The Uncertainty Machine - Crash

[Max833]

Game
The Uncertainty Machine

Download
https://archive.org/details/The_Uncertainty_Machine

AGS 3.6.3.1 save game
agssave.zip

AGS 2.54.495.0 save game
agssave.zip

Desktop
Windows 10 Pro, 22H2

AGS Version
AGS 2.54.495.0 vs. AGS 3.6.3.1 (newest github build version)

Describe the bug

• Load the save game
• Use the screwdriver with the panel (screenshot 1) and you'll get a crash (screenshot 2)
• The other method: Click again and again on the panel and you'll get a very similar crash (screenshot 3)
• Also, the save game menu seems to be broken compared to the original (click F9 in the game) - see screenshot 4
• There are no issues with the old version

[ivan-mogilko]

@Max833 I am not able to reproduce the script error using a build of the latest master (3.6.3) commit. Using a screwdriver on a panel simply opens a panel up, as expected (i guess), and brings the panel close-up.

Regarding the save menu issue, the game sets a different font in script right before showing the save dialog, and that's what makes it look bad. I cannot tell why it worked in the old version without a more thorough script analysis.

[ivan-mogilko]

Regarding the save menu, that's a curious case. Apparently there's this script:

SetNormalFont(0);
SaveGameDialog();
SetNormalFont(4);
<...>

In the modern engine, calling SaveGameDialog does not actually display a dialog right away, but schedules it until after the current script ends. This makes any additional commands after SaveGameDialog to execute prior the dialog is shown.
However, the old game seem to ignore the font 4 in the save dialog. Which may mean one of two things:

• either the older engine executed the dialog right away, in the middle of the script;
• or calling save game dialog remembered the current normal font in another variable, used only for the dialog.

EDIT:
It looks like this was the second case. I tested following script in 2.54:

Display("before");
SaveGameDialog();
Display("after");

And both Displays appear before dialog is shown. So the dialog was actually shown after the script completes, but it apparently remembered the font at the Save/RestoreGameDialog call.

[ivan-mogilko]

The dialog font should be fixed with aa3ff06

Please double check that the panel issue persists. Perhaps there is something different in reproduction steps?

[Max833]

@Max833 I am not able to reproduce the script error using a build of the latest master (3.6.3) commit. Using a screwdriver on a panel simply opens a panel up, as expected (i guess), and brings the panel close-up.

You're absolutely right. Looks like a fix a few days ago fixed this issue. It isn't working with this version ags.zip, but it looks like it is fixed with the newest . I'll test a little bit more, just to be sure...

And both Displays appear before dialog is shown. So the dialog was actually shown after the script completes, but it apparently remembered the font at the Save/RestoreGameDialog call.

I always wonder why something like this can't be seen more often in v2.x games...

The dialog font should be fixed with aa3ff06

Really cool! I will test this as well, thanks! ^^

[ivan-mogilko]

Hm, I tried going a number of commits back, but could not find any which would give this error. The earliest I can use is c897a66, because it implements a latest save update, and previous can't load this save.

[Max833]

Hm, I tried going a number of commits back, but could not find any which would give this error.

Looks like it's still an issue with the latest version. I think I can reproduce this now. It's REALLY weird. When you use the screwdriver with the panel and the characters goes to the panel to open it, don't hover over the panel with the mouse cursor than it crashes. It looks like it doesn't crash when the mouse is still on the panel when the character arrives?

The dialog font should be fixed with aa3ff06

It does look way better than before for sure, but there is still this black font when you want to load or save a game via F9. Not sure this can be fixed, though.

Original game:

AGS version before your dialog font commits:

Newest AGS version:

[ivan-mogilko]

Looks like it's still an issue with the latest version. I think I can reproduce this now. It's REALLY weird. When you use the screwdriver with the panel and the characters goes to the panel to open it, don't hover over the panel with the mouse cursor than it crashes. It looks like it doesn't crash when the mouse is still on the panel when the character arrives?

Does this exact problem happen or not in the original game?

I dont have a walkthrough, is there a lot to do to get to that scene? Or do you happen to have a save made in the original game?

[Max833]

There is not that much to do. You have to look in your bag at the start and call the newspapers. After that, you can go in the building. Anyway, here is a save game for the old version: agssave.zip

I can't reproduce this issue with the old engine.

[ivan-mogilko]

I was not able to understand what is happening with the error yet,
but at the meantime, pushed a fix for unnecessary "bold" font in dialogs: efb9aaa

[Max833]

The way it crashes is pretty weird, though. So I'm not surprised you're not really sure what's going on there. ^^;

The font issue is indeed fixed! =)

[adm244]

The game crashes inside of its custom FaceObject function trying to call GetObjectY with an object returned by GetObjectAt at mouse cursor which is null in new engines and -1 in old engines.

// at line 289 in room2.asc
FaceObject(GetObjectAt(mouse.x,mouse.y));

// in GlobalScript.asc
function FaceObject(int obj) {
    FaceLocation(EGO,GetObjectX(obj),GetObjectY(obj));
}

[ivan-mogilko]

The game crashes inside of its custom FaceObject function trying to call GetObjectY with an object returned by GetObjectAt at mouse cursor which is null in new engines and -1 in old engines.

GetObjectAt returns -1 for "no object" in the new engine too. It's Object.GetAtScreenXY that returns null.
We cannot return a different type or return value in the new engine, or the old functions (and hence old games) won't work correctly at all.

EDIT: but in any case, the problem is that it returns "no object" if the cursor is no longer over the object it was clicked on, and therefore GetObjectY will error. In the original game it somehow kept the reference to either coordinates, or original object id.
This is just my speculation, but maybe something did not update during the blocking character walk to object, but it does update in the new engine.