Some notes on changes from Denizen to Denizen2.

Discuss plans for the development of Denizen2Sponge here.
User avatar
mcmonkey
Site Admin
Site Admin
Posts: 229
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 14th, 2016, 5:57 pm

BlackCoyote wrote:what about a speed argument in script containers?
Gone and irrelevantized.
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 14th, 2016, 5:57 pm

but putting - wait 50 times in a script just to get the same result as speed: 5t is not very convenient :(

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 229
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 14th, 2016, 6:10 pm

BlackCoyote wrote:but putting - wait 50 times in a script just to get the same result as speed: 5t is not very convenient :(
When would you ever legitimately want a wait /between EVERY command/?!
Denizen lead developer.
http://mcmonkey.org

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 14th, 2016, 6:15 pm

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

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 229
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 14th, 2016, 6:47 pm

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
You'd have so many issues arise from doing it like that.
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
What happens there? Player bob joined at the right moment (he had half a second times two = one whole second to sneak in there, not difficult) and player bob is now online in maintenance mode!

Code: Select all

- narrate "Deleting <cu@Skyblock.blocks[stone].size> stones..."
- modifyblock <cu@Skyblock.blocks[stone]> air
"Deleting 5 stones" > removes 7 stones. Woops, darn delay!



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

BlackCoyote
Regular
Regular
Posts: 78
Joined: August 6th, 2016, 1:44 am

Re: Some notes on changes from Denizen to Denizen2.

Post by BlackCoyote » August 14th, 2016, 6:53 pm

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

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 229
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » August 22nd, 2016, 9:23 am

Added point 16.
Denizen lead developer.
http://mcmonkey.org

User avatar
mcmonkey
Site Admin
Site Admin
Posts: 229
Joined: August 5th, 2016, 7:27 pm
Location: Los Angeles, California, USA
Contact:

Re: Some notes on changes from Denizen to Denizen2.

Post by mcmonkey » February 14th, 2017, 2:27 am

Added some clarifications!
Denizen lead developer.
http://mcmonkey.org

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest