Possible Bug: Wait() behaves differently

[Old Guy]

Wait() is behaving differently in different situations. Either it’s a bug, or I am using Wait() when it is inappropriate to do so. Please advise.

I am using:
AGS 3.0.2.41 (Also experiencing this problem in 3.0.2.40)
Game built using default game template
Windows 2000 SP4


Consider this script for a room in which the character happens to be Not Visible . . .

1   //***************************************************
2   // Room 52: Shed Interior                           *
3   //***************************************************
4
5   //*----------------------*
6   // When we load the room *
7   //*----------------------*
8   function room_Load()
9   {
10  mouse.EnableMode(eModeLookat);
11  mouse.Mode = eModeLookat;
12  PlaySound(1);
13  Wait(15);
14  PlaySound(2);
15  }


This script works just fine when room 52 is entered via another room using player.ChangeRoom (52), but it does not work when the character is started out in room 52.

This is not really an issue for me, because I would not normally be starting the player in this room; I was only doing this to test the room.

----------
Here’s the error message that is issued:

An error has occurred. Please contact the game author for support, as this is likely to be a scripting error and not a bug in AGS.
(ACI version 3.02.1023)

in “room52.asc”, line 13

Error: A text script run in the Player Enters Screen event caused the screen to be updated. If you need to use the Wait(), do so in After Fadein

[Rui 'Trovatore' Pires]

I dunno why it's working sometimes, but basically you should never use Wait in "Player Enters Screen", like the message says. It used to be call "Player Enters Screen Before FadeIn", if that helps clear it out - its stuff that gets run in a singly cycle, before the room is loaded, or before the room is displayed, or whatever. It's why it says what is says on the message - the screen's not supposed to update at that stage, it's only a one-cycle moment in which you can make preparations.

If you want to, say, have two sounds with 15 cyles of wait between them in a pitch-black pre-fade-in room, then use a GUI or overlay to black it all out, or an object, a character, or use the FadeIn() FadeOut() functions to black the room out and then fade it back in - and do it all in "After FadeIn".

[Old Guy]

Rui,

Thanks very much for your response!

However, I was hoping for a more definitive answer from the AGS group. Either Wait() at room load time is allowed or it’s not. Given that it works in one situation but not in another, in my mind, means that it is a bug.

I am new to using AGS, but my limited understanding of the things that you can do at room load, seem to indicate that you can do anything that doesn’t require an update to the screen graphics (because the screen is not yet displayed). I don’t quite understand why Wait() would be one of the disallowed functions.

Still wondering . . .

[Khris]

Well, Wait() causes the screen to be redrawn.

I imagine with a room change, the screen is already there, just black, so calling Wait() won't crash the game.
But if you start in the room, the screen isn't there until it's gonna fade in, after room_Load().

[Pumaman]

There's a bit of history behind this.

Basically, you should never use any blocking calls, such as Wait, in the Room_Load event. As KhrisMUC describes, when Wait(15) is run, it will run 15 game cycles and attempt to redraw the screen 15 times -- but it is still faded out.

Initially, AGS would let you do this but it cocked up the palette and caused unexpected problems. So as a result of that, I added a check that would error out if you used a blocking call in Room_Load. But then that broke some people's games, so to maintain backwards compatibility I took the check back out again.

However, I left it in for the very first room, because there has been no previous rendering to the screen when the game starts up, attempting to run a blocking call here was causing problems.

The solution is, as Rui says, to do any blocking commands in AfterFadein instead of Load.