Some notes on changes from Denizen to Denizen2.
Re: Some notes on changes from Denizen to Denizen2.
Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.
We are the music makers, and we are the dreamers of dreams...
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
None of you are clarifying how complicated Queue ID's help this at all.Anthony wrote:Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.
Denizen lead developer. On Discord as
mcmonkey#6666
.Re: Some notes on changes from Denizen to Denizen2.
I'm not suggesting that the complicated and convoluted method of random text strings be maintained... the incremental numbering system is perfectly sufficient imo with the one caveat of having the originating script ID be the queue ID prefix.mcmonkey wrote:None of you are clarifying how complicated Queue ID's help this at all.Anthony wrote:Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.
We are the music makers, and we are the dreamers of dreams...
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Let me put it in BIG TEXT for you.Anthony wrote:I'm not suggesting that the complicated and convoluted method of random text strings be maintained... the incremental numbering system is perfectly sufficient imo with the one caveat of having the originating script ID be the queue ID prefix.mcmonkey wrote:None of you are clarifying how complicated Queue ID's help this at all.Anthony wrote:Queue management/manipulation is one of Denizens strong points. Let's not impede that unnecessarily. Again, we can easily use flags to track queues, but that is indeed another step in the process.
WHY
Denizen lead developer. On Discord as
mcmonkey#6666
.Re: Some notes on changes from Denizen to Denizen2.
Because it's such a good idea that some genius dev decided that's how queues should be identified already... by name...mcmonkey wrote:Let me put it in BIG TEXT for you.
WHY
We are the music makers, and we are the dreamers of dreams...
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Not only does that linked code go directly against your own point, you failed to make a fully qualified point in the first place! Good job!Anthony wrote:Because it's such a good idea that some genius dev decided that's how queues should be identified already... by name...mcmonkey wrote:Let me put it in BIG TEXT for you.
WHY
Denizen lead developer. On Discord as
mcmonkey#6666
.Re: Some notes on changes from Denizen to Denizen2.
not to butt in here, but I think this answers your question mcmonkey:
[11:00] <BlackCoyote> lets say you have a while loop on the player, with irregular waiting periods in it, if the player logs out, the commands running behind that might error since the player is no longer online, we have 2 choices for this, put a check in front of every single command, or clear the queue when the player goes
[11:01] <BlackCoyote> clearing the queue is the more convenient solution to this in my experience, now we can track the queue in 2 ways
[11:01] <BlackCoyote> by keeping a list ourself, in flags or something, or by putting a prefix on the queue
[11:01] <|Anthony|> i name my queues intentionally for this exact reason
[11:01] <|Anthony|> to avoid having to manage queues in a flag data set
[11:01] <BlackCoyote> keeping the list yourself is tedious, lots of work, and a lot of things to account for just in order to make sure the flag always only shows active queues
[11:02] <|Anthony|> the necessary data should be built right into the name of the queue
Wandering by lone sea-breakers, and sitting by desolate streams;
Denizen Super-noob
Denizen Super-noob
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
Please present your own response or allow the relevant people to present their own answers.AbiDada wrote:not to butt in here, but I think this answers your question mcmonkey
As was mentioned later in that channel, that response isn't particularly sufficient and was yelled in anger by annoyed users rather than well thought out.
My question stands:
WHY does having queue's prefixed with a script title help anything at all ever?
Denizen lead developer. On Discord as
mcmonkey#6666
.Re: Some notes on changes from Denizen to Denizen2.
An example scenario is this: things such as webget and sql take an amount of time and should be done in the background. Running these functions with a known name allows you to easily and reliably check for a current process if triggered again. A real world example right here relating to webget.
We are the music makers, and we are the dreamers of dreams...
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
So that doesn't answer the whole "script title prefix" thing, but it does pose an alternate point which needs a response.Anthony wrote:An example scenario is this: things such as webget and sql take an amount of time and should be done in the background. Running these functions with a known name allows you to easily and reliably check for a current process if triggered again. A real world example right here relating to webget.
If I read you correctly, you want a way to determine rapidly if a queue for a certain process is already running.
There are a variety of better ways to do this than custom ID's.
Some examples include:
- (Best) Store a flag somewhere indicating the queue. If the flag is present and the queue held by the flag is valid and running, the process is running.
- (Alternate) Take the tag that returns a list of all queues, filter it for being run by the relevant script or containing other identifying data, and if you get back a list with one or more entries, you have both the queue and a reference to the queue.
A thing to consider when you're wanting queue ID's is this:
Can you give custom ID's to players? NPCs? /Anything/? No, you can't. You either leave a marker on them and search for the marker, or add them to an external named reference. What's wrong with doing the same for queue's?
Denizen lead developer. On Discord as
mcmonkey#6666
.Re: Some notes on changes from Denizen to Denizen2.
Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.
We are the music makers, and we are the dreamers of dreams...
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.Anthony wrote:Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.
In fact, writing your own specialized code would be /more/ efficient than a general for-all-queues name-based lookup table!
It is assumptive logic... specialized code that reduces general complexity is smart coding!
Denizen lead developer. On Discord as
mcmonkey#6666
.-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
I happily believe that your current idea is going to be most efficient for d2. But you have to take into account the main reason why denizen is used. use of ease.denizen is meant to be really easy to use and to do otherwise complex things with.mcmonkey wrote:By requiring script names (as opposed to numeric IDs), you're creating an /internal/ lookup table... which, in D2, is no more efficient than an external one for most cases.Anthony wrote:Any opportunity to exclude managing an external lookup table is a performance increase both on the read and the write. It is assumptive logic... a consistent naming convention that removes extra steps in logic is smart coding.
In fact, writing your own specialized code would be /more/ efficient than a general for-all-queues name-based lookup table!
It is assumptive logic... specialized code that reduces general complexity is smart coding!
If you're going to strip the features that make it easy to use, to make it faster, you're making it more and more viable for users to instead directly program their own thing as a plugin rather than use denizen as a middle way.
Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
BlackCoyote wrote:
Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.
Code: Select all
- define queue_prefix "MySpecialQueue" <[run_queue]>
Denizen lead developer. On Discord as
mcmonkey#6666
.-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function. If we're going to have to filter out specific cases out of that list, every time, simply because we need an identifier, it again goes at cost of the user's ease of use and efficiency.mcmonkey wrote:BlackCoyote wrote:
Lets meet in the middle, and introduce a 'prefix' option for queue IDs, that are stored externally from queues, but still internally in d2 for the convenience of the scripter. this would only be optional and should only be affecting efficiency rates when actually utilized.:D ?Code: Select all
- define queue_prefix "MySpecialQueue" <[run_queue]>
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
wh... why?BlackCoyote wrote: me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function.
I can almost understand that in D1 (ALMOST) but in D2... where you can use a MapTag if you need a set of keys and values, ...?
Denizen lead developer. On Discord as
mcmonkey#6666
.-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
The maptag sounds like a neat thing, however it wouldn't work too great for API's wanting to make the user input as simple as possible. being able to pass 1|2|3 is a lot easier for the user than a=1|b=2|c=3. for some of us maptags might be extremely simple, but for beginners who need denizen because things otherwise get too complex, it is only pushing the bar up higher for them.mcmonkey wrote:wh... why?BlackCoyote wrote: me and anthony both use <queue.definitions> to return a complete list of arguments passed into a function.
I can almost understand that in D1 (ALMOST) but in D2... where you can use a MapTag if you need a set of keys and values, ...?
-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
aditionally, a maptag would mean processing raw dlist inputs, for example <context.args> into a maptag or some sort, which would mean additional work and complexity for scripters.
- mcmonkey
- Site Admin
- Posts: 299
- Joined: August 5th, 2016, 7:27 pm
- Location: Los Angeles, California, USA
- Contact:
Re: Some notes on changes from Denizen to Denizen2.
If the input is just 1|2|3, then make the input .... 1|2|3, as a ListTag.BlackCoyote wrote: The maptag sounds like a neat thing, however it wouldn't work too great for API's wanting to make the user input as simple as possible. being able to pass 1|2|3 is a lot easier for the user than a=1|b=2|c=3. for some of us maptags might be extremely simple, but for beginners who need denizen because things otherwise get too complex, it is only pushing the bar up higher for them.
I suggested a map tag cause I assumed you wanted definition names. If that's not needed, then just a simple list will fully suffice.
Denizen lead developer. On Discord as
mcmonkey#6666
.-
- Regular
- Posts: 78
- Joined: August 6th, 2016, 1:44 am
Re: Some notes on changes from Denizen to Denizen2.
so you want me to make sure the end user passes the undefined list, as a single definition, and then have me, inside the script recieving that list, turn it back into individual definitions?
once again that becomes more work and makes denizen less user friendly than when we could just pass context[<dlist>] and have each argument ready as its own definition.
once again that becomes more work and makes denizen less user friendly than when we could just pass context[<dlist>] and have each argument ready as its own definition.
Who is online
Users browsing this forum: No registered users and 1 guest