Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - gumby

Pages: [1] 2 3 ... 71
1
Thanks Kawa.

3
This is great.  At one point I was considering making a point-and-click version of Colossal Cave, similar to what I'm doing for Zork (if I can ever get it done).  Glad it's getting a reboot.

4
Nice!

5
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« 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.

6
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« 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.

7
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« 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.

8
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« on: February 13, 2022, 02:27:04 PM »
Oof.  ScummVM locks up too - in that state I can't get the debugger to open.

9
It could be done with a plugin I suppose.  Something that uses a file watcher task and monitors the patch files and upon change issues a commit to a 3rd party source control repo.  It's not really in the traditional spirit of source control (commits-on-change could result in a bunch of bad/useless commits), but that would fulfill the 'automatic' portion of your concept Collector.

10
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« 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.

11
SCI Syntax Help / Re: SCI 1.1 - Game class, newRoom method
« 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.



12
SCI Syntax Help / 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?

13
I think it's already built-in functionality under Properties?  "Manage resources as patch files (good for source control)"

14
Interesting. Good thing it has quick fix though, but too bad it requires no other changes or you lose stuff.

By the way, 3.2.4 has been out for a few months now. Who knows?
Thanks, just downloaded.

Not that it would be a viable solution, but can treating resources as patches still cause the same error?
I would think that would work, yeah.  If I continue to have problems I'll go that route.  In fact, maybe I should just do that anyway, would make versioning easier.

15
I've run into this issue a couple of times, but previously hesitated to report it as it's pretty tough to reproduce.  I'm getting an error on compilation of my game "Error enumerating items: Corrupt resource header - mismatched types."  For context, I was working on modifying a script - no other resource manipulation activities.

Game is SCI 1.1, I'm running version 3.2.3.2, Kawa's build.

EDIT: The quick-fix for this was to discard my resource file and map and recompile everything, which was viable for me because I hadn't introduced any other resources since my last commit.

Pages: [1] 2 3 ... 71

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

Page created in 0.04 seconds with 19 queries.