Recent content by fronobulax

This "breaks" autoascend. I had to edit mr2018 and auto_zone (which made me laugh because Auto Zone is the name of an automobile parts franchise. and @Veracity ' Meat Farm. and canadv

This is deliberate, AFAIK. @Veracity wrote code to detect and log when purchase failures occurred. Some discussion at https://kolmafia.us/threads/mafia-seems-to-spend-meat-but-not-buy-an-item.30300/#post-176386 Until this issue is addressed in code I think the work around is to just try and...

There is a technical problem with that. If mafia is not running the right version then the detection of that and associated error message are not under mafia's control. There is a work around, the somewhat dormant project Multitool...

thank you

@MCroft - Go for it, please.

Thanks. I'd say there are some philosophical differences because my quick and dirty measurements seem to show there is no measurable time saved... and it does make Preferences a touch more complicated, but if I decide to make a case for reverting it I will do so when it is the only change and...

Anybody remember why this was done? The description is correct - encoded values are not generated during tests if the file is not going to be saved. There is a comment on the PR about the change improving performance for tests but some casual testing using gradle reported times suggests tests...

@MCroft See https://github.com/kolmafia/kolmafia/pull/2901 It is not a test as such but rather a use of the test framework to generate "excursions". Feel free to make a local branch and experiment.

Still looking at locks. But.... I updated to main and one of the tests ran for at least three hours without finishing. I killed the test and reran and it worked but I think the Universe is telling me this is not ready to commit yet...

Operator error with withEquippableItem . Stats are changing. Thanks.

So it is a "feature request" to have withLevel set stats if it knows an Ascension path? I can live with that. I will do more debugging and confirm I am not seeing changes. Operator error is always a possibility :-) Thanks.

I call internal.helpers.Player.withLevel for various levels. I print out KoLCharacter.getBaseMuscle(), getBaseMysticality() and getBaseMoxie() before and after. Nothing changes. Since I have previously defined a class I would have expected at least one of the stats to be set to level squared...

My threat to commit is intended to provoke discussion, so thank you. I have not noticed a significant performance hit with this PR compared to running the main branch. Somewhat tongue in cheek I'd say the performance cost of a corrupted file is infinitely high and so, by definition, anything...

My understanding of the code is that uses effective is that it is really a special case to deal with weapons that use something other than the "expected" stat when determining damage. Effective does nothing different if the weapon is the July 4 saber, replica thereof or June Cleaver. If Moxie...

I forced the code to think it was headless and tests pass repeatedly. Specifically I hardwired SwinglessUIUtils.isSwingAvailable() to be false for several runs (and then restored it the exiting code which returns true in the test environment). I'm willing to commit.