Topic: Issue : Dialogs skip too fast

[NicolaGs]

Hi,

Some players found a weird bug in my game. It's related to the dialogs : they start to skip instantaneously without any user input after some time playing.

I've tried playing your game, but unfortunately after a while the text all scrolls through very quickly whenever I examine or do any other actions on things. I restarted a couple times and experienced the same thing.

Or visible here, in this walkthrough video : https://youtu.be/o-nvhUfGK9o?t=2244

My question is : has anyone seen the same problem (possible AGS engine bug) or coult it be just my game (bug in my scripts...)?

The game has the option to change the dialogs skip speed (4 choices : from click-to-skip to high speed) but changing this seems to not be of any help.
It was seen only by 2 players... so it may be related to their system.

I don't have any information on the players' system version atm (it's Windows, but don't know the version).

The game runs with latest stable AGS version (3.4.1.11).

Nicolas

[Crimson Wizard]

Ok, let me clarify first of all: are you saying that even if you set "skip only by click" mode they still continue to skip that fast?
Does your game feature voice-over? If yes, is there a difference if you turn voice on/off?

E: Checked the rest of the video, it looks like they begin doing that after certain point? Did user alt+tab somewhere during the game? I recall that may cause some keys "stick" in memory so AGS always thinks that a key is pressed.

[NicolaGs]

are you saying that even if you set "skip only by click" mode they still continue to skip that fast?

Apparently, yes (according to the only feedback I had)...

Does your game feature voice-over? If yes, is there a difference if you turn voice on/off?

No!

[NicolaGs]

E: Checked the rest of the video, it looks like they begin doing that after certain point? Did user alt+tab somewhere during the game? I recall that may cause some keys "stick" in memory so AGS always thinks that a key is pressed.

Oh, didn't see your edit... Well I'll ask, but it could be that, because, by looking at the video, there's a cut just before the occuring of the bug... So maybe the player took a look at the walkthrough and got back to the game...

[Crimson Wizard]

I remember someone posting a possible fix for Allegro 4 on forums before, but apparently I forgot to add it... again.
I will try to find it and see if it's possible to make a patch.

[NicolaGs]

Thanks for your fast answer, CW!

[eri0o]

Hey, a person found this bug with alt+tab, but it doesn't happen in any computer I own, so I can't reproduce. I also couldn't find the mentioned thread in Allegro forum - I also can only Google on Allegro forum, but from itself I can only look the latest 5 topics...

[Crimson Wizard]

Hey, a person found this bug with alt+tab, but it doesn't happen in any computer I own, so I can't reproduce. I also couldn't find the mentioned thread in Allegro forum - I also can only Google on Allegro forum, but from itself I can only look the latest 5 topics...

It was not on Allegro's forum, it was on this very forum, somewhere in Engine development. I could not find it last time, probably was just skipping it by.

I recall it involved some changes which looked confusing, so I'd rather not apply them automatically without some research first.

[eri0o]

Ha CW, I found the thread I think you are talking about: this thread here.

From the thread, the available options were:
 - using only mouse to skip text ;
 - modifying alleg-allegro/src/win/wkeybd.c , to remove the section with /* ignore special Windows keys (alt+tab, alt+space, (ctrl|alt)+esc) */ ...  (I don't think we need to prevent alt+tab from being handled in game if it isn't handled... So removing kind makes sense, but I can't understand why this would work ) ;
 - letting go (lot's of games don't play well with alt+tab and people are usually fine?) .

Edit:

I went with using only mouse to skip text. This solves the problem.

[Crimson Wizard]

- modifying alleg-allegro/src/win/wkeybd.c , to remove the section with /* ignore special Windows keys (alt+tab, alt+space, (ctrl|alt)+esc) */ ...  (I don't think we need to prevent alt+tab from being handled in game if it isn't handled... So removing kind makes sense, but I can't understand why this would work ) ;

I'd look into this at some point, but the fact that it does not reproduce at all times makes testing problematic.

[Dave Gilbert]

I found a very hacky way to fix this problem.

I ran the debug window (activated by pressing "`") while alt-tabbing in and out of the game until the problem manifested itself. When it did, I noticed that the debug window reported that an "on_key_press 399" command was being activated over and over again. So the reason why the dialog keeps skipping is because the game thinks a key is being pressed continuously. Pressing ANY key on the keyboard fixes the problem.

So I did a very hacky solution.

1 - I created a GUi that contained a single text message: "Game Paused. Press any key to continue." I named it "gUnpause".
2 - I added this bit of code under "function on_key_press" in the global script:

Code: [Select]

  if (keycode == 399)
  {
    if (gUnPause.Visible==false)
    {
      gUnPause.Centre();
      gUnPause.Visible=true;
    }
  }
  else if (gUnPause.Visible==true)
  {
      gUnPause.Visible=false;
  }

This "pauses" the game if the bug gets activated (which only happens about 1/5 of the time), and then forces the user to press a key to continue the game. SUPER hacky, but in lieu of an alternate solution this does the trick. Hopefully this bug will get fixed one day!

edit: Another solution is to use the command:

Code: [Select]

Speech.SkipStyle=eSkipMouseTime;
This prevents keyboard input from moving dialog forward. Although having a key constantly being pressed in the background could produce other bugs.

[eri0o]

Below is my little code to workaround if you are using Speech.SkipStyle=eSkipMouseTime; to allow skip dialog with the space bar.

Code: Adventure Game Studio

1. bool acceptKeyWasPressed;
2.  
3. void repeatedly_execute_always(){
4.   if(IsKeyPressed(eKeySpace)){
5.     if(!acceptKeyWasPressed){
6.       Mouse.Click(eMouseLeft);  
7.     }
8.     acceptKeyWasPressed = true;
9.   } else {
10.     acceptKeyWasPressed = false;  
11.   }
12. }
13.  

Spoiler: ShowHide

---

I tried to follow the code but I still don't fully get how getch() from allegro or ags substitute standard c getch. I think that every key press passes through the record part of ags even if you are not recording, since record.h is everywhere and getch is redefined for rec_getch() in Engine/ac/record.cpp, and under it my_readkey() is called. And below it's how it generates the 399 code (defined as AGS_KEYCODE_ALT_TAB).

Code: C

1. int my_readkey() {
2.     int gott=readkey();
3.     int scancode = ((gott >> 8) & 0x00ff);
4.  
5.     if (gott == READKEY_CODE_ALT_TAB)
6.     {
7.         // Alt+Tab, it gets stuck down unless we do this
8.         return AGS_KEYCODE_ALT_TAB;
9.     }
10. ...
11.  

readkey() is defined in allegro-4.4.2/src/keyboard.c, where it calls ureadkey(), that reads from a buffer, key_buffer. I don't understand how this buffer is filled. I don't understand how allegro-4.4.2/src/win/wkeybd.c comes into the mix. I have a feeling that alt+tab, since it is ignored by wkeybd.c function, but is considered in readkey, is somehow getting set as pressed, but the release event is lost, so in the boolean key array that marks if the key is pressed or not, it's kept marked true, which is pressed. My fix would be finding this array and everytime ags window receives focus (returning from alt+tab) all keys would get release. Unfortunately, I can't really understand this code so I don't know where the fix should be.

[Crimson Wizard]

I have a feeling that alt+tab, since it is ignored by wkeybd.c function, but is considered in readkey, is somehow getting set as pressed, but the release event is lost, so in the boolean key array that marks if the key is pressed or not, it's kept marked true, which is pressed. My fix would be finding this array and everytime ags window receives focus (returning from alt+tab) all keys would get release.

Yes, this is the most natural guess and option.

[Crimson Wizard]

Sorry for delay, I found some spare time and decided to look into this now.

The worst thing is that I cannot reproduce this problem for some reason. I remember I could once in the past, but no more. eri0o , or anyone else, if I present a test build, will you be able to test your game with it?

I will post soon.

DOWNLOAD: https://www.dropbox.com/s/dc6u0zq2om0ys72/acwin-3.4.1--try-alttabskip-fix.zip?dl=0

[Crimson Wizard]

EDIT: Dammit,nevermind. I was testing in 3.4.0, where we used older version of Allegro4. Apparently that particular bug that I found was fixed in the library since.

[NicolaGs]

Apparently that particular bug that I found was fixed in the library since.

Good news, thanks. I was hoping to find some free time to test it... but I see it's no more needed...

[Crimson Wizard]

Apparently that particular bug that I found was fixed in the library since.

Good news, thanks. I was hoping to find some free time to test it... but I see it's no more needed...

No, I was talking about separate bug. Not the bug that people still experience in 3.4.1. I since deleted my post about it.

Also we already found that my fix does not work.

[Crimson Wizard]

Alright, I am very much confused, there was time I thought that the way to reproduce the issue does not work in 3.4.1 anymore, but now I can reproduce it again.

So basically, what I do is this:
1. Start the game.
2. Hold TAB.
3. Hold ALT (dont let TAB yet).
4. Now release TAB.
5. Now release ALT.

Basically you need to press TAB earlier and release TAB earlier.
To fix - press any key.

Could someone try this with their game?

[NicolaGs]

I'll try this asap.

[Crimson Wizard]

I think I fixed it:
https://www.dropbox.com/s/6p1ylcj5aepnjpz/acwin-3.4.1--try-alttabfix-2.zip?dl=0

At least, I have nearly 100% reproduction with the latest 3.4.1 engine, and no reproduction with this test build.

I had to change library code, although I did not simply removed the code chunk as was suggested above. Not that I am against that, but I wanted to test if my understanding of the cause of this problem is correct. And also, in case of success, I'd like to suggest pull request to their repository.

For the reference, my changes are:

Code: C++

1. /* ignore special Windows keys (alt+tab, alt+space, (ctrl|alt)+esc) */
2.    if (((scancode == DIK_TAB) && (_key_shifts & KB_ALT_FLAG))
3.        || ((scancode == DIK_SPACE) && (_key_shifts & KB_ALT_FLAG))
4.        || ((scancode == DIK_ESCAPE) && (_key_shifts & (KB_CTRL_FLAG | KB_ALT_FLAG))))
5.    {
6.       handle_key_release(scancode); // <============================= my fix =======
7.       return;
8.    }
9.  

A little elaboration.
What this function does: it receives key push and release events, and passes them further into handle_key_press/handle_key_release. Before that it may skip processing under certain conditions.
Skipping Alt+Tab from passing it further into program, perhaps, may make sense, but the ambivalent meaning of this function caused it to fail.
Because when TAB key is released, if ALT key is still registered as pressed at that moment, the TAB release event will also be ignored.

Which leads to the issue which steps of reproduction I described above:
1) you hold TAB; since ALT is not pressed yet, the press event is registered.
2) you hold ALT and then release TAB or ALT & TAB simultaneously, and release event is skipped, making program think that TAB is still pressed.

My proposed solution is to force release event for the scancode that is accompanied by ALT (TAB, space or Escape in this case).


PS.

My fix would be finding this array and everytime ags window receives focus (returning from alt+tab) all keys would get release.

I actually tried this in my previous attempt using available Allegro API, but it did not work. Maybe there was something else, but frankly I think we already spend way too much time on this problem.

PPS. Also, when game is running in windowed mode, I was able to reproduce this error without game switching out (if you hold TAB earlier than ALT, guess that's how system works). Clearing buffer on switch in/out wouldn't help in that case.