Bug - Fixed GCLI dead zone scrolling change still a bit glitchy

[wrldwzrd89]

Try, for example, eating to your maximum fullness (20 in my case) of a 1-full food (I'm using jerky coins), with milk.

What will end up happening is that the GCLI will have roughly 60 messages printed out VERY quickly as KoLmafia detects the consumption results... but the display does not autoscroll to the bottom, as it should when something like this happens, assuming the scroll bar was already at the bottom before this happened (which it was in my case).

EDIT: Just realized that booze works even better for testing this, as mass-drinking 1-drunk boozes prints additional messages about drunkenness gained. Also thought up a simple fix: Before printing anything to the gCLI (for example, because of a request executing), store the gCLI scroll bar position just prior to the print. Perform the print as usual. Then, use the STORED position, not the CURRENT position, to decide whether to autoscroll or not.

 

[Winterbay]

The problem seems to be that the "locking of the scrollbar" for purpose of being able to look at one thing while Mafia automates other things is a bit too lenient on what it considers to be "not at the bottom", or something like that.

 

[slyz]

A cheaper way to reproduce this is:

ashq for i from 1 to 100 print( "test" );

 

[Winterbay]

Or just to do "verify randomscript.ash" with a a script that has more than a handful functions (WHAM and bumhceekascend both produced this problem during my testings yesterday).

 

[roippi]

I've posted about this in the SVN commit. The scrollbar has a listener attached to it that updates a boolean value telling the chat buffer whether to be sticky or not. When something is written to chat, it then checks that boolean value, and scrolls to end if it's supposed to be sticky.

The problem is that the updating of the chat buffer and the scrolling to end are dispatched in separate threads, and the scrolling to end happens after the updating chat buffer. So there's an opportunity for swing to step in and change the boolean value in between those two threads. This is a race condition.

My way of addressing this in r10832 was to create a second boolean value, essentially a copy of the first thread's "live" boolean value. When the second thread gets around to deciding on whether to scroll, it looks at that copy, which is more accurate than looking at whatever the live value may have changed to.

Unfortunately this got reverted in r10848 when hola (correctly) fixed some of my mistakes. If I were to fix this, I'd just create a second LinkedList and replicate the above paragraph's behavior from r10832. Since hola seems to have a better grasp of how to optimize the chat system, I'll let him fix this. (plus chat is broken with the chat update, so committing something that may get in the way of a chat system fix feels weird)

 

[Winterbay]

I would have no problem at all if it only was the Chat. Is the gCLI goverened by the same threads as chat?

 

[roippi]

Yup.

 

[Winterbay]

Fair enough

 

[Bale]

CLI does not scroll on re-login

r10849. CLI does not scroll on re-login.

Steps to reproduce:

1. Log in.
2. Play, script, etc for long enough so that the CLI output is longer than the height of the window.
3. Ensure you are at the bottom of the CLI.
4. Log out.
5. Log in again.

Result: I am looking at the TOP of the CLI output, not the bottom where my character has just logged in.

 

[roippi]

Merged.

 

[holatuwol]

Sorry, try 10585.

 

[roippi]

Looks good, thanks hola.

 

[Ethelred]

Sorry, try 10585.

Any chance that should really be 10855?

 

[holatuwol]

Yes, advanced simulation software suggests that the probability is around 100%.