Author Topic: SCI 1.1 - Game class, newRoom method  (Read 1022 times)

0 Members and 1 Guest are viewing this topic.

Offline gumby

SCI 1.1 - Game class, newRoom method
« on: February 11, 2022, 09:00:09 PM »
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?


In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline doomlazer

Re: SCI 1.1 - Game class, newRoom method
« Reply #1 on: February 11, 2022, 10:19:57 PM »
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.
« Last Edit: February 12, 2022, 11:55:04 AM by doomlazer »

Offline Kawa

Re: SCI 1.1 - Game class, newRoom method
« Reply #2 on: February 12, 2022, 07:09:50 AM »
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.

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #3 on: February 12, 2022, 07:49:35 AM »
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.


In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline Kawa

Re: SCI 1.1 - Game class, newRoom method
« Reply #4 on: February 12, 2022, 09:18:14 AM »
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?

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #5 on: February 12, 2022, 09:37:00 AM »
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.
« Last Edit: February 12, 2022, 11:42:06 AM by gumby »
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline troflip

Re: SCI 1.1 - Game class, newRoom method
« Reply #6 on: February 13, 2022, 12:13:37 PM »
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?)
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #7 on: February 13, 2022, 02:27:04 PM »
Oof.  ScummVM locks up too - in that state I can't get the debugger to open.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline troflip

Re: SCI 1.1 - Game class, newRoom method
« Reply #8 on: February 13, 2022, 03:09:45 PM »
Where exactly is your handsOn/handsOff?

You mentioned something about a changeState method? How does that factor in?
Check out my website: http://icefallgames.com
Groundhog Day Competition

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #9 on: February 13, 2022, 03:56:56 PM »
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.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline doomlazer

Re: SCI 1.1 - Game class, newRoom method
« Reply #10 on: February 13, 2022, 08:44:17 PM »
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:)
      ...

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #11 on: February 14, 2022, 09:23:41 AM »
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.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition

Offline doomlazer

Re: SCI 1.1 - Game class, newRoom method
« Reply #12 on: February 14, 2022, 11:02:40 AM »
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?
« Last Edit: February 15, 2022, 09:58:18 PM by doomlazer »

Offline gumby

Re: SCI 1.1 - Game class, newRoom method
« Reply #13 on: February 15, 2022, 09:12:04 AM »
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.
In the Great Underground Empire (Zork port in development)
Winter Break 2012 Rope Prop Competition


SMF 2.0.19 | SMF © 2021, Simple Machines
Simple Audio Video Embedder

Page created in 0.135 seconds with 23 queries.