Bug - Fixed trackedMonsters resets on login

ckb

ckb

Minion
Staff member
If I use a tracker (such as Transcendent Olfaction) this sets property "trackedMonsters", but this is cleared if I log out and log back in.

This is defined as 'Reset.ASCENSION_RESET' in TrackManager.java, but I have not been able to find what is causing it to reset on login.

Also, both "trackedMonsters" and "trackedPhyla" are missing from defaults.txt


More Background:
Older trackers have individual monster tracking prefs, such as "olfactedMonster" and "_gallapagosMonster"
At some point, it looks like this was replaced by a common "trackedMonsters" pref. The older prefs do not reset, but the "trackedMonsters" does if I log out and log back in again.
This issues is more noticeable with McHugeLarge Slash because it does not have a legacy pref and can only be tracked with "trackedMonsters"
 
I can confirm.

The CLI opens with
Code: 
logPreferenceChange => true
Sending login request...
Preference    _concoctionDatabaseRefreshes changed from to 1
Using data override:    data/mallprices.txt
Preference pingLatest changed from    api:10:114:126:1188:19620:118.80 to api:10:112:117:1140:19620:114.00
Ping    test: average delay is 114.00 msecs.
Preference banishedMonsters    changed from fluffy bunny:ice house:0 to
Preference trackedMonsters    changed from pygmy witch surgeon:Nosy Nose:214:garbage    tourist:Transcendent Olfaction:292701:garbage tourist:Gallapagosian Mating    Call:292701 to
Preference nextAdventure changed from Noob Cave to Barf    Mountain
Initializing session for USER

In refreshSessionData we load banished monsters (and not tracked monsters), but it seems we've already cleared them by that point. BanishManager also clears its cache on login (in initialize(final String username)) which is correct I think.

I don't know exactly what's causing the clear: some UI component? I haven't checked whether it happens in headless mode. A potential fix would be to have a static variable tracking whether we've read the preference into the cache, and prevent saves from overwriting the preference until we've done so. A different fix would be to just use the preference itself as a single source of truth.
 
Ryo_Sangnoir said:
A different fix would be to just use the preference itself as a single source of truth.
Click to expand...

To the extent that my opinion is solicited and informed I vote for this. Single source of truth is almost always the better implementation.

I also admit my antipathy towards static because it is one more thing that might possibly leak across tests.
 
You must log in or register to reply here.
Back
Top