Feature Request: Record order of Daily Dungeon rooms

VeeArr

Member
The order in which Daily Dungeon rooms are encountered is turning out to be a useful piece of data for a spading effort. It would be nice if there was a preference that recorded what encounter was in each room. (Only the type of encounter--monster, door, or trap--matters, not the specific monster fought or trap element.)

Ideally, the preference would be something like ????_????_???? at the start of an ascension and fill in each ? as that room's identity is found, finally becoming (for example) MDTD_MTMD_MDTT after the room order is fully-known. This preference resets on ascension.
 
Is the order identical for every day and only resets after ascension? (I think you said yes, but..)

Could this be satisfied by a Daily Dungeon script that you run and it creates or adds to or validates a user preference?
 
Yes, the order of room types is identical every day until you ascend.

In an ideal world the solution wouldn't require using a script to collect the data because the idea is to use information that you've naturally seen over the course of an ascension to predict other information.
 
Is this necessary?
That is, if you just want ascension info and details about the Daily Dungeon rooms, you could probably write a log parser and have people parse they logs from the past few years and generate thousands of data points. I know I have 10+ years of session logs.
 
In an ideal world the solution wouldn't require using a script to collect the data because the idea is to use information that you've naturally seen over the course of an ascension to predict other information.

We have different definitions of ideal world :-) In my ideal world KoLmafia would not have features that could be implemented by scripts. If it is not in the code base then it does not have to be tested, maintained, or fixed and it does not create a possible security hole or something that could be maliciously exploited.

I was proposing using a script to run your DD turns. A side effect of running the script would be that it collects the data. I could have been clearer that I was thinking of a turn burning script and not something that acquired data.

If you are only concerned about using the data for the current ascension then a log parser might be the way to go, provided you had a decent tool set and were comfortable using it.

If you are thinking about historical data and some kind of predictive tool then log parsing is the way to go. My earliest session log is from January 1, 2014 which suggests to me that somewhere there is a disk with even older session logs that I just forgot to copy.
 
We have different definitions of ideal world :-) In my ideal world KoLmafia would not have features that could be implemented by scripts. If it is not in the code base then it does not have to be tested, maintained, or fixed and it does not create a possible security hole or something that could be maliciously exploited.

I'm sympathetic to this position, but it doesn't match the reality of what KoLmafia currently is (in my opinion). It tracks all kinds of things that could theoretically instead be determined by going back and parsing the run's logs, because having that information already tracked enables scripts to leverage that information more readily.

I'll acknowledge that this particular case is maybe too niche to warrant tracking within KoLmafia, but let's not pretend that the vast majority of things it tracks already are only tracked because doing so is needed for KoLmafia to function.
 
Maybe for a little more context about what we're doing: It has been discovered that you can look at some bits of information about the current ascension and use that determine other information about the ascension. As an example, currently, we're using things like the effects of bang potions to predict the answers to the Mer-kin dreadscroll without actually gathering the various clues, and this is easy because KoLmafia automatically tracks the bang potion effects.

It turns out the daily dungeon room order also has predictive value in the same way, so it would be convenient to have ready access to it, rather than having to go back and figure out what it was after the fact.
 
Back
Top