Bug - Fixed Charpane blank screen issues

lostcalpolydude

Developer
Staff member
Now (with 9755) when I run a fight in the relay browser, with a combat macro for the whole fight (but not set to auto-attack), if I have a relay override the charpane is blank when it loads at the end of the fight. If I don't have a relay override then it doesn't reload at all at the end of the fight.

Edit: It seems that if I finish the fight without using a combat macro then I don't have that problem with a relay override active.
 
Last edited:

Theraze

Active member
Possibly tied into this change, it's stopped loading data off the charpane... I've missed a semi-rare and broken a 100% run tonight (a good night, apparently) because the effect didn't count down properly (on semirare) and it believed I had a different familiar equipped, then it went into NS fight with 1 hp and my last tower familiar. Ah well. It's just time. :)
 

Ruby Eyes

Member
r9755

Fun stuff. I'm having autoattack on a macro so each combat takes only 1 page load in the center.
I'm watching the adventure & ronin count, as those are a good indicator for actually fresh data. The left pane *does* reload after every combat (you can see that when you scroll down before entering the next fight - the reload will scroll it back to top), but not always refresh.

I click [refresh] on the left pane. Adventure counter shows 63.
I fight and defeat a giant. Adventure counter shows 63.
I fight and defeat a giant. Adventure counter shows 63.
I get a noncom with chaos butterfly and plot hole. Adventure counter shows 60.
I get a noncom with stats. Adventure counter shows 59.
I fight and defeat a giant. Adventure counter shows 59.
I fight and defeat a giant. Adventure counter shows 59.

For now, I'll go back to an older version (r9742), which had reliably just 1 turn delay :) Looking forward to trying new things!
 

Chez

Member
r9755

I'm not seeing the same behaviour as Ruby. My charpane now always refreshes with the correct turncounts after every combat. There's usually a slight delay (about 2 seconds) before the charpane reloads, but that's 100 times better than the charpane always being 1 turn behind. Maybe it's a browser caching thing?

Ruby: Try editing relay/basics.js and change lines 63 and 117 to read: charpane.location.reload(true);

That will force the browser to request a new charpane instead of using any cached versions. Maybe that makes a difference for you.

Also: Many many thanks to hola for looking into this.
 

Ruby Eyes

Member
Line 63 is empty, line 117 has a "}"
Do I just insert this line before any other content?

edit: Oh, that was apparently an old version. Deleted /relay/ and started mafia new, got different contents now. Thanks, will try this!

edit edit: No, not quite. Still having my adventure count stick at fixed 92 turns while I learned 2 rave skills.
 
Last edited:

Chez

Member
Hmm, I just noticed that inline use links were not working any more either.

Try top.charpane.location.reload(true);

That at least fixed the use links for me.

Edit for clarification: The use links themselves still work..they just don't update the charpane afterwards.
 
Last edited:

AlbinoRhino

Active member
(using r9756) This appears to work perfectly the majority of the time for me. The only times I am getting the blank character pane are when mafia maintains my mood. I am getting the blank pane every time the "maintain mood" fires. At least once, I also got a blank pane without the mood firing, but mafia had added one of its "You can now equip ..." messages to the end of the fight.

As an experiment, I disabled "run moods during manual adventuring" ("maintain health" & "maintain mana" were still enabled.) I did not get the blank pane when the mood would have normally fired, but I did get a blank pane when a MP restoration fired.
 

lostcalpolydude

Developer
Staff member
I just turned off "maintain moods" and "maintain health" ("maintain mana" is always off for me), and an auto-attack combat macro still gives me a blank charpane.

Also, my charpane override sets compactCharpane depending on whether it sees stuff it expects in a compact charpane, and at the end of these fights I get
compactCharpane => false
compactCharpane => true
in the CLI, one right after the other. Those only show up when the value changes, so it's like the script is running twice and seeing something different each time.
 

Chez

Member
I'm guessing when you get blank charpanes, the stuff it expects in a compact charpane isn't there, so it sets compactCharpane to false. When it gets a non-blank charpane, it changes it back to true. I'm getting similar bug reports for my charpane override, probably all caused by blank charpanes.
 

AlbinoRhino

Active member
Yes. Now that I've played some more turns, the behavior I described above doesn't appear as consistent as it did at first. Perhaps it's more generally cases where the character pane gets updated multiple times for whatever reason ?

I use only the mafia "script" button or KoL macros (which I have as buttons on the CAB). However, it still works for me most of the time. I don't use auto-attack though.
 

Theraze

Active member
Another bug I've had since this happened is that the HP/MP restore links on my charpane (clicking on the HP/MP value when not full) have stopped showing up reliably... The relay browser looks more like the mini-browser. I'm not using any charpane relay override, so this is confusing.
 

lostcalpolydude

Developer
Staff member
Right now I'm automating turns using astral mushrooms. Apparently my charpane override is running during automated adventuring, because I'm seeing the line about compactCharpane being set regularly. In fact, I've seen it change values 4 times during a single turn of collecting a munchies pill, which I believe indicates 2 blank charpane loads and 1 proper charpane load in the middle of the choice adventure (the last one might have been at the end of the adventure). That sounds hard to track down.
 

holatuwol

Developer
Debugged it, found that charpane refreshes were happening in the same second (and that's all the precision you get from HTTP headers), changed it to be strictly > rather than >= and committed, asked myself, "How did this even work before?", went back to old commit logs, found that Veracity had already run into the same problem and I had restored the code incorrectly, found out that relay overrides run even when the response code is 304 (faked or otherwise), and most of the recent problems should be fixed it.
 
Top