Denizen Forum

So the burning question is:
What's the difference between Denizen2 and good ol' Denizen for Bukkit?

In no particular order, here are a few:

1. Denizen2 is for Sponge primarily (whereas Denizen 1 was for Bukkit and Spigot).
2. Denizen2 is a total internal rewrite, with no shared code at all.
3. Denizen2 is designed to be more abstracted and generic, in such a way that it can be reimplemented into other projects (EG even a different game entirely) with ease.
4. Denizen2 removes the following syntax: %def% but adds a similar syntax <[def]>.
   1. Note that the %def% syntax was removed due to it being unnecessary and producing oddities. It may be readded if deemed useful.
   2. It was originally added just for the quick syntax, but carried with it a strange pre-parsed implementation that is at-odds with the existing tag system.
   3. The new syntax works within the existing tag system much better.
5. Denizen2 is expected to be much faster. What Denizen1 does in a minute of pure CPU cycling, Denizen2 can do in under a second! This is actually the key reason for the total rewrite. We knew how to make it faster, but didn't have room to do that within the existing setup.
6. FAIR WARNING: Denizen2 makes no attempt to match minor details of Denizen1, EG a command may easily have entirely different syntax or even command name in one version compared to the other. This is due to it being a total rewrite: We might as well improve the details while we're improving the general system.
7. The if x { ... } notation is now if x:, same for loop commands and anything else that used braces. Note that braces still function, but are discouraged.
8. The /denizen command is gone, in favor of using /ex exclusively. Also, /ex received a bump in power. Including such things as /ex command one - command two - command three to specify multiple commands at once, and /ex reload to call the reload command, which is equivalent to the old /denizen reload scripts.
9. The event <context...> tag is now <[context].[...]> to work with the definition system better. (UPDATE: Old style now works too!)
10. Queue ID's are now a simple number that counts up, rather than nonsense text.
11. Waitable is now - &waitable command here where the & replaces the previous ~ symbol from Denizen1.
12. Determine format is different, now determine cancelled false instead of determine cancelled:false. Determinations are now handled as a map of values, rather than a list of text.
13. Procedure scripts are now accessed like so: <procedure[script:myscript|mycontext:mydata]> where you can add as much context as you please. Also, procedure tags now return a map as mentioned above.
14. There are a variety of tag types available. Where Denizen1 has "element", Denizen2 has "numbertag", "integertag", "booleantag". Where Denizen1 abused dList for maps, we have a separate "listtag" and "maptag".
15. There is no longer an inherent command delay, or any need for ^ in front of commands. If you wish to induce delays, add the wait command wherever needed.
16. Cuboid logic is modified a bit. In particular, blocks are considered minicuboids (1x1x1 cuboids) for all mathematical purposes, as opposed to assuming their cornermost point is the entirety of a block. Thus, a cuboid from 0,0,0 to 16,256,16 will exactly encompass one minecraft chunk. (Whereas in Denizen-Bukkit it's sometimes that and sometimes 15,255,15 depending on random variation details). Also, none of that multi-part cuboid nonsense.
17. All sorts of other minor differences that may not be listed currently. Do not expect this to be a complete list.

Have any questions about the differences (whether listed already or not mentioned)? Ask below!

Will Denizen2 still use add-ons like Depenizen and Webizen or is it different?

Mwthorn wrote:Will Denizen2 still use add-ons like Depenizen and Webizen or is it different?

Yup! We'll have addons available as usual, for all the things we need.

Some planned examples are:

Web Host - Webizen2
IRC Bot - D2IRCBot
Discord Bot - D2DiscordBot
Dependencies - Depenizen2Sponge

Added a note about /ex and /denizen!

A thing about the speed...

Here's a Denizen2 load test script: ... This runs on my PC in about a tenth of a second (around 100 ms).

A similar script in Denizen1 for Bukkit can take up to a minute.

That is a /massive/ speed boost!

mcmonkey wrote:A thing about the speed...

Here's a Denizen2 load test script:

Code: Select all

load_test:
    type: task
    debug: false
    script:
    - define count 100000
    - define counter 0
    - define time_start <system.current_time_milliseconds>
    - repeat <def[count]>:
      - define x <def[counter]>
      - define y <def[x].add[1]>
      - define counter <def[y]>
    - define time_end <system.current_time_milliseconds>
    - echo "Completed <def[counter]> loops in <def[time_end].subtract_integer[<def[time_start]>]>ms!"

... This runs on my PC in about a tenth of a second (around 100 ms).

A similar script in Denizen1 for Bukkit can take up to a minute.

That is a /massive/ speed boost!

All hail d2!

Also, is echo the new narrate? echo sounds console specific

BlackCoyote wrote: Also, is echo the new narrate? echo sounds console specific

Echo outputs to the console. Don't have narrate yet.

Added point 9.

EDIT: and 10 and 11.

Added 12, 13, and 14.

As Denizen2 is being built primarily for Sponge, a quetion arises: Is Denizen2 going to be compatible with Spigot/Bukkit, and if so, to what extent?

mawej1 wrote:As Denizen2 is being built primarily for Sponge, a quetion arises: Is Denizen2 going to be compatible with Spigot/Bukkit, and if so, to what extent?

As it currently stands: no it won't be, as the Sponge API is vastly different from the Spigot API and thus would be a challenge to make a 1:1 match.

However, if Sponge somehow winds up dead activity-wise (I really hope not) we will switch Denizen2 to Spigot.

mcmonkey wrote: Queue ID's are now a simple number that counts up, rather than nonsense text.

This is nice! But I do hope we can still keep the nonsense text in a tag for other uses

mcmonkey wrote: Waitable is now - &waitable command here where the & replaces the previous ~ symbol from Denizen1.

Why the change? I liked the ~ symbol

Mwthorn wrote:

mcmonkey wrote: Queue ID's are now a simple number that counts up, rather than nonsense text.

This is nice! But I do hope we can still keep the nonsense text in a tag for other uses

Maybe. I don't know about maintaining that word list again though. That thing, while incredibly entertaining, wasn't my best idea.

Mwthorn wrote:

mcmonkey wrote: Waitable is now - &waitable command here where the & replaces the previous ~ symbol from Denizen1.

Why the change? I liked the ~ symbol

That was done at random without thinking and I liked it so much I left it in.
I just copied that symbol from FreneticScript's matching setup.

It was that way in FreneticScript because it just seems like a more natural / sensical symbol to represent the concept of holding onto an entry and waiting for it to complete.

im sure we'll still have random.uuid which serves just as much if not a greater purpose than random.duuid @mwthorn

And who doesn't name their queues anyway? If it's a queue you want to track, either name it intentionally, or store the queue id in a known variable. Though i submit to you that having the script ID as the queue ID prefix is quite useful indeed. Let's not ditch that if it's not necessary please.

Anthony wrote:And who doesn't name their queues anyway? If it's a queue you want to track, either name it intentionally, or store the queue id in a known variable. Though i submit to you that having the script ID as the queue ID prefix is quite useful indeed. Let's not ditch that if it's not necessary please.

What's the use of that, beyond more readable debug?

mcmonkey wrote:

Anthony wrote:And who doesn't name their queues anyway? If it's a queue you want to track, either name it intentionally, or store the queue id in a known variable. Though i submit to you that having the script ID as the queue ID prefix is quite useful indeed. Let's not ditch that if it's not necessary please.

What's the use of that, beyond more readable debug?[/quotes]

stopping specific queues at specific events

BlackCoyote wrote:

mcmonkey wrote: What's the use of that, beyond more readable debug?

stopping specific queues at specific events

In what way does the queue ID help that?

mcmonkey wrote:

BlackCoyote wrote:

mcmonkey wrote:

Anthony wrote:And who doesn't name their queues anyway? If it's a queue you want to track, either name it intentionally, or store the queue id in a known variable. Though i submit to you that having the script ID as the queue ID prefix is quite useful indeed. Let's not ditch that if it's not necessary please.

What's the use of that, beyond more readable debug?

stopping specific queues at specific events

In what way does the queue ID help that?[/quote]

rather than keeping a list of queues that match a certain use yourself, you can simply set the queue's ID to have a prefix that you can then filter the queue list for, to retrieve all queues you want to affect.

BlackCoyote wrote:

mcmonkey wrote: In what way does the queue ID help that?

rather than keeping a list of queues that match a certain use yourself, you can simply set the queue's ID to have a prefix that you can then filter the queue list for, to retrieve all queues you want to affect.

I don't get how the Queue ID helps this in D2.