SCI0: Varibles and changestates

[robbo007]

I think your onto something here. I did not fix the Trite phrase yet but it does the same thing when I add a trite phrase and change rooms.

My main.sc has the following line:

Code: [Select]

(User alterEgo: (= gEgo ego) blocks: 0 y: 150)
I can't seem to find the equivalent for adding this part: (= ego egoObj) or is it (= gEgo ego) ?

[robbo007]

OK, so this seems to be connected to the same issue as your earlier ego initialization problem (in the trite phrase thread). The debugger hits at a callb $1 instruction, which is the first instruction after the fault. callb $1 corresponds to (SetUpEgo), so the faulting instruction is one of the sends just before that line, which both send to gEgo. You can double-check by viewing the value of gEgo (global 0): In the debugger, press g then enter the number zero. The next input box after that lets you see the current value of global 0, and optionally to change it. I am guessing that gEgo is 0 at this point.

What did you do about the problem in the trite phrase thread?

You are right its gEgo is 0. Do you know why is it not picking up the changes I've made to main.sc ? Or is my syntax in main.sc wrong?
Regards,

[lskovlun]

It must have picked up that change. After all, you couldn't start the game before, and now you can walk into the bar...? So gEgo is either being reset, or there's memory corruption going on. Given those suspicious bits of code I quoted earlier, I'm betting on the latter, though I'm struggling to see how the very first global variable could be affected. Is your string array declared correctly? Did you get rid of that "passwd = ken sent me" thing?

[robbo007]

Right I've found the issue. I was using this script taken from LSL3 to check the changeState numbers to troubleshoot my changeState scripting. It displays the State number at the top of the screen in realtime. Any ideas why that causes the crash? Its a very handy little script.

I call this on my method for the peephole door changeState:

Code: [Select]

(method (changeState newState)
(ShowState self newState 1 2)
(switch (= state newState)

Code: [Select]

;;; Sierra Script 1.0 - (do not remove this comment)
;**
;** Logics for room 797 -- Just a showState procedure
;**
;** Leisure Suit Larry 4 - Never say Nontoonyt (AKA The Missing Floppies)
;**
;** Last Update: October 8th, 2024
;**
(script# 797)
(include sci.sh)
(include game.sh)
(use Main)

(public
ShowState 1
)
(procedure (TestFlag flag)
(return
(if (& [gFlagArray (/ flag 16)] (>> $8000 (mod flag 16))) 1 else 0)
)
)
(procedure (ShowState whatScript newState where color &tmp [str 33])
(if (and gDebugging (not (TestFlag 14)))
(if (< argc 2)
(= where 1)
)
(if (< argc 3)
(= color 7)
)
(Display
(Format @str 797 0 (whatScript name:) (whatScript state:) newState) ; "%s was state %d; is now state %d."
dsCOORD
1
(- (* 8 where) 7)
dsFONT
999
dsCOLOR
color
dsBACKGROUND
0
)
)
)


[doomlazer]

Is script 797 getting disposed when changing rooms? Just a guess, but if it's a memory fragmentation error or heap crash you might try adding (DisposeScript 797) to the Game::newRoom method when it's cleaning up everything else.

[lskovlun]

startRoom is the usual place for this. LSL3 even overrides it, so there's a natural place to add your script (the LoadMany FALSE call).

[doomlazer]

Thanks I looked briefly for that loadmany false, but couldn't remember where they put it. Been a while since I've needed to do that

[robbo007]

Amazing guys that did the job.

So I've added the show_state script 797 to my main.sc but I dont really understand what's happening and why would I need to add something there? What is it doing and what is best practice here? Should I be adding other scripts here like my regions path script maybe? Does this free up heap space as I'm already skating on thin ice with that.

Code: [Select]

(method (startRoom roomNum)
(DisposeLoad
NULL
FILEIO_SCRIPT
JUMP_SCRIPT
EXTRA_SCRIPT
WINDOW_SCRIPT
TIMER_SCRIPT
FOLLOW_SCRIPT
REV_SCRIPT
DCICON_SCRIPT
DOOR_SCRIPT
AUTODOOR_SCRIPT
WANDER_SCRIPT
AVOID_SCRIPT
DPATH_SCRIPT
SHOW_STATE ;script 797
)
(DisposeScript DISPOSELOAD_SCRIPT)

[lskovlun]

It's to avoid heap fragmentation (where there is lots of memory available, but you can't allocate a single block that's large enough for the task at hand). I don't know how doomlazer connects this to a NULL gEgo, though. BTW, there is a kernel call ShowFree that tells you how much heap is available. It may be useful if you're having problems with free heap.

[doomlazer]

I don't know how doomlazer connects this to a NULL gEgo, though.

I think there were two issues. Robbo fixed the ego problem you spotted, but the showState script was still fragmenting memory. I'm too lazy to read through everything again to check if that's right.

What is it doing and what is best practice here? Should I be adding other scripts here like my regions path script maybe? Does this free up heap space as I'm already skating on thin ice with that.

Essentially you've got scripts that always live in memory like main, game, etc.. Then you have scripts that are loaded when a room script uses them. On room change, everything that was loaded for that room needs to get disposed to keep memory unfragmented. Some stuff, like actor instances, get cleaned up automatically because the lsl3 (or template game) code was already written to do so.

When I looked at Sluicebox's lsl3 decompile, I couldn't find script 797, so I assumed you had imported this yourself, copied from the lsl3 source code. The game isn't going to automatically know to dispose new scripts you add. Since you are calling this new script from a room script, you need to be responsible for cleaning it up. You're using it across more than one room, so disposing in startRoom is an effective way to ensure it's cleaned up every room change. DisposeScript safely ignores any of the args that weren't loaded in a given room.

I'm guessing you're adding (use SHOW_STATE) to the top of each room script? Another way to call showState would be:

Code: [Select]

;(ShowState self newState 1 2)
((ScriptId SHOW_STATE 1) self newState 1 2)
(DisposeScript SHOW_STATE)

This loads script 979 then calls method index 1 (ShowState has been assigned 1 in the script's public methods). Once the method returns, it's cleaned up by the DisposeScript call. No need to add (use SHOW_STATE) to the room script and script 979 isn't taking up heap the entire time the player is in the room.

It gives you a bit more control over the heap, but in the case of SHOW_STATE it's probably better to leave it as you have it now. You need enough heap for the room + 979 when ScriptId gets called anyway.

I'm not clear what 'regions path' is, but regions are generally going to be disposed by newRoom automatically.

Here's some great info on heap fragmentation: https://sciprogramming.com/tutorial.php?entry=5402

[lskovlun]

Scripts can even dispose themselves. Sierra used this a lot. It's technically a use-after-free situation, so you must be careful what you do afterwards.