Feature - Implemented Adventure Queue Support

So the adventure queue has been spaded for a while, and at some point it would probably be worthwhile to track the queue in mafia at some point in the future.

http://kol.coldfront.net/thekolwiki/index.php/Adventure_Queue

I'm curious though if this information would even be that useful. How much would knowing the exact percentage of a particular encounter help a user? What are the scripting possibilities if you have access to the queue? Would it be worth implementing something that players have basically no control over (besides banishing or olfaction) just to see the results? What about when someone adventures outside of mafia, it would basically invalidate any tracked data until they clear and refill the queue(s) again. What are your thoughts?

First, it would require adding something like 200 preferences (one for every adventure.php location), and that seems excessive. Second, mafia doesn't properly record where you adventured when things like teleportitis affect it, and anything like that messes with queue calculations.

I don't think it is worth implementing because I don't see how it can be used to make strategy decisions. There was a global queue before, right? That would have made it interesting...

Yes tehre was. And the strategies involving it were very metagamey and I think one of the reasons they changed it to be what it is now (and added some of the queue manipulations that exists now instead).

It would certainly take a lot of saved data since there's a separate combat/noncombat queue for each zone. Additionally mafia currently doesn't really know much about noncombat adventures besides what option to select. I'm kind of with you guys on this, but I thought it should be brought up for discussion.

This actually reminds me of another large feature request that I think would be way more useful, having a data file of all the noncombat adventures, their results, and where they're located. I should write that one up sometime.

And a run_noncombat() function!

Yeah... actually having that use datafiles, instead of all being hardcoded, would be a nice upgrade/update to the internals.

On a perhaps related (and easier to implement) note, I'd like to see some delay() tracking. Now that delay is always 5, mafia could conceivably track your progress on burning up delays. It'd have to account for hipster combats, though.

As for the queue stuff, I think it is relevant in HC speed-running when trying to make the "get N, arrow ascii and fax adding machine" decision(s). Delay is also important here. It is also relevant for spading, as there are several questions to answer about specific queue-affected/related mechanics which generally depend on having a perfect knowledge of your queue status. This can of course be arranged by first spending enough turns to fill both queues with known encounters, though it might be nice to waltz into a new zone/mechanic/project without having to do that prep work. Either way it's marginal enough that I'd consider it a low priority if there's not something else it dovetails nicely with.

I would expect that accurately tracking delay() is the hard part. If that was handled properly, then the last step would be to update the combat or noncombat list for the zone with lastEncounter, or to recognize it as a superlikely/semirare/UR/clover adventure/whatever and not update either of those lists.

AWISE!

On a related and presumably much easier to implement note: would it be possible for mafia to store the last N combats and N noncombats (N at least 5) you've had (and possibly their zone) in a retrievable setting? This wouldn't be a full queue state monitoring (more like NS11 queue monitoring), so you wouldn't have to store hundreds of zones worth of queues, but as long as you tend to adventure in a single zone at a time, then this information would frequently be enough to give you the full queue state for the zone in question. A built-in command or user script to display/use this information could then be used to help make these optimality decisions. If you make N a little bigger than 5 that would also tend to give enough room for a user/script to ignore superlikelies, skipped noncombats, or anything that doesn't contribute to the queue. 8 to 10 perhaps? Or maybe have the number stored be a preference that can be set to something other than a default if desired?

And mafia could probably use this information to automatically adjust and display the rates on specific combats in Location Details. Specific rates on noncombats would also be nice, but requires adding that to Location Details or something similar, which may be excessive. I can do without this particular bit, since always displaying the exactly correct rate (with the understood base rates) would require mafia to know which things do and don't contribute to queues and when, and that's one of the things we've so far figured as a major obstruction to perfect queue tracking.

AFAIK, it WOULD have to be an individual queue for each zone. For someone like me who hops around a ton, just storing the last 5 would be wildly inaccurate.

It wouldn't be for you, then. Or you'd look for a customizable number, or you'd run a custom script that would collect the last adventures periodically and form the list to your satisfaction.

If mafia is adjusting location encounter rates based on a just-the-last-5-adventures queue, the feature is forced upon me. I would not want that feature.

I fully believe in either doing a feature right or not doing it at all. To me, that is not the 'right' way.

Like I said, I can do without that feature, since it has a number of shortcomings.

And doing perfect queue tracking is infeasible, as it requires substantial amounts of data storage (and resetting it on ascension or command) as well as substantial amounts of restructuring how mafia interprets a variety of adventures and their outcomes. Partial queue tracking should be radically more feasible, and sufficient in most cases; and in the few cases it isn't custom user scripts can take over (as they can likely do now, but presumably internal support will help them out).

Hey, 2-year-old thread.

I recently took a couple hours and coded up a way to do this using serialization. Internally we can maintain a TreeMap of (zoneName) -> (List of last 5 monsters encountered in that zone). When logging out, we serialize to a file (roippi_adventurequeue.ser) that ends up being about ~12kb. On login, we deserialize and read in that TreeMap's value from the file.

It needs a lot of polish and sanity checking to be ready for the masses, but it's Not That Big Of A Deal to implement.

I actually implemented this as an afterAdventureScript (and file_to_map / map_to_file), but then I was too lazy to do anything useful with it afterward.

r12063 adds the infrastructure for queue tracking. Right now we just track the combat queue. There is a .queue $location proxy field that you can use to see the last 5 dudes you saw in a zone.

I'm sure there is more work to be done on this but I think it's okay to release as a beta feature.

Upon logout:

Oops, used the wrong KoLConstants constant. r12065

So I think the API for appearance_rates will be an overloaded version with the extra boolean denoting whether you want the queue effects or not.


I kinda dig watching the encounter rates jump around in Location Details as I adventure. I'll leave those as queue-modulated numbers.