Some notes on changes from Denizen to Denizen2.
- Thread starter mcmonkey
- Start date
but putting - wait 50 times in a script just to get the same result as speed: 5t is not very convenient :(
background processes that do a lot of work, but that you don't need to have done urgently, just to keep things updated. For example one thing i can think of right now that uses it is a system on a skybock server that checks various properties of a cuboid from entities, materials, connected structures, etc. It's a big blob of abstract code one after another that just checks things in the area and then renders a score based on it. if this were a speedy queue it'd cause a lot of lag, if i were to try to slow down the queue between every minor lag inducing check i'd have to put down about 20 wait commands. It'd be far more convenient for me to have control over the queue speed in this case
You'd have so many issues arise from doing it like that.BlackCoyote said:
Here's a random example or two not necessarily from that situation but from just /any/ situation
Code:
- define players <server.list_online_players>
- kick %players% "Server is going into maintenance mode"
- flag server maintenance
Code:
- narrate "Deleting <[email protected][stone].size> stones..."
- modifyblock <[email protected][stone]> airI can't honestly think of valid code that wouldn't have issues from an enforced /every command/ level delay.
Denizen-Bukkit has so many oddities to fight the glitches off, and still confuses the hell out of new users because of it...
as i said in my example, it's entirely lookup, it only reads data, but data that is inefficient to look up, and then processes it. it doesn't try to adjust an object of which it isn't 100% certain that it exists at that very specific time.
Besides, the few cases it could have to adjust data, it could, one way or another, ensure that that specific set of commands runs instantly, which would still be far more convenient to bother with than placing down a lot of wait commands.
If you're concerned about this speed argument potentially confusing new users, it'd be a simple matter of making the speed argument default to instant, and not shove it in new users their face when they're not experienced enough
Besides, the few cases it could have to adjust data, it could, one way or another, ensure that that specific set of commands runs instantly, which would still be far more convenient to bother with than placing down a lot of wait commands.
If you're concerned about this speed argument potentially confusing new users, it'd be a simple matter of making the speed argument default to instant, and not shove it in new users their face when they're not experienced enough