SCI 1.1 - Game class, newRoom method

[gumby]

I'm having an issue where sometimes my game completely locks up between switching rooms. This is occurring in debug mode, and I get the message "Switching to room...", but the new room is never displayed and control is never returned to player.  Just "locked up".  Frustrating part is that it's not easily reproducible, so I'm looking for help.

Right now, I'm suspicious of this code block in the newRoom method, which seems like it could explain the lockup:

Code: [Select]

...
(self startRoom: gRoomNumber)
(while ((= temp5 (Event new: 3)) type?)
(temp5 dispose:)
)
(temp5 dispose:)
...

...which is a head-scratcher.  What is the point of the loop that generates events and checks to see if a type is defined until it breaks out of it?

[doomlazer]

I know that when I was working with KQ4 if (HandsOff) was enabled it would prevent room changes and lock the game. Sounds like you've disabled player control when this happens, so maybe it's something similar?

Edit: Looking at the template game, event type 3 is a mouse event, so the code you posted seems like it's checking if player controls are enabled in a roundabout way.

[Kawa]

What this does is eat any pending mouse clicks so you can't "buffer" any actions before the new room appears. Here's what it looks like in the original Larry 5 code:

Code: [Select]

;Eat all mice downs and mice up.
(while ((= evt (Event new: (| mouseDown mouseUp))) type?)
(evt dispose:)
)
(evt dispose:)
Input events are produced by the engine and queued up. The Event::new method calls the GetEvent kernel to fetch the next event from that queue, of the given type if specified. So "eating the mice" just repeatedly fetches a mouse click event from the queue, leaving the keyboard stuff, and tosses them out, until there are no more mouse clicks left.

[gumby]

Thanks for the explanation on this.  It makes sense that while transitioning to a new room that mouse events should be ignored.  And yes, doomlazer, I recently put in handsOff/handsOn in the room init()s for my rooms ... but this code fires in the changeState method in the room script for the new room, not the room I'm leaving.

What is odd is that from an mouse event perspective, there shouldn't have been any mouse button events firing.  Unless I double-clicked the mouse when I was changing rooms - I *am* orchestrating room changes via mouse clicks, so this does make some sense that I've got a rogue mouse click that is giving me trouble.

[Kawa]

I *am* orchestrating room changes via mouse clicks, so this does make some sense that I've got a rogue mouse click that is giving me trouble.

Well ain't that interesting, hmm? What if you commented out the mice-eating?

[gumby]

Yes, just did.  So far, no lockups but I'll need to do a lot more testing before I'm satisfied that the problem is remedied.

EDIT: Ugh.  That's not it, time to look elsewhere.  I just discovered that creating a save game and then attempting to change rooms causes a lockup every time.  And removing the handsOff/handsOn from the destination room prevents a lockup.

[troflip]

Does it lock up in ScummVM too? If so, break into the debugger when it happens, and look at the stack trace and see if it's in an infinite loop somewhere.

(We still don't have a SCI 1.1. interpreter with debugger, right?)

[gumby]

Oof.  ScummVM locks up too - in that state I can't get the debugger to open.

[troflip]

Where exactly is your handsOn/handsOff?

You mentioned something about a changeState method? How does that factor in?

[gumby]

Here's my typical room script, which gets called on init() of the room.

Code: [Select]

(instance rmScript304 of Script
(properties)

(method (changeState newState)
    (= state newState)

(switch state
  (0
(gGame handsOff:)
(gGame setCursor: 997 1)
  (if (not (IsLight))
                   (DrawDarkness)
)
        (if (not (RoomVisited RV_CHECK))
      (= seconds VERBOSE_ROOM_DESCRIPTION_DELAY)
  else
      (= cycles 1)
        )
  )
  (1 
        (if (not (MovedIntoDarkPlace))
      (if (RoomVisited RV_SET)
         (rm304 roomLook:)
    )
)
(DoDaemons)
(gGame setCursor: gPreviousCursor 1)
(gGame handsOn:)
  )
)
)
)


Functionally, I'm trying to make it so that when the player first enters a room, it removes control from player, wait a couple of seconds, then the room description prints along with any other actions (DoDaemons) then return control to the player.

[doomlazer]

Are you calling changeState in the room init or just (self setScript: rmScript304)?

It might be interesting to try something like this to see what happens:

Code: [Select]

(instance rmScript304 of Script
  (properties)

  (method (changeState newState)
    (switch
      (0
         (= cycles 1) ;or 10, 100, etc.
      )
      (1
          (gGame handsOff:)
      ...


[gumby]

Yeah, I'm not calling the changeState directly, just doing a setScript call.

I tried adding another state with just a (= cycles 1) and while that allows the room to fully init (paint the pic etc), it still locks up.  By adding a few DebugPrint statements, I was able to confirm that it's locking on the (gGame handsOff:) call.

[doomlazer]

I see in the SCI1.1 template game that there is (gGame handsOff:), but also (SQ5 handsOff:) defined in main.sc. Does using (SQ5 handsOff:) change anything?

[gumby]

Same outcome.  I don't see any difference in the behavior, locks up the game in the same place as using the gGame handsOff/handsOn methods.