Community

SCI Programming => SCI Syntax Help => Topic started by: avo323 on November 05, 2025, 02:58:34 PM

Title: [LB2CD] approachVerbs causes inset to display graphical issues
Post by: avo323 on November 05, 2025, 02:58:34 PM

Hi! I'm having troubles with a strange phenomenon after coding some bugfixes for LB2CD's safe in Carrington's office (#560, #561). The CD version of LB2 ditched the auto-closing of the safe/picture that was present in the floppy version, but that decision brought multiple side effects they overlooked (apart from the infamous "unable to open picture" bug).

Since they let the picture stay open, the player can try to use verbs from afar on it, on the safe or on the safe's door. None of these props are initialized with approachVerbs (in the floppy version that makes sense because the painting would close before you could interact from afar to begin with), what leads to ego being able to trigger them as if Laura had a remote control. Considering this, I modified them so they're initialized with approachverbs, a pretty basic and straightforward alteration.

In #560, safePic:doVerb:

Code: [Select]

;((ScriptID 561 0) init:) ; safePicture
((ScriptID 561 0) init: approachVerbs: 4 1 8)
In #561, safePicture:init:

Code: [Select]

;(safe init: stopUpd:)
(safe init: stopUpd: approachVerbs: 4 1 8)
;(safeDoor init: stopUpd)
(safeDoor init: stopUpd: approachVerbs: 4 1 8)
Everything works well, except for one bizarre issue. When you use the DO verb on safeDoor, it has to set an inset of the dial (inDial). If you do it from afar, ego now correctly approaches the safe (yay!), but the moment the inset appears I get this:

(https://i.imgur.com/H7GaDMR.png)

And when the inset is disposed, remainders of it stay on screen. The funny thing is that this doesn't happen if I use the DO verb on safeDoor when ego is next to it and doesn't need to approach it (using the exact same code, just ego being close).

That inset is set by safeDoor:doVerb in #561:
https://github.com/sluicebox/sci-scripts/blob/12c1ab894c4bd5fbf4157eb18a9e86653ec15d1b/ra-cd-dos-1.1/src/safePicture.sc#L78-L130

And this would be the inDial inset, also in #561 (it initializes a ton of features):
https://github.com/sluicebox/sci-scripts/blob/12c1ab894c4bd5fbf4157eb18a9e86653ec15d1b/ra-cd-dos-1.1/src/safePicture.sc#L132-L182

I found out that by creating a simple instance of Script to wrap the "(gCurRoom setInset: inDial)" with a 1 cycle wait in the initial state, and attaching it to safeDoor:doVerb using "(gCurRoom setScript: sInDial)" instead directly setting the dial using "(gCurRoom setInset: inDial)" makes it properly display. Without the 1 cycle wait it'll still glitch.

Code: [Select]

(instance sInDial of Script
(properties)

(method (changeState newState)
(switch (= state newState)
(0 (= cycles 1))
(1
(gCurRoom setInset: inDial)
(= cycles 1)
)
(2 (self dispose:))
)
)
)
Does anyone know why this would happen? I'm suspecting the game requires a small delay to set it properly if ego approaches it, but I don't see any logic behind this. I'd prefer to avoid coding any new instance, including additional classes or add new methods if possible (as I'm not a fan of making heap patches if they're not strictly needed), but safeDoor is a prop and afaik these have no means to delay execution or execute things sequentially. Any suggestions are welcome. Thank you!