Gone and irrelevantized.BlackCoyote wrote:what about a speed argument in script containers?
Some notes on changes from Denizen to Denizen2.
- mcmonkey
- Site Admin
- Posts: 187
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Denizen lead developer.
http://mcmonkey.org
http://mcmonkey.org
-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
but putting - wait 50 times in a script just to get the same result as speed: 5t is not very convenient :(
- mcmonkey
- Site Admin
- Posts: 187
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
When would you ever legitimately want a wait /between EVERY command/?!BlackCoyote wrote:but putting - wait 50 times in a script just to get the same result as speed: 5t is not very convenient :(
Denizen lead developer.
http://mcmonkey.org
http://mcmonkey.org
-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
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
- mcmonkey
- Site Admin
- Posts: 187
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
You'd have so many issues arise from doing it like that.BlackCoyote wrote: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
Here's a random example or two not necessarily from that situation but from just /any/ situation
Code: Select all
- define players <server.list_online_players>
- kick %players% "Server is going into maintenance mode"
- flag server maintenance
Code: Select all
- narrate "Deleting <cu@Skyblock.blocks[stone].size> stones..."
- modifyblock <cu@Skyblock.blocks[stone]> air
I 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...
Denizen lead developer.
http://mcmonkey.org
http://mcmonkey.org
-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
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
- mcmonkey
- Site Admin
- Posts: 187
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Added point 16.
Denizen lead developer.
http://mcmonkey.org
http://mcmonkey.org
- mcmonkey
- Site Admin
- Posts: 187
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Added some clarifications!
Denizen lead developer.
http://mcmonkey.org
http://mcmonkey.org
Who is online
Users browsing this forum: No registered users and 1 guest