Search results

I changed my name. Mad Carew is now me. I copied my darwinlet_prefs.txt and darwinlet_moods.txt to mad_carew ... and it recalled my preferences. I suppose we detect the use of a name change card, reset the prefs file name, and write it all back out. I ended up getting the password from the...

I think you're right in that it's a KoLmafia issue, which means this may not be the best thread to discuss this. 1: Do we want to give extra weight to a muffin in cases where fullness is 0, to allow "Started your day right" on the first consumption? Or do anything special around it? (sort of...

I haven’t reviewed the code (still at work). Does this solve Adventuristo’s original problem with a scripted use of the Astral Energy Drink?

Are we sure? The error with div/0 was happening with the astral energy drink in the real world experience in the start of this thread, despite the two AED’s each having a value for SpleenHit. I don’t really know why we look up the item by name when usesRemaning requires an itemId anyway

It's weird. We have an itemId when we call maximumUses. We call getSpleenHit(itemName), which looks up the map ConsumablesDatabase.consumableByName.get(name); But it would probably be more precise to create ConsumablesDatabase.getSpleenHitById(itemId) and have that function call...

Yes, this is helpful. It tells me that when it read the preferences, it found one item. I'm trying to find a set of steps to blow up the preferences, and it seems that leaving KoLmafia running and having KoL log you out for inactivity is part of the pattern. The odd thing is that that pref...

some data to experiment with: fullness.txt:8: [glitch season reward name] 0 0 0 0 0 0 Inedible, starts a fight with %monster% fullness.txt:170: Children's Meal of the Damned 0 1 crappy 0 0 0 0 fullness.txt:359: flask of peppermint oil 0 1...

progress, for you to consider. It passes the new tests, but I don't like the output of eating a quantum taco: > eat quantum taco Eating 1 quantum taco... Consumption limit reached. Finished eating 1 quantum taco. > eat pr0n taco (usable quantity of pr0n taco is limited to 0 by fullness)

I debugged it as well and the second code was hit on startup with a consumptionType of "NONE". This came up when building the panes for the Inventory panels, (X possible, Y current) If it falls through everything, it will return Integer.MAX_VALUE; However, GLITCH_ITEM doesn't fall through...

I'm not sure what I'm seeing. In practical terms, we have a switch statement which is failing on case EAT and SPLEEN (and potentially DRINK) because it doesn't have the protection from zero statement that's below it. So, it's easy to pull those if wrapper up into the case statement, but why do...

That makes me think we should have a failsafe to prevent divide by zero in any case, regardless of special casing the code or giving it a fake fullness.

It looks like quantum taco is fullness 0 in fullness.txt When we call EatItemRequest's maximumUses(final int itemId, final String itemName, final int fullness) , it ends with return fullnessLeft / fullness; I'm not sure if this should be special cased in EatItemRequest or if we should fudge...

@Alium, I'm not sure that's related. I think that the narrow fix for that rollover issue is in the rollover code, not the prefs loading/saving code. If you want to prove it's unrelated, try it without writing to the file. This PR is strictly about the file system related issues we've been seeing.

So, can we close this as "won't fix, go get Fedora 37"?

It's not the only bad state, but it's one known bad state. It's why I'd love to see some logs or prefs files that were in bad state, to see what else we should be trying to detect. Another bad state is "my prefs were reset to the defaults". Part of the problem is that there are normal states...

I don't want to put it I this PR, but would it be worthwhile to instrument the code a bit? Or put some validation in the write or in loadPreferences? This is why I'd like to see what it actually looks like, but I'm imagining something like this. synchronized (encodedData) { for...

OK, so is there a pattern like play/sleep/get KoL logged out/wake/play/relogin? Is the problem happening because we're trying to write after we wake up and we've been logged out or the file handle is closed or something? We're not failing, but we're not succeeding the way we want.

I'm ok with making things less painful while we figure out a better long term solution. The weakest part of my approach is that I've never had this problem and I don't have any examples of corrupted preference files. Under the hood the a DB is writing to files (and DB corruption is miserable...

Do you have a session log of that?

If we're going that far, I think I'd like Frono's idea of a SQL database better. downside can't edit with a text editor, upside, can edit with a SQL client. Upside is not as good for people who don't use sql. Imagine Transactions! in the prefs... Do you happen to have the damaged prefs file?