three questions

[duskshine]

1. is there any convenient way to set properties auto-reset on ascension (like _ prefix only not on RO)? (currently doing that the stupid-way involving asc script)
2. anyway to override/modify breakfasts? onlogin is called everytime on login and i might not necessary want to breakfast on the first login (due to mana concerns) so thats nogo
3. anyway to bounce the result of post-adv/pre-adv script into relay browser? i know that'd be a tricky one but since we have clover warning etc...

 

[lostcalpolydude]

1. is there any convenient way to set properties auto-reset on ascension (like _ prefix only not on RO)? (currently doing that the stupid-way involving asc script)

A pre/post-ascension script is the only way.

2. anyway to override/modify breakfasts? onlogin is called everytime on login and i might not necessary want to breakfast on the first login (due to mana concerns) so thats nogo

The best way to go is a login script that sets and checks a _ property.

3. anyway to bounce the result of post-adv/pre-adv script into relay browser? i know that'd be a tricky one but since we have clover warning etc...

I don't think so.

 

[Fluxxdog]

1. is there any convenient way to set properties auto-reset on ascension (like _ prefix only not on RO)? (currently doing that the stupid-way involving asc script)

A pre/post-ascension script is the only way.

I've always wondered about that. When I look at something like:

user	lastPirateInsult1	false
user	lastPirateInsult2	false
user	lastPirateInsult3	false
user	lastPirateInsult4	false
user	lastPirateInsult5	false
user	lastPirateInsult6	false
user	lastPirateInsult7	false
user	lastPirateInsult8	false
user	lastPirateInsultReset	-1

...that last bit seems excessive. When you start a new ascension, all the insults should be false. But after that, why do you need the number for each things that resets? Can't it be tied to one setting, like a simplified "lastAscensionReset" that triggers when mafia detects you're in your next life? I compare it to the lastSlimeVial38xx just down the list in defaults.txt that don't have a(n apparrent) reset counter.

tl;dr Why not? ^^ Thanks

 

[Theraze]

Because sometimes mafia bugs and loads up the preference file from the wrong character. And rather than keep the wrong pirate insults/nemesis passwords/demon names forever, it's good to have a touchbase where you can say... hey, wait. That's the wrong ascension number. Something must have gone wrong with loading my preference files.

 

[Veracity]

I guarantee that that explanation has nothing whatsoever to do with why the "lastxxx" preferences were implemented the way they were. I could explain, but that comment has left a sour taste in my mouth, and I don't feel like it any more.

And, as always, give us a way to reproduce the "sometimes Mafia bugs" issue, and we will address it.

Sheesh.

 

[duskshine]

um. can i add some of these into feature request? because like the first two could really be useful - ive been play with mafia for just four days and already feeling a urge to use those things.

 

[bordemstirs]

2. anyway to override/modify breakfasts? onlogin is called everytime on login and i might not necessary want to breakfast on the first login (due to mana concerns) so thats nogo

I've read this several times and I'm still not sure what exactly you're asking for. You have a breakfast script that runs on login. But you want to have it... not run on login sometimes. How is mafia supposed to know which times it should or should not run it? I think I'd better understand with an example or if you could maybe reword this.

 

[heeheehee]

Because sometimes mafia bugs and loads up the preference file from the wrong character. And rather than keep the wrong pirate insults/nemesis passwords/demon names forever, it's good to have a touchbase where you can say... hey, wait. That's the wrong ascension number. Something must have gone wrong with loading my preference files.

I was under the impression that Mafia does this for people who don't use Mafia for _everything_.

 

[Veracity]

I have no idea what you mean by that.

 

[heeheehee]

Basically, if I were to ascend outside of Mafia then switch to using Mafia in the middle of a run (maybe because I like the insult tracking and don't want to use greasemonkey? I don't know) the lastXXXReset preferences mean that Mafia will correctly realize that the existing data is outdated. That's more or less what I meant (and also my interpretation of the lastXXXReset preferences).

 

[Veracity]

OK, yes. That is right.

As it turns out, there is a "knownAscensions" setting which is that - in addition to the lastXXXReset settings.

If you ascend within KoLmafia itself, it calls ValhallaManager.onAscension, which increments knownAscensions, calls ValhallaManager.resetPerAscensionCounters(), resets counters (fortune cookie, etc.), and calls KoLmafia.resetSession, which loads all the initial pages - api.php, inventory, etc.

KoLmafia.refreshSession is also called when you log in. In that, we look at that setting after having loaded api.php and everything else, and if the current ascension count is different than that setting, we call ValhallaManager.resetPerAscensionCounters() and reset other counters. That is exactly the case of "the user ascended outside KoLmafia and everything we thought we knew is invalid".

So, we have "ValhallaManager.resetPerAscensionCounters" - which looks like it might be able to supersede all the "lastXXXReset" settings. It was, in fact, implemented after the lastXXXReset settings.

The thing is, those lastXXXReset settings control the value of other settings - and if it was just a matter of resetting the other settings to default values on Ascension, we could move that to ValhallaManager.resetPerAscensionCounters and get rid of the lastXXXReset setting. But some of them - dusty bottles, for example - "reset" by actually looking at the glyphs.

It would be a nice little refactoring job to look at all the lastXXXReset settings and move as much as possible to the newer mechanism. Not all would be removable; you can't look at dusty bottle glyphs immediatly after ascending, for example.