"Whispers of the Machine": clicks that skip speech might affect notepad GUI

[ivan-mogilko]

Describe the bug
In "WOAM" the notepad may be displayed during conversations with NPC, with topics that player may ask about.
In the latest master branch, skipping the mouse click made to skip the final line of conversation propagates further and triggers any element of the notebook below the cursor, either a topic, or else (like X button in the corner).

EDIT: This does not seem like affecting interactive elements inside the room. For example, skipping protagonist's speech while not in a dialog with another character, and having mouse cursor above some object, will not trigger that object's interaction.

AGS Version
Latest master, 3.6.1, 3.6.0, 3.5.1, 3.5.0.

Game
Noticed in "Whispers of the Machine".

Expected behavior
Mouse click made to skip the speech line should not affect anything else.

Further information
This is not a generic issue, it does not happen in a simple test game with default speech and a gui controls or dialog options, for example.
The issue reproduces in older versions of the engine, meaning it affects only very specific setup (otherwise it would be reported by users much earlier).
There's a possibility that this is related to the WOAM's custom engine, because they have had made certain changes on top of the official AGS engine of the time.

NOTE: WOAM's engine was based off v3.3.0.1150, so if it's necessary to compare source differences, commit b1fba4c should be used as a reference.

[ivan-mogilko]

As a small update, first of all this is not a new recent bug, it happens way back into 3.6.0 Beta. UPD: 3.5.1 has this too.

Second, the situation is more strange than described above. Not only clicking to skip the last speech line causes the topic to retrigger, but also waiting through the last line sometimes causes the same issue, so long as you keep mouse cursor above the topic.

UPDATE: the topic seem to retrigger only once, which makes me wonder if this is not a problem with mouse click skipping particular line, but rather something gets scheduled before the sequences of speech lines begin. But it's hard to tell for certain.

[rofl0r]

i just noticed that mouse button release is registered as a click (i misclicked when doing a drag and drop and then the button release was registered on the target). maybe either the engine sends the same event to the game for both SDL events, or the game itself doesn't differentiate between press and release - but then you say this didn't happen in earlier AGS, so it seems it's the former. edit: i misunderstood what you said, nevermind. it's probable that the game wont work with anything below 3.5.1

[ivan-mogilko]

I went back to v3.5.0.32, and the issue with repeating question still happens there. This is where I stopped.

This means that this is not a regular bug (it would be noticed and reported long time ago). This is either a regression in very specific circumstances, or a difference between our engine and WOAM's custom engine.

I tried checking out the diff between old commit b1fba4c and their code (found here: https://github.com/josthas/WoaMAGS). They have number of changes related to mouse handling, but so far I could not tell for certain if these may be causing this difference in behavior.

It may also be worth checking out maintainers of ScummVM AGS port, as they were dealing with WOAM in the past too. Maybe they know something.

[rofl0r]

@criezy do you recall fixing this in scummvm ?

[criezy]

We had a similar issue, but it was not specific to Whispers of a Machine: https://bugs.scummvm.org/ticket/13996
This was a one-line fix, but from what I remember the AGS code was already correct and it was just a line we forgot in the ScummVM code.
I don't remember any specific fix for Whispers of a Machine that could be related.

[ivan-mogilko]

@criezy does ScummVM have the issue described in this ticket right now?

I don't have scummvm installed at the moment, but i might try later myself too.

[rofl0r]

ftr this is the fix in scummvm: https://github.com/scummvm/scummvm/pull/4574/files

[ivan-mogilko]

ftr this is the fix in scummvm: https://github.com/scummvm/scummvm/pull/4574/files

This is a fix for their own mistake, which was not present in ags.
The mentioned mistake is also not the same as observed in this case.

[ivan-mogilko]

Something else I noticed: this effect seems to happen only with notebook.

For example, if a protagonist character speaks to herself, and mouse cursor is positioned above an object in the room, then clicking top skip the speech does not trigger interaction with that object.

Does not happen with inventory items, for another example.

[ivan-mogilko]

Hmm, so, this is not related to speech at all. Any click in the notebook is duplicated.

Steps to reproduce:

1. Click on arrow which turns the page.
2. Very quickly move the mouse up to X button (but do not click).
3. As a result - page turns, and then notebook closes, as if you clicked for the second time.

[rofl0r]

the mouse up registered as mouse down i mentioned earlier happened on the input pad in front of the flat in mimir road, i pulled up the forensics analyzer and dragged it over the input pad, when releasing the mouse up was registered as a click on a digit on the pad.

[ivan-mogilko]

Well, not any mouse up is acting as mouse down. This may be tested with walking, or pressing on buttons on the action bar.
Not to mention that if this was a consistent bug in the engine, that would be noticed by numerous users in many games.

Since this is not a generic behavior, this likely means an issue with scripting. Also could be the scripting was relying on a different engine behavior (as an option, although I don't have a clear evidence right now).

[ivan-mogilko]

the mouse up registered as mouse down i mentioned earlier happened on the input pad in front of the flat in mimir road, i pulled up the forensics analyzer and dragged it over the input pad, when releasing the mouse up was registered as a click on a digit on the pad.

I tried this running the original executable, and it seems to happen there as well.
When the keypad is on the screen, simply holding mouse button down elsewhere above the keypad GUI (but not outside), and then dragging over a key button and releasing is enough to trigger that button's press.

[ivan-mogilko]

In regards to the main issue, I made an experiment: created a branch at the old version 3.3.0.1150, which WoaM's custom engine was based on, and tried to copy only small number of changes just enough to run the game - new script functions and resolution hacks.

The resulting version does not have this repeating problem. So, unless I miss something in copied code, there's a difference in behavior somewhere between 3.3.0 and 3.5.0.

I have a suspicion towards "custom dialog options rendering". According to a quick debugging, WoaM uses this feature. The feature was updated in 3.4.0, and received new behavior (it's controlled by the switch).
https://adventuregamestudio.github.io/ags-manual/CustomDialogOptions.html

I might look further into this direction.

[rofl0r]

nice. if you export those changes/hacks into a patch, it would be straightforward to script a git bisect search for the commit breaking it (so long as the patch keeps on applying cleanly to each rev). on my end, i tried various changes in the engine, debug output, etc but couldn't figure out what's going wrong. it would be nice reading the code of the game to see what's happening, but it's way too much asm to wade through.

[ivan-mogilko]

I went other route, tried to figure out where does the next "Say" command call comes from under debugger.

It appears there's a mistake done very long time ago, during a code refactor, which missed a bit. As a result, a "on_event" script callback can fire twice for "mouse up" under some conditions, once immediately, and another event is scheduled to run after the current chain of actions has completed.

The breaking commit is 2f54a16 (yes, it's from year 2014...). Somehow no one noticed that since. Maybe not many games use "on_event" to handle mouse up.

I pushed 988f6e1 to fix this.

@criezy , this might be applicable for ScummVM ags port as well, because the problem is present since like v3.4.0.

Also, 625e3e4 fixes dialog options not redrawing themselves when mouse hovers above an option - but that is a rather recent bug.

[rofl0r]

nice bug hunt! i can confirm that the issue is resolved with master - thanks!