Ascension Log Visualizer

For stuff related to KoLmafia, KoLproxy, Ascension Log Visualizer, and greasemonkey scripts. Maybe other stuff too.
User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Ascension Log Visualizer

Postby Flolle » Sun Jan 25, 2009 10:11 am

This thread has been superseded with a thread in the KoL main forum. I recommend to use that one for feedback purposes.


I'd like to introduce everyone to a program able to visualize ascension logs. It can handle parsed ascension logs like the ones posted on forums (they are often created by this very program), unparsed KolMafia session logs and an Ascension XML format that tries to put the data of KolMafia session logs into a more structured form. The program can also create parsed logs, even with color coding if you want, or Ascension XML files from KolMafia session logs. Development has gone on for quite some time, so I'd like to think that the program is pretty stable. But enough of an introduction, it'll be easier and faster if you just see for yourself. :)

I hereby present the Ascension Log Visualizer.


Requirements
The Ascension Log Visualizer is written in Java and as such you will need to have a new enough Java SE Runtime Environment (called JRE) installed on your system. Java SE 5 (sometimes called Java SE 1.5) or newer is the minimum, however Java SE 6 Update 10 (Java SE 1.6.10) or newer is recommended (better looking GUI and faster rendering of said GUI). As far as operation systems go, there shouldn't be a problem no matter which one you are using as long as you have the correct JRE. No guaranties though, because personally I am able to test only on Windows XP and Linux (Ubuntu to be exact).

Links
Project page: http://code.google.com/p/ascension-log-visualizer/
Download page: http://code.google.com/p/ascension-log- ... loads/list
End-User wiki: http://code.google.com/p/ascension-log- ... zer/w/list



If something seems buggy or otherwise strange, I'd greatly appreciate it if you send feedback about it. The same goes for feature suggestions, but note that I may wait with adding features depending on the size of them. Also, if you have a feature suggestion, you should be able to describe how it should look in the end. For example, if you want an additional chart to be added, you should be able to tell me what data should be found in it and what the chart should look like.

Feedback should be send to this thread, the thread on the HCO forum or through the issue tracker of the project. While forum PM or K-Mail will not be outright ignored (although I personally do hate the K-Mail interface), I would like for as much of the bug/feature discussions to be in the open as possible.
Last edited by Flolle on Sat Mar 19, 2011 7:16 am, edited 4 times in total.

User avatar
QuantumNightmare
AFH
Posts: 1827
Joined: Mon Jan 29, 2007 10:28 pm
Location: Montreal

Postby QuantumNightmare » Sun Jan 25, 2009 12:25 pm

Is there any difference between the AFH mafia log parser, and the parser used in this program?

Either way, this will reach a much bigger audience since it's easier to use. And the visualization is awesome. Nice to see you back, flolle!

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sun Jan 25, 2009 12:45 pm

This thing is incredibly awesome. Well done.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sun Jan 25, 2009 3:34 pm

QuantumNightmare wrote:Is there any difference between the AFH mafia log parser, and the parser used in this program?

There are some differences. I never made a list, so I'll have to recite this from the top of my head.
  • There is an "Ascension Start" adventure location at the beginning of every log to catch all actions done before any turns were spent.
  • The familiar change line (-> Turn [#] familiar) uses the turn on which the change happened as its turn number, not the turn on which the familiar was first used. Reasons were program internal usage of those numbers and me thinking it is the more logical approach, but I guess one can argue in either direction here.
  • Stat gains from areas and consumables are always given.
  • I didn't check in detail, but it's possible that some itemdrops might be handled differently.
  • There is a HUNTED COMBATS summary. It's very similar to the SEMI-RARES summary in format, only here it's hunted combats which are listed.
  • The STATS summary holds some additional information
  • The EATING AND DRINKING AND USING holds additional information.
  • There is no BY COST summary.
  • There currently is no level change line (the ones starting with =>).
  • Navel Ring usage isn't tracked. Admittedly, I don't really get what those lines are saying, but I also didn't really look at that yet.
  • There is no +stat breakdown. I don't know whether I actually want to parse equipment operations yet.
I may have missed some things, but you can try to check for yourself. Either by looking at the example log or simply using the program on some of your logs.


QuantumNightmare wrote:Either way, this will reach a much bigger audience since it's easier to use. And the visualization is awesome. Nice to see you back, flolle!

Thanks! But I'm pretty sure that there are people who want to continue to use your parser, which is the reason I included a way to run it from inside the Ascension Log Visualizer. :)

User avatar
Manendra
My Pie Blown Sky High
Posts: 663
Joined: Tue Apr 22, 2008 4:04 pm

Postby Manendra » Sun Jan 25, 2009 3:58 pm

Very well done, thanks! I would, however, like to request that the "=>Level 2!" thinger in the run be added back. I find it to be useful to see in-run as well as at the end of the run where I hit each level.

User avatar
QuantumNightmare
AFH
Posts: 1827
Joined: Mon Jan 29, 2007 10:28 pm
Location: Montreal

Postby QuantumNightmare » Sun Jan 25, 2009 4:00 pm

Flolle wrote:[*]Navel Ring usage isn't tracked. Admittedly, I don't really get what those lines are saying, but I also didn't really look at that yet.
If you attempt to run away while using the navel ring, the MafiaLogParser will check if a turn was used or not. For example, the following text means that 4 turns were expended searching for the encryption key. 8 run aways were attempted with the navel ring during this time, and 6 of those 8 did not use up a turn. This helps keep track of navel ring use during a softcore run.

Code: Select all

[71-74] Outskirts of The Knob
     &> 6 / 8 free retreats


Also, could you filter out repeat drops?

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sun Jan 25, 2009 4:34 pm

Another quick request, mafia seems to be kind of dumb about tracking days, so if you do two "days" on the same (real-life) calendar day, it'll show up as one "day" in the mafia logs. Fortunately it does add the in-game calendar date to a run, perhaps check that to break up things that matter per-day (such as pulls). It's not a huge deal, but it's kind of weird when it shows me having 40 pulls on day 1.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sun Jan 25, 2009 5:43 pm

First, I forgot to mention it last time, but thanks for the compliments. :)

Manendra wrote:Very well done, thanks! I would, however, like to request that the "=>Level 2!" thinger in the run be added back. I find it to be useful to see in-run as well as at the end of the run where I hit each level.

I guess I can see about whether I can add it.


QuantumNightmare wrote:If you attempt to run away while using the navel ring, the MafiaLogParser will check if a turn was used or not. For example, the following text means that 4 turns were expended searching for the encryption key. 8 run aways were attempted with the navel ring during this time, and 6 of those 8 did not use up a turn. This helps keep track of navel ring use during a softcore run.

Thanks! That explanation makes stuff much clearer! :)

It does seem to be not that easy to add for me though, so it's not really that high on the to-do list for the time being.


QuantumNightmare wrote:Also, could you filter out repeat drops?

Er, I don't really know what you are meaning by that. Is this a request or a question concerning the internal parser?


stupac2 wrote:Another quick request, mafia seems to be kind of dumb about tracking days, so if you do two "days" on the same (real-life) calendar day, it'll show up as one "day" in the mafia logs. Fortunately it does add the in-game calendar date to a run, perhaps check that to break up things that matter per-day (such as pulls). It's not a huge deal, but it's kind of weird when it shows me having 40 pulls on day 1.

Hrm, I hoped that something like that wouldn't happen. :?

I'll see what I can do. Might be a little tricky to fix though. Just to be clear here, you end up having two days worth of logging in a single Username_date.txt session log, correct?

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sun Jan 25, 2009 5:49 pm

Flolle wrote:Hrm, I hoped that something like that wouldn't happen. :?

I'll see what I can do. Might be a little tricky to fix though. Just to be clear here, you end up having two days worth of logging in a single Username_date.txt session log, correct?


Correct. I can send you the raw logs if they'd be helpful. I'm certainly no programmer, but it seems like you could just have an array of all the KoL dates, find the first one that appears (since mafia logs it when you log in), then tell the day counter to increment when you see the next one in the array. Or something.

Oh, and this might be an option I missed, but it would be nice to set a default directory. My mafia folder is in C: and for some reason it always opens to My Documents, making further navigation a pain. If there was some way to specify a default sessions directory (even if it was just per session of the visualizer) that would be nice.

I've also had some weirdness, one run it didn't recognize any leveling I did after level 10, said I killed the NS at level 10. As I said before, if any logs would be helpful I'll gladly send them, this project is incredibly useful.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sun Jan 25, 2009 7:05 pm

Logs are always helpful if you are willing to send them. You can send them to my google account (orriiion [at] googlemail [dot] com). :)

Concerning setting a default folder: The Java file dialog uses the system default folder in case no other folder is specified. In the case of Windows, that is My Documents. Would it be fine if I let the file dialog point towards the last used folder to load mafia session logs from?

User avatar
QuantumNightmare
AFH
Posts: 1827
Joined: Mon Jan 29, 2007 10:28 pm
Location: Montreal

Postby QuantumNightmare » Sun Jan 25, 2009 7:07 pm

Flolle wrote:Er, I don't really know what you are meaning by that. Is this a request or a question concerning the internal parser?
By repeat drops, I mean the second giant needle you receive. The log parser has a list of drops that are only critical to display the first X times they are seen, which just helps reduce spam.

Also, if you have "session log records player state on login" selected, the mafia log will print the KoL date when you log in as well as the drunkenness level. If the drunkeness decreases or the KoL day changes... rollover occurred. Not sure what method you use to find day changes, but that's what the log parser does.

(I guess I mean, why recreate the internal parser to produce the exact same output as the afh log parser, when all these extra features already exist? It would be simple to edit the log parser to include the changes you've made, instead of reinventing the wheel.)

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sun Jan 25, 2009 8:08 pm

Another comment, on the turn rundown, a scrollbar at the bottom would be nice, so that we can move the turns over to get actually see what bars correspond to what. At later levels it's pretty difficult to tell what's actually going on.

Also I'm not sure how to interpret the familiar data there, is it from one colored bar to the next?

Huh, also loading an already parsed log apparently borks all the stat info. Bug or feature?

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Mon Jan 26, 2009 12:10 pm

I made a new beta release that should address most of the problems people had with the program. Please note that all users have to recreate the data files before using this new revision. You can recreate the data files through the Extra->Recreate data files option.


Manendra wrote:Very well done, thanks! I would, however, like to request that the "=>Level 2!" thinger in the run be added back. I find it to be useful to see in-run as well as at the end of the run where I hit each level.

This is included in the new release.


stupac2 wrote:Another quick request, mafia seems to be kind of dumb about tracking days, so if you do two "days" on the same (real-life) calendar day, it'll show up as one "day" in the mafia logs. Fortunately it does add the in-game calendar date to a run, perhaps check that to break up things that matter per-day (such as pulls). It's not a huge deal, but it's kind of weird when it shows me having 40 pulls on day 1.

I believe that I was able to fix this problem. Note that this problem can however only be recognised if the "player snapshot on login" logging option of KolMafia is turned on. (in one of the logs you send me it wasn't turned on, stupac2; in case you'll wonder why it still won't work)


stupac2 wrote:Oh, and this might be an option I missed, but it would be nice to set a default directory. My mafia folder is in C: and for some reason it always opens to My Documents, making further navigation a pain. If there was some way to specify a default sessions directory (even if it was just per session of the visualizer) that would be nice.

As noted earlier, the file dialogs now point towards the last used folder to load mafia session logs from.


stupac2 wrote:I've also had some weirdness, one run it didn't recognize any leveling I did after level 10, said I killed the NS at level 10. As I said before, if any logs would be helpful I'll gladly send them, this project is incredibly useful.

This was a problem with mafia logs that didn't contain player snapshots. The parser could not determine what class was used and thus defaulted to muscle as the mainstat. It now will attempt to guess the class based on total stat gains in such cases.


QuantumNightmare wrote:By repeat drops, I mean the second giant needle you receive. The log parser has a list of drops that are only critical to display the first X times they are seen, which just helps reduce spam.

Good idea. Added. :)


stupac2 wrote:Another comment, on the turn rundown, a scrollbar at the bottom would be nice, so that we can move the turns over to get actually see what bars correspond to what. At later levels it's pretty difficult to tell what's actually going on.

Isn't this more or less covered by the zoom function of the charts? If not, please elaborate on why it is not the case. :)


stupac2 wrote:Also I'm not sure how to interpret the familiar data there, is it from one colored bar to the next?

The colored ranges show which familiars were used during those turns.


stupac2 wrote:Huh, also loading an already parsed log apparently borks all the stat info. Bug or feature?

If you mean parsed by the AFH parser, then it is neither (otherwise it's a bug). For those charts to work it is necessary to have stat gains from every adventure location and every consumable and that data simply isn't there in logs from the AFH parser. If there is a parameter that would include this data, I'd like to know it.


stupac2 from e-mail wrote:Also, could we have an easier way to close tabs?

This is not that easy to change in Java, because tabbed panes do not include that feature on default. I'd have to write it myself or see whether I find something on the internet. For now, this will stay low priority.


QuantumNightmare wrote:(I guess I mean, why recreate the internal parser to produce the exact same output as the afh log parser, when all these extra features already exist? It would be simple to edit the log parser to include the changes you've made, instead of reinventing the wheel.)

This might be a little longer ...

Back in September, when I decided to start working on the then still called Log Visualizer again, it was pretty clear that I would have to rewrite big chunks of it, because most of the code base was simply not really flexible and maintainable (the top two priorities for any software project) the way it was. Also, I wanted the program to be able to directly parse mafia logs, because I was getting annoyed by having to start Cygwin, needing to make changes to your parser based on whether I was running Windows or Linux, and other things. With this in mind, I started to work, and when I was finished all but a couple of UI classes were completely rewritten. From this point, it was pretty easy to add a textual output feature (needed less than a day to add it at that point). It was basically the logical next step.

Now, as to why I didn't try to include your parser instead of doing all this myself, well, first of all I liked the programmatic challenge it posed. Also, trying to somehow shoehorn the script into the program felt like introducing too much instability to me and lastly, I wanted to be able to make changes to the parsing mechanism if necessary and I'm not really that well versed in Perl for that to be feasible.

Please understand that I didn't write the program with the intention of going into direct competition with you (if that had been my goal, I would not have included a way to run your parser from inside the ALV), that particular featureset just kinda happened through natural evolution of the project. I admit that I did not refrain from adding it when it came to that point, but I do not see how one can blame me for it.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Thu Jan 29, 2009 8:28 pm

stupac2 from e-mail wrote:Also, could we have an easier way to close tabs?

I didn't get much feedback in the way of bug reports, so even though this was low priority, I ended up working on it. There is now a new beta version available that has little X's on the log visualisation tabs to close them.


Also, on the notion of new versions, I'd like to point towards the project feeds. Especially the Downloads feed should be interesting since it gives one the ability to stay up-to-date on the newest released versions while not having to constantly check the site or this thead. I thought I should throw this info out there in case people overlooked it on the site. :)

User avatar
Manendra
My Pie Blown Sky High
Posts: 663
Joined: Tue Apr 22, 2008 4:04 pm

Postby Manendra » Fri Feb 06, 2009 1:43 pm

Question: What is the expected turns value for the pyramid based on? I get the feeling that the reason it usually shows me having good RNG there is that it's based on the noncombats, but olfacting tomb rats is the trendy way to do that zone now, and is much quicker.

Also, on the Quest RNG page, there's a goofy-looking number by the pirates, and I'm not sure why. It's just with one of my logs, as far as I can tell, but it sticks around when I close and reopen the visualizer. screenshot here

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Feb 06, 2009 3:52 pm

Concerning the numbers of the QuestRNG chart, I'll first point towards the the documentation.

I think I did calculate the pyramid based on the noncombats, but I also think that numbers from farming tomb ratchets weren't that far away.

But this just makes it obvious that the QuestRNG chart doesn't use a good design, since this isn't the first time there were misunderstandings concerning that chart. I think it might be better to just remove the RNG ranges and simply display turns needed to finish the quests. There are simply too many variables that can change the expected turn count to use static values and calculating this dynamically is just not feasible in my opinion.

And about that screenshot (btw, you can save the charts as an image by using the right click menu), I don't see anything wrong with it ... Could you be more specific about what seems to be displayed incorrectly?

User avatar
Manendra
My Pie Blown Sky High
Posts: 663
Joined: Tue Apr 22, 2008 4:04 pm

Postby Manendra » Fri Feb 06, 2009 4:06 pm

Ah, ok, thanks for explaining the Quest RNG. I can see how it's difficult to come up with a good way to calculate that, and I do like the way it's shown now, but it might be more useful, as you said, to just show turns per quest. That would make it easier to compare run to run, as opposed to against the average.

The display is nothing big, its just that for the pirates quest, where it should say "10", it looks like it says -18 in a larger font than everything else. I edited the screenshot to point a big red arrow at it.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Feb 06, 2009 4:28 pm

Manendra wrote:Ah, ok, thanks for explaining the Quest RNG. I can see how it's difficult to come up with a good way to calculate that, and I do like the way it's shown now, but it might be more useful, as you said, to just show turns per quest. That would make it easier to compare run to run, as opposed to against the average.

Indeed, that was also my idea. (the possible comparison between different runs)

By the way, if anyone else wants to weigh in on this problem, please do.


Manendra wrote:The display is nothing big, its just that for the pirates quest, where it should say "10", it looks like it says -18 in a larger font than everything else. I edited the screenshot to point a big red arrow at it.

Ah, haha, ok. Those are two "10"s over each other not a big "-18". :D

I'm baffled that you saw the latter in it, but than again, everyone seems to see something different when he/she looks at a picture by M. C. Escher for the first time. ;)

User avatar
Manendra
My Pie Blown Sky High
Posts: 663
Joined: Tue Apr 22, 2008 4:04 pm

Postby Manendra » Fri Feb 06, 2009 4:36 pm

haha, wow. :oops:

I guess that's what I get for staring at that thing for too long. :P

VladimirPootin
AFH
Posts: 1236
Joined: Tue Mar 27, 2007 2:03 am
Location: Ad Absurdum

Postby VladimirPootin » Fri Feb 06, 2009 7:00 pm

woot woot the flolle is back
AFH: Now with more new and improved moral ambiguity!

User avatar
KujjieKujjieKoo
Spade Ninja
Posts: 2240
Joined: Mon Apr 30, 2007 8:50 pm
Location: !Chicago
Contact:

Postby KujjieKujjieKoo » Mon Feb 09, 2009 1:20 pm

As a general question... there are many people who don't use mafia, but keep logs by hand. Is there a quick format method they could use for their hand written log, which would allow them to use this program? More specifically... what key information / formating should be included to ensure the program operates as expected? Do zone names need to match as mafia records them, etc?
Image

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Mon Feb 09, 2009 5:12 pm

First, to be absolutely clear, I do not officially support handwritten logs. There are far too many things a human can get wrong such as incorrect format (and be it a whitespace where one shouldn't be), misspellings, wrong numbers and so on. So, if someone makes a handwritten log and the program chokes on it, as hard as it sounds but tough luck.

So, now that that is established, if one wants to write the log by hand I assume it is a log with a format similar to what the AFH parser uses, because trying to emulate what KolMafia does would be madness and almost guaranteed to not work.

The most important part of the turn rundown log of a pre-parsed run log (aka AFH parser format) is the adventure area. All other information is tagged to those areas. Or, if there was no interesting information, there isn't anything tagged to it. Area names should be logged like KolMafia does, otherwise the Quest Turns chart might end up not working. Most important, what is not possible, under no circumstances what-so-ever, is to log the turncounts by turns left. Always log by turns used as it is stated on the character sheet, otherwise the parser will output complete gibberish.

Quest item drops should be be logged with exactly the same name as used by KolMafia, otherwise there might be problems with the Quest Turns chart. I recommend to log other items/consumables also with the format used by KolMafia, but that won't screw a chart up that much if not done.

Empty lines in the turn rundown log are not a problem as are all possible orders of those lines, in fact all lines that are not recognised as an information line are no problem at all (just make them different by using say "//" at the start). In summaries that is however not the case and one should hold to the format used in those.

If one doesn't want to log certain things such as semi-rares or consumables, that is fine and no problem. Just don't complain if the information is later missing in the charts or summaries.

What kind of information lines are possible and the format of them is described below. Variables are written as underscore, variable name in camel case, underscore (_testExample_). Those variables should be replaced by the actual information needed when writing the log. What that information is should be pretty obvious through the variable name.

Summaries are not explained here, but it should be really obvious how those are made by looking at an example or two.

Sorry if this seems to be a rather cumbersome way to log, but if one wants to do it right, one has to use a certain format and adhere to it at all times. There is no way around it.

Code: Select all

=Adventure strings=
[_turnNumber_] _areaName_ [_mus_,_myst_,_mox_]
OR
[_startTurn_-_endTurn_] _areaName_ [_mus_,_myst_,_mox_]

The stat gains can be omitted if you don't want to include them.

Note that the stat gains should not include stat gains from consumables, since those have their own stat gain notation.

Do not leave trailing whitespace after the area name whether there are stat gains or not.

The first adventure area should always be "[0] Ascension Start" and all actions done before a turn was spent should be tagged to that adventure area.


=Item drop=
+> [_turnNumber_] Got _itemName_
OR
+> [_turnNumber_] Got _itemName_, _itemName_
OR
+> [_turnNumber_] Got _itemName_, _itemName_, _itemName_
OR
And so on ...


=Consumable=
o> Ate _numberOfConsumables_ _nameOfConsumable_ (_adventureGain_ adventures gained) [_mus_,_myst_,_mox_]
OR
o> Drank _numberOfConsumables_ _nameOfConsumable_ (_adventureGain_ adventures gained) [_mus_,_myst_,_mox_]
OR
o> Used _numberOfConsumables_ _nameOfConsumable_ (_adventureGain_ adventures gained) [_mus_,_myst_,_mox_]
OR
o> Used _numberOfConsumables_ _nameOfConsumable_ [_mus_,_myst_,_mox_]

The stat gains can be omitted if you don't want to include them.


=Familiar change=
-> Turn [_turnNumber_] _familiarName_

It is better to log the turn on which the familiar was changed (what the ALV does), than to log the turn on which the newly equipped familiar was first used (what the AFH parser does) for the reason that the latter may result in problems with the familiar statistics (the reasons are internal usage of those numbers).


=Day change=
===Day _dayNumber_===


=Semi-rare=
#> [_turnNumber_] Semirare: _semirareName_


=Bad Moon=
%> [_turnNumber_] Badmoon: _badmoonAdventureName_


=Hunted combat=
*> [_turnNumber_] Started hunting _combatName_


=Pulls=
#> Turn [_turnNumber_] pulled _amount_ _itemName_


=Navel Ring usage=
&> _successfulAttempts_ / _totalAttempts_ free retreats

User avatar
QuantumNightmare
AFH
Posts: 1827
Joined: Mon Jan 29, 2007 10:28 pm
Location: Montreal

Postby QuantumNightmare » Mon Feb 09, 2009 7:23 pm

Flolle wrote:Concerning the numbers of the QuestRNG chart, I'll first point towards the the documentation.

The easiest way to do this properly is to read in the skills and familiars a player has available, and calculate the expected length of each quest per player. Adjust numbers for key pulls (RoC, monster bait, eyedrops, inhaler).

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Mon Feb 09, 2009 8:19 pm

That would leave out free runaways (through whatever means), the ball room song and encounter probability altering items (deo-/reodorant). And this doesn't even touch +item or +meat, for which there are a bazillion different modifier altering effects, items and skills for. Also, this wouldn't work with pre-parsed logs.

The numbers given could still very well be pretty incorrect and I'd rather give no numbers than (by unknown margins) incorrect ones. Yes, I realise that I shouldn't have put the chart in in first place based on that argument (and I wonder how I could be so careless by adding it), but that's why I said this is beta software, because things are still in flux and tend to change with user input.


If there are other arguments on this topic, keep 'em coming, the above is by no means a definitive decision (it will be if nothing else is raised though).

salien
Pie in the Sky
Posts: 115
Joined: Fri Jan 11, 2008 1:50 pm

Postby salien » Tue Feb 10, 2009 3:33 pm

One alternative might be to give users an option to sumit their quest turns data to a central database; if stored along with stuff like number of skills, equipment pulls, familiars used, ascension type and duration, etc., you could eventually make all kinds of neat comparative charts out of that data.

Actually... I wonder if you could partner with Oxbarn, to allow people to submit that kind of data to his database? It obviously wouldn't be available for every ascension unlike the rest of the data he has, but if enough people do it there's some cool stuff you could do with that.

User avatar
KujjieKujjieKoo
Spade Ninja
Posts: 2240
Joined: Mon Apr 30, 2007 8:50 pm
Location: !Chicago
Contact:

Postby KujjieKujjieKoo » Thu Feb 12, 2009 8:38 am

Re: Determining what class you are (which may have come up in another thread...)

The rewards for the 1st guild challenge vary based on your class.

SC: 2 enchanted barbells, giant moxie weed
TT: 2 enchanted barbells, concentrated magicalness pill
PM: 2 concentrated magicalness pills, enchanted barbell
SA: 2 concentrated magicalness pills, giant moxie weed
DB: 2 giant moxie weed, enchanted barbell
AT: 2 giant moxie weed, concentrated magicalness pill
Image

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Thu Feb 12, 2009 7:43 pm

I made a new beta release which - barring any serious bugs - will be the last one before I tackle release 1.0.0. :)

Many changes went in, among them the before mentioned removal of the QuestRNG chart in favour of the more simple but also more reliable Quest Turns chart, tracking of a couple of "broken" adventure areas (broken in the sense that KolMafia doesn't log those with the standard turn spent format), optional parsing of gCLI notes and tracking of Navel Ring usage. For a full summary of all changes, I'll point to the SVN log which is viewable from the project website by clicking Source->Changes.


salien wrote:One alternative might be to give users an option to sumit their quest turns data to a central database; if stored along with stuff like number of skills, equipment pulls, familiars used, ascension type and duration, etc., you could eventually make all kinds of neat comparative charts out of that data.

Actually... I wonder if you could partner with Oxbarn, to allow people to submit that kind of data to his database? It obviously wouldn't be available for every ascension unlike the rest of the data he has, but if enough people do it there's some cool stuff you could do with that.

While I can see the value in tracking such data, I can also see some problems, which make it seem not worth the hassle. First, I do not have access to a server and while there are free hosting sites, I think using them for something like this wouldn't be the ideal solution. Second, I'd have to go to relatively great lengths to make sure that people don't submit fake data or the same data more than once (one thing one learns after playing this game for three years is that there are always people willing to abuse the system for whatever reason).

And as far as Oxbarn's site goes, I actually don't think he would necessarily need me for that. As of the current beta, a quest turns summary is included in the textual log output, so he could just open up the site to ascension log submissions and generate that data from those logs. Plus, not only being able to look at the ascension histories but also at the run logs would be badass. Obviously though, he would have the same problem of making sure the submitted data is actually valid (which I consider non-trivial to say the least, we are after all talking about text files here and those are easily edited).


KujjieKujjieKoo wrote:Re: Determining what class you are (which may have come up in another thread...)

The rewards for the 1st guild challenge vary based on your class.

SC: 2 enchanted barbells, giant moxie weed
TT: 2 enchanted barbells, concentrated magicalness pill
PM: 2 concentrated magicalness pills, enchanted barbell
SA: 2 concentrated magicalness pills, giant moxie weed
DB: 2 giant moxie weed, enchanted barbell
AT: 2 giant moxie weed, concentrated magicalness pill

Very good thinking, and not hard to check for me too! I added it. :)

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sat Feb 14, 2009 6:36 pm

I think I've found a bug. On the "Turn Rundown Gantt" tab, when you hover over a block of turns, it shows the duration as being the first turn spent in that zone to the last, even if you were in other zones between. So if on turn 30 you went to the 8 bit realm, then putty'd a blooper for 5 turns, then went back until turn 41, it would say "8-Bit Realm 30-41" on both blocks, even though one is 30-34 and the other is 39-41 (or whatever). That might be the intended behavior, but I somewhat doubt it.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sat Feb 14, 2009 8:21 pm

No, it isn't intended behaviour, but it is how the underlying chart library works - at least it's tool tip generator. I assume you would like to have the tool tip only show the interval numbers of the subinterval over which the mouse pointer currently hovers. As far as I can tell, that feature isn't supported in the library and I'm unsure how deep I'd need to dig to implement it myself. From taking a quick look, I'd say pretty deep, which always means possibly breaking existing functionality on the way. This doesn't seem like enough of a problem to warrant such work, so just take the tool tip to show the first and the last turn spent in an adventuring area, not the actual interval range.


(please don't take it personal that I shot down the request, I simply try to honour this at least to a certain degree.)

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Sat Feb 14, 2009 8:28 pm

Nah I understand, it happens. Though it seems like you could create an array with that info in it, I really have no idea how hard it would be. If it'd be too hard, then it's too hard.

User avatar
BC_Goldman
My Pie Blown Sky High
Posts: 499
Joined: Tue Jul 22, 2008 9:44 pm
Location: New Jersey

Postby BC_Goldman » Sun Feb 15, 2009 12:30 am

Heh, I wish I had found this before I spent the last two hours working on installing the Perl stuff listed in the other sticky. It would have saved me a great deal of frustration.

This script is awesome, I really like the visualizer aspect.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sun Feb 15, 2009 3:43 am

stupac2 wrote:Nah I understand, it happens. Though it seems like you could create an array with that info in it, I really have no idea how hard it would be. If it'd be too hard, then it's too hard.

Heh, yeah sorry, but that's not really how it works. ;)

Accessing the data is not the problem, it's subclassing and overwriting the right classes and methods to make the tool tip generators do what I want them to do.

Also, on a fairly offtopic sidenote, in 99% of all cases it's better to use dynamic data structures such as lists in a managed language such as Java. They are easier to handle and it's rather unlikely that using them ends up being the performance bottleneck.


BC_Goldman wrote:Heh, I wish I had found this before I spent the last two hours working on installing the Perl stuff listed in the other sticky. It would have saved me a great deal of frustration.

This script is awesome, I really like the visualizer aspect.

Thank you. Not needing to have a Perl runtime environment installed to use the program was one of the considerations I made when I decided to implement my own parser instead of using the existing AFH MafiaLog Parser.

And this is more a syntactic thing, but this program is not a script. Neither language used, size nor scope of the ALV fit that description. ;)

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Feb 20, 2009 7:44 pm

Seeing as there were no actual bug reports on the current beta, I'll have to assume that there are no glaring bugs/problems with the program. Also, I finished most of the refractoring I wanted to get done. So, seeing as there is pretty much nothing else to do, I guess it is time to tackle version 1.0.0 after one last thing:

I'm wondering whether people miss some itemdrops from the textual log and would like them to be included in the future. If there are in your opinion such items, please post a list of them.

For reference, the currently included itemdrops are:
always shown itemdrops
itemdrops only shown on their first drop

Please note that the intention here is to include as many ascension relevant drops as possible while trying to not spam the textual log up too much.

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Tue Feb 24, 2009 2:47 pm

One thing I've noticed is that pulls and consumption happening at the beginning of day 2 (or later) are presented in the log as having happened at the end of the previous day.

It's not a major issue, but since nobody seems to be reporting major issues... :)

Also, thanks for implementing the free retreat counter, it's really nice.

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Tue Feb 24, 2009 2:49 pm

In a similar vein I've had a few cases where two "days" were played on the same calendar day and not getting a separation on the rundown and having all the pulls lumped together on the same day. Not sure if that's fixable or been fixed though, I haven't been doing real runs as frequently and my last one didn't fit that criterion.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Tue Feb 24, 2009 5:24 pm

desatysso wrote:One thing I've noticed is that pulls and consumption happening at the beginning of day 2 (or later) are presented in the log as having happened at the end of the previous day.

Well, the actions happened on the turn which was started the day before, which is why they are tagged to it.

Currently, the day on which consumables were used is not saved and would result in a couple of non-trivial internal changes if I wanted to do it right. Which is why I didn't change how consumables are displayed in these cases.

Pulls are handled differently and this was relatively easy to change for them, so I added it.

If leaving consumables usage display the way it is is really seen as a big enough problem that it should be fixed, I could take another look at it. However, I am personally not of the opinion that it is. This doesn't mean that I can't be persuaded by good arguments though. :)


stupac2 wrote:In a similar vein I've had a few cases where two "days" were played on the same calendar day and not getting a separation on the rundown and having all the pulls lumped together on the same day. Not sure if that's fixable or been fixed though, I haven't been doing real runs as frequently and my last one didn't fit that criterion.

If this happens (mafia keeps logging in the wrong session log file), it can only be recognised if you have the KolMafia logging option Session log records your player's state on login checked (basically, the log has to contain player snapshots). If that option is not checked, there is no way to recognise these day changes.

If your session log contains player snapshots, but these day changes are not recognised it would mean there is a bug.

User avatar
NardoLoopa
Market Manipulator
Posts: 1201
Joined: Tue Jun 19, 2007 10:37 pm

Postby NardoLoopa » Tue Feb 24, 2009 7:33 pm

Re: day changes

I believe I had this option set, but the VisLog didn't recognize the change of day. However, MafiaLogParser.pl did recognize the change of day. Might mine that code for the secret.

Sorry, i didn't save the files for you to examine.
Image

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Wed Feb 25, 2009 6:37 am

NardoLoopa wrote:Re: day changes

I believe I had this option set, but the VisLog didn't recognize the change of day. However, MafiaLogParser.pl did recognize the change of day. Might mine that code for the secret.

Sorry, i didn't save the files for you to examine.

From what I can tell, both programs use the same mechanism to figure this specific problem out, namely looking at the date line in a player snapshot and compare the listed KoL date with one from a previous snapshot of the same day. Not much of a surprise given the fact that it is the only place in session logs that gives actual dates, be it real life or KoL ones.

Did you by chance use Beta 1 of the ALV when noting the discrepancy between it and the AFH parser? Because that wouldn't be surprising since I added recognition of the date problem after Beta 1.

Also, without a test case that gives me at least an idea about where I should look, I cannot act; even if it were the case that there still exists a bug in the date recognition.

User avatar
stupac2
Oh my! Guy with Pie!
Posts: 3027
Joined: Mon Dec 08, 2008 10:04 pm
Location: Stanford, CA
Contact:

Postby stupac2 » Wed Feb 25, 2009 9:22 am

I just recreated this scenario (starting a run before rollover, playing all of day 2 after rollover but before the next calendar day) and it seems to handle it fine now. Pulls a separated and there's a line for day 2 on the rundown. I guess the problem was only with an earlier version, or I didn't have that setting checked.

User avatar
NardoLoopa
Market Manipulator
Posts: 1201
Joined: Tue Jun 19, 2007 10:37 pm

Postby NardoLoopa » Wed Feb 25, 2009 9:31 am

Flolle wrote:Also, without a test case that gives me at least an idea about where I should look, I cannot act; even if it were the case that there still exists a bug in the date recognition.


Yeah, I realize it's not very helpful, thus my initial apology.

It was Beta3. And the log files were generated on Linux mostly (\n), though some were on Windows (\r\n). Not sure if that had anything to do with it. The Vis was run on Windows against those log files. mafialLogParser was run on linux.

So yeah, too many variables to be more than just frustration.
Image

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Wed Feb 25, 2009 10:14 am

NardoLoopa wrote:Yeah, I realize it's not very helpful, thus my initial apology.

No problem, I just wanted to explicitly state that test cases are a very important thing when trying to track down bugs.


NardoLoopa wrote:It was Beta3. And the log files were generated on Linux mostly (\n), though some were on Windows (\r\n). Not sure if that had anything to do with it. The Vis was run on Windows against those log files. mafialLogParser was run on linux.

So yeah, too many variables to be more than just frustration.

I'm pretty sure that line separators are not the problem, because the file and stream readers of Java are very good at correctly recognising lines and their EOL characters, no matter the OS. And personally, I switch around between Windows and Linux very often and have yet to see a problem with bad recognition of EOL characters in the Ascension Log Visualizer.

So, this basically means that one cannot further analyse this potential problem from current knowledge. But if someone manages to step over a day count problem in the future and can reproduce it with their logs, I'd like to hear about it.

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Wed Feb 25, 2009 11:00 am

Flolle wrote:If leaving consumables usage display the way it is is really seen as a big enough problem that it should be fixed, I could take another look at it. However, I am personally not of the opinion that it is. This doesn't mean that I can't be persuaded by good arguments though. :)


This is a much smaller issue in softcore, I think, where diets tend to be pretty similar (pie, pie, and more pie, washed down with peppermint schnapps and bungles), but I think a nice visual breakdown of stomach/liver/spleen usage by day would be pretty handy for hardcore. I can usually remember these things if I'm looking at a log right after the run, but if I want to compare two or more ascensions, having a graph would be really handy.

Maybe people who play hardcore more than me would chime in? (I'm about to start some HC runs, but don't have a lot of experience yet).

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Wed Feb 25, 2009 2:36 pm

That sounds interesting, but I think you should go into more detail. Could you be more specific on what kind of charts you would like to have added and what kind of data they should hold?

Please understand that this is nothing personal and that I'm not trying to put you off through bureaucratics, but:
Opening post wrote:[...] Also, if you have a feature suggestion, you should be able to describe how it should look in the end. For example, if you want an additional chart to be added, you should be able to tell me what data should be found in it and what the chart should look like.

The reason being this and the simple fact that if someone makes a proposal that would take 2+ hours to implement (+ whatever it may require in the future to maintain it) better lives with me requiring a certain amount of work put into the proposal. ;)

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Wed Feb 25, 2009 3:19 pm

Sure thing :). At the moment, I'm going to include every piece of information I can think of that would be useful, since I don't know what particulars are difficult to parse out.

For each day, a bar chart that shows Stomach, Liver, and Spleen usage for the day. Each organ is represented by a segmented vertical bar, with each segment representing a single consumed item, sized proportionately to the amount of fullness it consumes. Items consumed earliest in the day are shown at the bottom of the appropriate stack, with each subsequent consumable displayed above them. Any unused space in the organ would be the represented at the top of the bar, grayed out. Ideally, each bar would be scaled the same (so that you can clearly discern which Organ of Steel, if any, you have), and (without Liver of Steel), the liver bar would be slightly shorter than the others if a nightcap was not consumed (and would extend appropriately to the drunkenness post-nightcap).

Each item should be separated from others of its kind by a bold black line, and have text indicating the name of the item consumed and the adventures it produced. It should be colored in subsections according to the distribution of substats it granted (so if it granted 15 chutzpah and 30 strengthliness, it would be colored 2/3 red and 1/3 green, with no line between the colors), and preferably have mouseover text indicating the exact substat distribution. If it's reasonable to do so, mouseover text should also indicate whether Milk, Munchies Pills, Ode, or any other enhancer was used (though Milk and Ode are probably the only important ones).

That help?

User avatar
MonsterERB
AFH
Posts: 895
Joined: Wed Aug 06, 2008 9:58 am
Location: St. Louis, MO (USA)

Postby MonsterERB » Wed Feb 25, 2009 3:54 pm

desatysso: That's a great idea, for both HC and SC. I would add that, if adventure gains and stat gains for each consumed item were displayed on mouseover, that would be TREMENDOUS.
Image

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Wed Feb 25, 2009 4:02 pm

MonsterERB wrote:desatysso: That's a great idea, for both HC and SC. I would add that, if adventure gains and stat gains for each consumed item were displayed on mouseover, that would be TREMENDOUS.


desatysso wrote:Each item should be separated from others of its kind by a bold black line, and have text indicating the name of the item consumed and the adventures it produced.


My thought was that adventures produced would be the kind of thing that most people would want to see right away (hence, putting it right next to the consumption name), whereas substat distribution is both more "nerdy" and more clutter, so it makes more sense for mouseover.

Another thing: below each bar, show adventures gained per unit fullness for the day, in the following format: #adv/#full (#avg). For example, eating two Hell Ramen for a total of 53 adventures would display under the stomach bar 53 adv/12 full (4.42 avg).

EDIT: In case it wasn't clear, adding a Boring Spaghetti to the above for 7 more adventures would result in 60 adv/15 full (4 avg).

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Thu Feb 26, 2009 12:29 pm

desatysso wrote:That help?

Very much so, thanks! It's now much easier for me to understand what your actual proposal is. :)

I think your proposal is pretty nice and I'm inclined to implement something along those lines. If others want to chime in on some of the specifics though, it would be greatly appreciated.

That being said, I think the charting tool I'm using may not support some of the subfeatures you are proposing. I'll have to look at stuff in more detail to make a more definitive statement on that though. If you want to check it out yourself, look at the demo on this page to see what stuff the library is able to do. Please note that I'm consciously limitting myself to what that library can do, because writing my own library to handle charts would result in too much maintenance work to be worth it in my opinion.

However, looking at what adding this feature may entail, I think I'll refrain from implementing it right now. I was already in kind of a feature freeze for anything more than very small changes to the source, and implementing this looks to me to be anything but very small. This doesn't mean that I'll put it off until forever, just that instead of making it into 1.0.0, which I plan to release pretty soon, it'll probably be in 1.1.0. I went with release early, release often up to now, and I think it worked out pretty well, so I believe continuing with it is the right choice.

Does that sound OK? :)

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Thu Feb 26, 2009 12:53 pm

Flolle wrote:
desatysso wrote:That help?

Very much so, thanks! It's now much easier for me to understand what your actual proposal is. :)


Excellent!

Flolle wrote:That being said, I think the charting tool I'm using may not support some of the subfeatures you are proposing. I'll have to look at stuff in more detail to make a more definitive statement on that though. If you want to check it out yourself, look at the demo on this page to see what stuff the library is able to do. Please note that I'm consciously limitting myself to what that library can do, because writing my own library to handle charts would result in too much maintenance work to be worth it in my opinion.


Being a Developer by trade, I completely understand :) Even a relatively small subset of the functionality would, IMO, be pretty handy.

Flolle wrote:However, looking at what adding this feature may entail, I think I'll refrain from implementing it right now. I was already in kind of a feature freeze for anything more than very small changes to the source, and implementing this looks to me to be anything but very small. This doesn't mean that I'll put it off until forever, just that instead of making it into 1.0.0, which I plan to release pretty soon, it'll probably be in 1.1.0. I went with release early, release often up to now, and I think it worked out pretty well, so I believe continuing with it is the right choice.

Does that sound OK? :)


That sounds great!

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sat Feb 28, 2009 4:37 am

After mentioning it a couple of times that I wanted to get it out soon, here it is: Ascension Log Visualizer 1.0.0! :)

Changes from the last beta include, but are not limited to:
- Additional information being printed into textual logs on day changes
- Fixes to the familiar usage counting
- Meat gains from the Nuns are now ignored for total meat gain
- A new Spooky Putty usage tab in the Misc section
- Updates to the itemdrops shown in the textual log
- Stats per turn per level in the LEVELS summary

As always, check the SVN log if you want a more detailed list.

Anyone who used any of the beta versions should on the first startup of this release recreate the data files through Extra->Recreate data files and then restart the program. If you made manual changes to the files, you will have to add them again afterwards. Anyone who didn't use the beta versions is not affected by this.

Since this is the very first non-beta release, I strongly recommend to anyone who used a beta version to update to version 1.0.0.

Also, even though this isn't beta software anymore, I'd appreciate it if people continued to mentioned it if they noticed incorrect behaviour of any part of the Ascension Log Visualizer.

User avatar
Fred Nefler
AFH
Posts: 812
Joined: Sat Jan 17, 2009 5:47 pm

Postby Fred Nefler » Sat Feb 28, 2009 6:03 am

Neat. I was just coming by to say that the beta4 was counting using my parrot for DD resist tests towards familiar percentage (or to see if that had already been reported), and about how I was having an issue with my day 2 not being recognized as day 2.

The 1.0 version fixed that familiar issue, and after looking at my mafia logs I see mafia, for some reason, did not correctly record the in-game date on my second day. Manually changing that seems have made everything all better now.

Perhaps any existing/lingering day issues are from similar mafia misbehaviors? If so, perhaps you could add a sort of band-aid workaround by checking for certainly daily activities being repeated, especially standard "breakfast" activities. Like in my log you can see at the start of (the true) day 1 that I visited the Mr. Klaw, and on the fake day 1 that was really day 2 I also visited the Mr. Klaw. I can't recall at the moment if Mafia records manual visits to the Klaw after the breakfast routine; if it does I suppose that could cause a problem. But maybe then your parser could give some sort of indication that there may be an incorrectly recorded day in your log, rather then just assuming that a new day has started that wasn't properly recorded.

Not sure if this could possibly cause problems in the reverse order, if say mafia sometimes records the day as one ahead of what it should be, but for whatever reason I feel that is significantly less likely than it recording the day as one behind.

EDIT:
I seem to have found one error in the parser. In my log for today, this is the turn I made it to level 11:

Code: Select all

[801] Haunted Gallery
Encounter: Louvre It or Leave It
choice.php?whichchoice=91&option=1&pwd
Encounter: Louvre It or Leave It (Escher: Relativity)
choice.php?whichchoice=92&option=1&pwd
Encounter: Louvre It or Leave It (Munch: The Scream)
choice.php?whichchoice=97&option=1&pwd
Encounter: Louvre It or Leave It (Seurat: Sunday Afternoon on the Island of La Grande Jatte)
choice.php?whichchoice=102&option=2&pwd
You gain 300 Fortitude
You gain some Muscle points!
You gain a Level!
You acquire an item: giant discarded bottlecap

But the parser claims I hit level 11 at turn 810 (by which point I had already completed the black forest for the level 11 quest and gotten my diary).

Adventure 810 was a witty pirate (at which point I gained a mysticality point; I'm a Seal Clubber), and 811 was the swordfish adventure.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sat Feb 28, 2009 8:22 am

I can see how not having day changes properly recognised can be annoying, but I cannot catch every possible error that the session logs may contain. At some point I have to draw the line and as far as day change recognition goes, the line is reached. Because, let's face it, these things are not errors of the ALV not working properly, but of KolMafia simply having problems with its logging mechanisms and I'd rather have this stuff fixed in KolMafia than me putting more and more band-aids into my program (which would be all for nothing if mafia's devs fix this stuff).

And concerning the level problem: It's a bit hard to diagnose this particular problem from afar, but stat counting can be off if the session log is missing some stat gains (or the parser is being faulty by missing them). Could you check before the first level that was off by some turns whether there are some stat gains missing in the session log, be it from adventures or consumables or something else?

Also, since when do session logs contain level gains? I swear to god, they didn't have them last month. D:

User avatar
Fred Nefler
AFH
Posts: 812
Joined: Sat Jan 17, 2009 5:47 pm

Postby Fred Nefler » Sat Feb 28, 2009 5:46 pm

Flolle wrote:Also, since when do session logs contain level gains? I swear to god, they didn't have them last month. D:

Uh, I dunno. I've mostly been using mafia for level 35+ characters that do spading work, so level ups are few and far between. They've been in my logs since the start of this run, though, I can confirm that much.

Flolle wrote:Could you check before the first level that was off by some turns whether there are some stat gains missing in the session log, be it from adventures or consumables or something else?

I'm on it. Looks like it was fine up through level 9, but was off by 7 turns for when I hit level 10.

Looking at what happened after level 9, I think the problem is that there is no record of the stat gains for the secret word in the leaflet. The item acquisitions are in my mafia logs, but there's nothing in there concerning the secret word gains. And there is, consequently, no record of it in the visualizer presumably. It'd have to be guessing, otherwise.

Flolle wrote:I can see how not having day changes properly recognised can be annoying, but I cannot catch every possible error

That's fine. I was kind of expecting that. Looks like there are other day errors in the logs. This must be a result of me logging in very soon after rollover or something. I'll report it on the mafia forums and see what can be done about.

I'm using sticker summons to track down the erroneous days. Well, the bulk of them anyway. Should be able to figure out the rest from that and my memory of when I did things in the run (as well as booze/food consumption).

EDIT:
Okay, I think I found a parser-specific bug.

My day 3 occurs over 2 real-life calendar days. I started the run just after rollover, but logged out because of some image loading lag issues, and when I logged back on it was past midnight my time and the date changed.

In both logs, the player snapshots on my log-ins for day 3 correctly record the KoL date as Frankruary 1. Moon phases are also shown correctly. However, for the part of the log that records the real-life calendar date as February 23, the parser is placing the events under day 2 (Jarlsuary 8). And those with calendar date of February 24 are placed under day 3.

There is one mafia-specific error here in that the logs also change how many days there are until the holidays come up, but I assume your parser isn't using those.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sat Feb 28, 2009 6:35 pm

Leaflet stat gains are pretty high, so if they are missing it may be the source of the problem. You could try adding them in yourself and see whether it fixes the level turncount. You have to be careful to use the same format for stat gains as mafia though.

(If you're OK with it, you can also send the log to me to check it for problems. You can find my e-mail address in the license notes in the ALV.)


Edit due to your edit: OK, that sounds interesting. Now I'm really interested in the log. Would it be a problem to send all the session logs of that run to me so I can test this in detail?

User avatar
Fred Nefler
AFH
Posts: 812
Joined: Sat Jan 17, 2009 5:47 pm

Postby Fred Nefler » Sat Feb 28, 2009 6:48 pm

Flolle wrote:Edit due to your edit: OK, that sounds interesting. Now I'm really interested in the log. Would it be a problem to send all the session logs of that run to me so I can test this in detail?


Not a problem at all. I'll send them shortly.


And adding in the leaflet gains fixed the level recording problem.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Sun Mar 01, 2009 10:46 am

Alright, your problems should be fixed now as far as I can tell, and the fixes are included in version 1.0.4 which I just pushed out.

I recommend to anyone to update to the new version because it contains a fix for an incorrect gregorian calendar handling bug I had in the program.

User avatar
Fred Nefler
AFH
Posts: 812
Joined: Sat Jan 17, 2009 5:47 pm

Postby Fred Nefler » Sun Mar 01, 2009 5:36 pm

Flolle wrote:Alright, your problems should be fixed now as far as I can tell, and the fixes are included in version 1.0.4 which I just pushed out.

I recommend to anyone to update to the new version because it contains a fix for an incorrect gregorian calendar handling bug I had in the program.

Yep, a quick clance through the parsed logs shows no obvious problems or any of the previous ones. Thanks.

zomg
Spy vs. Pie
Posts: 98
Joined: Sat Jul 05, 2008 11:39 pm
Location: Bottom o' the boards.

Postby zomg » Mon Mar 09, 2009 4:42 pm

Just used it. Man, it's awesome. Thanks Flolle. :D

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Tue Mar 31, 2009 10:27 pm

It's been a while since I last released a new version, but since this was supposed to be a new minor release and not just simply a bug fix release, I had a couple more points on my todo-list than usual. Also, there was this contest that took some time to actually play through, and even more mental and emotional energy out of me. Also also, I wanted to have at least a little bit from my holidays. Anyway, here it is: Ascension Log Visualizer 1.1.0

Changes from the last version include, but are not limited to:
- A per day consumption statistics chart was added*
- The day on which a consumable was consumed is now properly recognised
- The stat gains per turn per level from the textual log now also have a chart
- A couple smaller things, features and bug fixes alike

As always, check the SVN log if you want a more detailed list.

Anyone who used any of the previous releases of the ALV should on the first startup of this release recreate the data files through Extra->Recreate data files and then restart the program. If you made manual changes to the files, you will have to add them again afterwards.

Since there were a couple of features added with this release (which usually results in a far higher likelihood of breaking things), I'd appreciate it if any observed problems would be reported. Only known bugs can be fixed after all. :)


*Directly addressing desatysso here: I tried to add this as close as possible to what you proposed while staying inside the confines of the tools I'm using. Hopefully it looks at least partly like what you envisioned.

User avatar
desatysso
Inscrutable Pi
Posts: 386
Joined: Wed Feb 18, 2009 11:37 am

Postby desatysso » Wed Apr 01, 2009 9:39 am

Flolle wrote:Directly addressing desatysso here: I tried to add this as close as possible to what you proposed while staying inside the confines of the tools I'm using. Hopefully it looks at least partly like what you envisioned.


Hey, that looks pretty good! It doesn't look to account for tavern drunkenness (and presumably pirate drunkenness), but I didn't think to put that in my request so I shouldn't be surprised.

I'm gonna go have some fun with this :)

ADDED: The visualizer seems to be tracking each of KoLMafia's Player snapshots as a new day, even though the recorded dates (both RL and KoL dates) are the same for each.

I can post log data directly if you need it, but assuming it's not a fluke you should be able to reproduce it just by logging in and out (through mafia) several times.

MORE: I've also noticed that tropical and fruity girl swill didn't show up on the chart, even though they show up in the parsed log.

User avatar
Elayne
My Pie Blown Sky High
Posts: 504
Joined: Thu May 08, 2008 3:19 am

Postby Elayne » Wed Apr 15, 2009 2:03 am

I don't know what happened, but for some reason, after today's run on a multi, I can't seem to parse the log anymore (the previous ones work, btw). I don't know if it was due to some weirdness that happened in the pyramids as my turns were about to run out.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Wed Apr 15, 2009 9:27 pm

desatysso wrote:ADDED: The visualizer seems to be tracking each of KoLMafia's Player snapshots as a new day, even though the recorded dates (both RL and KoL dates) are the same for each.

I can post log data directly if you need it, but assuming it's not a fluke you should be able to reproduce it just by logging in and out (through mafia) several times.

MORE: I've also noticed that tropical and fruity girl swill didn't show up on the chart, even though they show up in the parsed log.

Hah, saw these edits only now. They weren't there when I read the post and nobody posted for some time, so I didn't look into this thread.

Either way, problem 1 was fixed relatively fast because someone else also reported it and problem 2 has been amended just now with version 1.1.2. :)


Elayne wrote:I don't know what happened, but for some reason, after today's run on a multi, I can't seem to parse the log anymore (the previous ones work, btw). I don't know if it was due to some weirdness that happened in the pyramids as my turns were about to run out.

Hmm, interesting. Could you test whether any exceptions are thrown when you try to parse that log? And if anything is thrown, could you post the whole stacktrace that's printed in such a case?

You'll have to start the ALV from a command prompt with java -jar to see the exception stacktrace print-out.

User avatar
Elayne
My Pie Blown Sky High
Posts: 504
Joined: Thu May 08, 2008 3:19 am

Postby Elayne » Thu Apr 16, 2009 6:07 am

Flolle wrote:Hmm, interesting. Could you test whether any exceptions are thrown when you try to parse that log? And if anything is thrown, could you post the whole stacktrace that's printed in such a case?

You'll have to start the ALV from a command prompt with java -jar to see the exception stacktrace print-out.


Uhm, can I have that in layman's terms? The only thing I understood is the phrase "parse that log." If it's going to be easier for you, I can zip the whole ascension files. It's just three days anyway (today's the fourth, and I haven't played yet).

On a side note, maybe if I sent you the files, you'd see if the weird thing that happened in the pyramids might have caused it (although I don't see how it could).

Edit: I'm using 1.1.1. Will try to see if anything changes in 1.1.2. I'll update this post later, as soon as I can download the new version.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Thu Apr 16, 2009 7:34 am

Sure, if it's easier for you, just send me the problematic ascension. My e-mail address is mentioned in the ALV license comments. :)

Also, updating the version won't help, because I only updated the consumable tables and nothing else.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Thu Apr 16, 2009 12:48 pm

OK, version 1.1.3 is out and should be able to handle your log without problems. Your log contained a corner case that I had neglected to handle. This means that there was no apparent error in your log (at least nothing that would break the parsing), but simply a bug in the ALV. :)

I'm not really sure what happened in the Pyramid there for you, but maybe KolMafia had a problem or something (maybe due to lag)?

Also, the two muscle days are lumped together, because - as you correctly assumed - you played your turns directly after rollover. I have a check build in that is usually able to catch these cases, but for whatever reason the date recorded on login in the player snapshot didn't change (it usually does every rollover). Sadly, there is no other way to recognise these cases. You can fix this by changing the KoL date from Petember 1 to Petember 2 in the player snapshot that was done after rollover.

User avatar
Elayne
My Pie Blown Sky High
Posts: 504
Joined: Thu May 08, 2008 3:19 am

Postby Elayne » Thu Apr 16, 2009 8:22 pm

Strangely enough, when I parsed the log today after finishing the run, it was working. Maybe because a new day was added to the run?

Also, it looks like the Pyramid problem was a relay browser problem. I just had the misfortune of getting two "errors" at the same time. :)

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Jun 26, 2009 7:12 pm

The Ascension Log Visualizer version 1.3.0 has been released.

Changes from the last version include, but are not limited to:
- Added a basic ascension log notes manager to give users at least some degree of ability to manage log notes inside the ALV. It can be started for the currently selected log tab through Extras->Notetaker.
- Fixed a problem with the settings handling which resulted changed settings not being saved. (I was kinda surprised that this wasn't reported once I found this bug, it had the potential to be rather annoying for users.)
- Updates to many of the data files to mirror the new content in the game.

As always, check the SVN log if you want a more detailed list.

Anyone who used any of the previous releases of the ALV should on the first startup of this release recreate the data files through Extra->Recreate data files and then restart the program. If you made manual changes to the files, you will have to add them again afterwards.

As usual, any feedback, be it bug report, request, or just general comment will be appreciated. Especially feedback on the new Notetaker would be very interesting, since it is a rather basic implementation that probably could be made better (I lack the artistic creativity to think of something myself, though ... >.>).

salien
Pie in the Sky
Posts: 115
Joined: Fri Jan 11, 2008 1:50 pm

Postby salien » Thu Jul 30, 2009 5:01 pm

Random bug: Not all instances of casting Spring Raindrop are being reported. I think maybe ones cast by auto-attack aren't counted? The visualizer reported 192 casts, but a find-in-files showed over 350 instances of "casts SPRING RAINDROP".

Random request: Since the main point of Spring Raindrop is to generate MP, could it's total MP generated be reported somehow? As a negative cost might make sense, but it might muck up that graph, so I dunno. (As a side note, in the logs I have, mafia didn't always record the HP/MP gains from Spring Raindrop; sometimes those lines just aren't there. I realize there's nothing the visualizer can do about that, just mentioning it so you can avoid having that cause parsing errors.) A similar method could be used for Bakula attacks, I suppose, though I'm not worried about that since I don't have one and they're non-optimal. :)

Actually, if you could manage it, an MP gains report could be awesome; that may be ambitious, though, since you'll have to parse MP from items in and out of combat, familiar MP, skill MP, MP regen effects/equipment, Doc visits, free rests... Would make for some excellent info, though, to know where all that MP you spend is coming from. Even if you only identify some sources like Spring Raindrop and familiar actions, and lump the rest under other, that'd still be useful.

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Jul 31, 2009 8:50 am

salien wrote:Random bug: Not all instances of casting Spring Raindrop are being reported. I think maybe ones cast by auto-attack aren't counted? The visualizer reported 192 casts, but a find-in-files showed over 350 instances of "casts SPRING RAINDROP".

Just checked:

Round 1: Flolle casts THRUST-SMACK! (auto-attack)

I bolded the part that I failed to pay attention to in the regex. :D

No idea whether mafia always logged auto-attacks like that or if it was a recent change. Either way, 1.3.1 is out and should handle this correctly (if not, get right back to me).

Thank you for reporting this bug. :)

salien wrote:Random request: Since the main point of Spring Raindrop is to generate MP, could it's total MP generated be reported somehow? As a negative cost might make sense, but it might muck up that graph, so I dunno. (As a side note, in the logs I have, mafia didn't always record the HP/MP gains from Spring Raindrop; sometimes those lines just aren't there. I realize there's nothing the visualizer can do about that, just mentioning it so you can avoid having that cause parsing errors.) A similar method could be used for Bakula attacks, I suppose, though I'm not worried about that since I don't have one and they're non-optimal. :)

Actually, if you could manage it, an MP gains report could be awesome; that may be ambitious, though, since you'll have to parse MP from items in and out of combat, familiar MP, skill MP, MP regen effects/equipment, Doc visits, free rests... Would make for some excellent info, though, to know where all that MP you spend is coming from. Even if you only identify some sources like Spring Raindrop and familiar actions, and lump the rest under other, that'd still be useful.

A MP gains report sounds intriguing, I'll have to look at how that stuff is logged by mafia to say how much work it would be to add something like that though.

However, I'll be writing my last couple of end-of-semester exams next week, so I hope it is understandable that I'll be pushing this back until after those are done. I will get back to you some time after next week, though.

Until then, people can of course use the time to give their opinion on whether they would like to see such a report, because the more people want it, the more I'm inclined to do it even if it ends up being a nontrivial amount of work. ;)

User avatar
Flolle
Fie the Pie
Posts: 848
Joined: Mon Apr 02, 2007 10:13 am

Postby Flolle » Fri Aug 14, 2009 3:25 pm

Alright, as promised, here I am again.

First however, I noticed that a couple of recent logs seemed to have some problems with properly logging encounter names, which resulted in broken hunted combat and quest adventure listings. (Sadly, I havn't got a single bug report concerning this problem, so I only noticed it by chance.)

I looked at some more recent logs of mine and believe that I found the problem. So, 1.3.2 is up and hopefully fixed this issue. If not, I would appreciate it if people got back to me.



And with that, onwards to the matter of a MP report.

I have reviewed how KolMafia tends to log MP gains and I must say that a really detailed report would be pretty complicated to do with the current way that the internal parser works. Doing some basic categories Starfish Familiars, Out-Of-Combat Consumables, Resting and Other would however be doable with the current parser.

I do intend to rewrite the parser at some point, but I still have to think about some of the finer points of such a rewrite though. Also, I'd like to work on some other points before that, so unless there is great demand for a more detailed MP report*, it will be on the back burner for the time being.

Please note though, that even with a reworked parsing mechanism, such a MP report wouldn't be perfect because KolMafia very often doesn't link MP gains with some specific action. This, for example, makes it quite hard to tell which gain is linked with which action if there is more than one MP gain in a combat round. I probably have to analyse the session logs a little more to see whether there may be any kind of pattern to find, but I don't have much hope in that regard.


* High demand means something along the lines of about 20 people wanting this. Not only out of curiosity, but also because they really could use such data to better analyse their runs, and they'd have to be able to state such in a post.

salien
Pie in the Sky
Posts: 115
Joined: Fri Jan 11, 2008 1:50 pm

Postby salien » Fri Aug 14, 2009 4:03 pm

I was about to report that issue with encounter names, heh, but wanted to ensure I had logs for it myself so I could provide those; glad to hear it's fixed!

As for the MP gains report, those basic categories sound pretty fantastic already (would the starfish gains be break-down-able into the individual fish-fams? Hobo vs. clownfish vs. GGG vs. slimeling, etc.). One question I have is what might fall into Other; in particular, would there be any way to split out an In-Combat (not starfish) category? That would help significantly with analysis of the benefit of the haiku katana or bakula (and you're really unlikely to use both, so it should be easy to decide which one was involved). It'd still probably get muddied up with in-combat use of MMJ or whatever, purple snowcones, etc. (and maybe *whelp gains? or do they fall under starfish-type?), but those shouldn't have too much of an impact. I guess the Sauceror splashback stuff could muck it up a lot too, but I dunno how much people would mix that strategy with katana use anyway. (And for HC types, Sauceror splashback is probably the best application of this category; nice to be able to compare your splashback gains with your MP spent on spells.)

Oh, also, would 'kitchen sink' familiar MP gains (NPZR, e.g.) fall into the starfish category? I think that would make sense.


Return to “Ascension Tools”

Who is online

Users browsing this forum: No registered users and 2 guests