QeMistry Queue Manager

[kevutian]

I was actually meaning to post on this thread, hence my screw up yesterday.

I really like the look of this package and have decided to play around with it some more. I have just a small issue, though. I am declaring all my namespaces on the sysLoadEvent event, although the queue system fails to initialise until I click the script. I created a queue called balQueue like your suggestion above, although in system load, this variable is nil. I have a test alias that contains:

Code: Select all

balQueue:add( {code = "touch cloak", required = "daze.balances.physical.state", 
	consumed = "daze.balances.eq.state"} )

I'm sure it's something basic that I am just being too lazy to debug, but how might this be rectified, please?

Also, if you might explain the reasoning behind using "balQueue" also? Will I also need an "eqQueue" ? - It's a tad confusing especially when the function can be passed args to declare whether these are required/expended.

Finally, how would one go about adding multiple balance requirements to the queue?
It tried:

Code: Select all

balQueue:add( {code = "touch cloak", required = "daze.balances.physical.state", "daze.balances.eq.state", consumed = "daze.balances.eq.state"} )

But it did not seem to like this.

Many, many thanks on such a great queue system. It's really nice not having to write such a convoluted thing.

Regards,

Martin.

[Oneymus]

As to your first problem, I don't know how much advice I can offer. All scripts should load when the client starts up and connects to the MuD. If the sysLoadEvent triggers before this loading, you may need to have a second script to handle script-dependent initialization. This should not be the case, but since I'm not terribly familiar with Mudlet's event structure, I can't comment on that. It may be a simple case of improper script order.

If you send me relevant debug messages, I may be able to help you figure it out.

With IRE MuDs in mind, it sometimes makes more sense to have separate Balance and Equilibrium Queues. While most actions do require both Balance and Equilibrium to work, there are a few exceptions here and there. That being said, you could get away with a single Queue requiring both if you're willing to give up that granularity.

The idea behind having both the Queue balance and the Action balance was to allow finer control for individual Actions while retaining generalized functionality for Queues. This means that a "Balance Queue" should reasonably handle ALL Actions concerned with Balance, but does not needlessly restrict Action behaviour.

To add multiple balances to an Action, you pass a table.

Code: [show] | [select all] lua

balQueue:add( {code = "touch cloak", required = {"daze.balances.physical.state", "daze.balances.eq.state"}, consumed = "daze.balances.eq.state"} )

It should be noted, though, that you do not need to mark a balance both "consumed" and "required". If it's "consumed", it's already "required". Further, assuming you instantiated balQueue with "daze.balances.physical.state", you don't need to specify that for each Action. So, your add() should be...

Code: [show] | [select all] lua

balQueue:add( {code = "touch cloak", consumed = "daze.balances.eq.state"} )

[Oneymus]

I would like to point out that I wrote this script quite a while ago. It could stand some improving. If there's sufficient demand for it, I'd be more than happy to clean it up and expand functionality.

[kevutian]

Thanks a bunch for that. I found the source of the problem and have this working. I am pondering on seeing how this would work were I to add a herb balance queue. Also do you anticipate much in the way of latency if a user were to add multiple queues and be fighting in a combat setting?

I am currently in the process of writing a "base system package" - Much like how Crucible works. Having collated a few things and added a lot of my own stuff, this package is nearing completion. It would be great for more functionality, however! (As is always the case.)

Thanks again for releasing this. It will be getting a fair bit of use over the coming months, so we'll see what happens.

[Oneymus]

It's a fairly simple process, so I don't predict any significant (or noticeable) lag. It could probably be improved, which I may look into since you've gotten me to take another peek at it.

Are there specific features you'd like to see added? What would help you? What do you expect out of a Queue manager?

[kevutian]

Right now, what is does is actually pretty sufficient, to be honest. I guess the only other thing that would be nice would be a more streamlined way to add to a "default" queue for those people who might otherwise simply be unable to get this working. A sample alias and a few sample variables, perhaps?

I'll just finishing up writing a stress test script for this. I'll post my results later today.

[Oneymus]

I'm definitely very interested in this stress test.

My plans to rewrite Qemistry are as follows:

1. Move code to .lua files and require in.
   • Beyond personal preference, this allows me to use take advantage of things like lexical scoping and encapsulation.
2. Add meta functionality to the Qemistry object.
   • A list of all Queues currently managed (all Queues will now require names, as a consequence).
   • Executing all/one Queue through a single interface.
3. Implement similar Object Oriented decoration to that used in Vyzor.
   • Unnamed constructor.
   • (potentially) Properties
4. Optimize the script with locally stored global functions.
5. Address possible performance issues with the current implementation.

It is my hope that these changes will make Qemistry more robust and efficient.

[Akaya]

Exactly what I needed. Thanks again Oneymus!

[Oneymus]

Glad I could help!

This has been around for a while, and I don't know if too many people have been using it.

[phasma]

I've been using it for an awfully long time. While I may have made a fair few changes so that is fits my uses, I can certainly confirm that the functions are absolutely brilliant.

Again... Thanks!