View Issue Details

IDProjectCategoryView StatusLast Update
0006313The Dark ModCodingpublic03.10.2023 20:04
Reporterstgatilov Assigned Tostgatilov  
Status feedbackResolutionopen 
Product VersionTDM 2.11 
Target VersionTDM 2.12 
Summary0006313: Readable GUI sometimes gets stuck on screen (blank)
DescriptionSometimes when player reads a multipage book, he gets stuck in a nasty state.
The GUI of the book is displayed, but the pages are empty.
Controls don't affect the GUI (can't close it for instance), and the immobilization is already removed.
So player can freely walk around, but there is readable GUI stuck on screen which makes the game unplayable.

This state is fully captured by save/load.
Steps To ReproduceLoginnerer found way to reproduce this issue.

1) Pick up a multipage pickable book (e.g. Lady Barrington's Diary in The Elixir, or the Rotwick's diary in New Job).
2) Open the book.
3) Hit two keys in short succession: next page, then use item.

So it seems that this state happens when player tries to close the book ("Use" key) while its page is being changed (due to Next/Prev Inv. Item key).
Additional InformationSee original thread:
TagsNo tags attached.




03.10.2023 20:03

administrator   ~0016095

Cleaned this in svn rev 16831.

I revised all the controls-related code, located in tdm_readables.script and readable.guicode.
Instead of single "InteractionState" variable changed from both sides, now there are several separate signals/requests/....

There is a major difference between "requesting an action" and "doing an action".
::: Doing an action (page flip or closing readable) can only be done in script code in one specific place.
That is some event loop --- usually either handlePageTurns or main loop in darkmod_readable_immobile::onFrob/darkmod_readable_mobile::inventoryUse.
::: Requesting an action can happen pretty anywhere, both anywhere in script and in GUI callbacks.
This is only setting/modifying a variable: gui::ChangePageRequest or gui::CloseRequest.
These requests are serviced in the main even loop in script when it is a good time to do that.

Aside from that, there is fade in/out animation, and script code often waits for it.
With the new code, it is done like this:
* Script sets gui::AnimationInProgress to 1 and SIMULTANEOUSLY calls some GUI handler which resets Desktop --- either readableClose or pageTurnBegin.
* Then it waits for gui::AnimationInProgress to get back to 0.
* The GUI script runs event handler in near future, which resets Desktop and soon "onTime READABLE_FADE_TIME" handler runs and resets gui::AnimationInProgress back to 0.
* After that waitForAnimation script function returns.
Note that there are no other places which modify this variable: only waitForAnimation can set it to 1, but then it only returns when it's back at 0, which can only be done by GUI code.

There are some other changes as well.
PrevPageRequest and NextPageRequest are merged to single integer ChangePageRequest, which stores the increment player wants on top of the current state.
Also, the GUI code on longer sets it to 1, by increments or decrements it by 1 --- that's made possible by 0006028.

On script side, ChangePageRequest is now resolved in better way.
It allows saving user's intent for how much pages he wants to scroll through (aka "input queuing"), although we are not yet sure this is a good thing:
If it is not, just modify this line as comment explains, and queuing will be gone:
  guiEnt.setGuiInt(overlayHandle, STATE_CHANGE_PAGE_REQUEST, changePageReq); // note: replace changePageReq with 0 to disable page flip queuing

Note that CloseRequest is saved too, so now if you try to close book while page is flipping, it will close immediately after flip is over.
Also to do this I reordered handlePageTurns and check for STATE_CLOSE_REQUEST in the main event loops --- check for close request first, and check page flipping only if closing is not requested yet.

Finally, I changed all waits in script from 16 ms back to single frame.
There is no timing-sensitive stuff in this script, better run loops every frame for better responsiveness.


03.10.2023 20:04

administrator   ~0016096

It is not yet clear if it is good or not that page flips are now queued.
We should wait for feedback in future dev builds and probably remove page flip queuing if necessary.

Issue History

Date Modified Username Field Change
27.08.2023 12:37 stgatilov New Issue
03.10.2023 19:05 stgatilov Assigned To => stgatilov
03.10.2023 19:05 stgatilov Status new => assigned
03.10.2023 20:03 stgatilov Note Added: 0016095
03.10.2023 20:04 stgatilov Status assigned => feedback
03.10.2023 20:04 stgatilov Note Added: 0016096