Community
SCI Programming => SCI Syntax Help => Topic started by: robbo007 on September 26, 2024, 04:35:18 PM
-
Hi guys,
I'm trying to implement something like the Trite Phrase used in LSL2 or the Expletive in LSL3. The LSL2 version seems a lot simpler but I'm getting a crash when using the code in my main.sc
I've added the following to my main.sc
(= gExpletive (Format @gExpletiveBuffer 976 0)) ; "Have a nice day."
and I've added the following to menubar.sc
(AddMenu
{ Action_}
{Pause Game`^p:Inventory`^I:Retype`#3:--! :Colors`^c :Ask about`^a :Boss Key`^b :Lowe-O-Meter\05`^h :Expletive`^x};:Expletive`^x
)
(MENU_EXPLETIVE
(GetInput (Format @temp4 gExpletive) 38
{Enter your favorite expletive:}
)
(if (> (StrLen @temp4) 4)
(Format gExpletive @temp4)
)
)
The game.sh has:
(define MENU_EXPLETIVE $0309)
And I have a text file created 976 with the 0 entry holding "Have a nice day"
I get the opps error when starting my game. Using the debug commands I see its getting stuck in room 290 init. This room runs a speed checker for real hardware at startup.
(method (init)
(ProgramControl)
(= gProgramControl FALSE)
(SL disable:)
(TheMenuBar hide:)
(super init:)
(gEgo
view: 290
posn: 20 100
setStep: 1 1
setMotion: MoveTo 3000 100
setCycle: Walk ;even though view.290 has only one frame, the overhead of a Cycler makes the simulation more realistic.
init:
)
(gGame setSpeed: 0)
)
-
Did you insert the new variable in the middle of the existing globals, and if so, did you remember to recompile everything? It may be a good idea in any case...
-
Hi,
I did, I've got gExpletive defined in my main.sc. Recompiled all.
Regards,
-
You can put (SetDebug) at the beginning of rm290::init and it will break into the debugger when you get there. Then either step through or move the SetDebug later and later until you hit the problematic statement.
-
Amazing thanks for the pointer. I did not know that syntax. It works very well. I find it easier to understand the stack than the actual debug code.
So its seems its failing on all startup rooms that have the:
(PlayerControl)
(ProgramControl)
If I comment these out it gets to my first room #29 then crashes with the infamous out of heap space error.
I see in room 29# I have:
Free Heap: 2022 Bytes
FreeHunk: 40KBytes
Maybe putting the Trite menu item in the main.sc is a bad idea? As it uses more memory right? In LSL3 they don't seem to use it in the main.sc
What things can help free up Heap and Hunk? I think I need to optimise my code a little more.
-
I went and looked at the code for PlayerControl/ProgramControl, and they both do (ego setMotion: 0), i.e. stop ego. Now, room 290 (as taken from LSL3) doesn't have an ego, so this ought to fail in LSL3 as well, but doesn't.
I don't think this is because of your menu item. There must be something else you've changed. LSL3 sets up ego in the main script like this:
(User
alterEgo (= ego egoObj),
blocks FALSE,
; echo SPACEBAR,
; x -1,
y 150,
)
did you change or move this?
-
Sorry for the hiatus.
So I have in my main.sc
(User alterEgo: gEgo blocks: FALSE x: -1 y: 150)
I don't have the "echo SPACE" syntax as it does not like it. I'm not sure if its needed?
I've tried to simplify the command a little more in my 290 script:
(= gExpletive ;this is causing startup not to work
(Format @gExpletiveBuffer 290 1)
)If I use %s in my text file 290 1 it works but does not show a default Trite phrase when selecting it from the menu. You can enter in a new one and it seems to work fine. If I change the %s for "Have a nice day" that's when it crashes on the ProgramControl syntaxes.
-
I don't have the "echo SPACE" syntax as it does not like it. I'm not sure if its needed?
It was a comment in the snippet of code Lars posted... See the semicolon? So it wasn't included.
So was x: -1...
So the equivalent to
(User
alterEgo (= ego egoObj),
blocks FALSE,
; echo SPACEBAR,
; x -1,
y 150,
)
would be
(User alterEgo: gEgo blocks: FALSE y: 150)
-
(User alterEgo: gEgo blocks: FALSE y: 150)
You missed the most important and subtle part of this, actually. gEgo is 0 before this point, and as a side effect of setting alterEgo, it also assigns a value to gEgp:
alterEgo (= ego egoObj),
-
As you guys mentioned in the other post this error seems to be similar. If I add the trite phrase via the menu it will then crash when I change rooms.
-
Sluice's decompile has the menu item as switch 776 (https://github.com/sluicebox/sci-scripts/blob/5ce19d3be606f2f9a758f54144904d201bc4a8e9/lsl3-dos-1.021/src/Menu.sc#L279). You define MENU_EXPLETIVE as $0309. 0x0309 is decimal 777, so presuming `^x is 776 this shouldn't trigger at all, right? You've said "If I use %s in my text file 290 1 it works but does not show a default Trite phrase when selecting it from the menu.".
Did you do that background? Pretty cool.
-
Sluice's decompile has the menu item as switch 776 (https://github.com/sluicebox/sci-scripts/blob/5ce19d3be606f2f9a758f54144904d201bc4a8e9/lsl3-dos-1.021/src/Menu.sc#L279). You define MENU_EXPLETIVE as $0309. 0x0309 is decimal 777, so presuming `^x is 776 this shouldn't trigger at all, right? You've said "If I use %s in my text file 290 1 it works but does not show a default Trite phrase when selecting it from the menu.".
But that's not what causes the crash (see my analysis in the other thread).
-
Sluice's decompile has the menu item as switch 776 (https://github.com/sluicebox/sci-scripts/blob/5ce19d3be606f2f9a758f54144904d201bc4a8e9/lsl3-dos-1.021/src/Menu.sc#L279). You define MENU_EXPLETIVE as $0309. 0x0309 is decimal 777, so presuming `^x is 776 this shouldn't trigger at all, right? You've said "If I use %s in my text file 290 1 it works but does not show a default Trite phrase when selecting it from the menu.".
Did you do that background? Pretty cool.
So if I define the @gExpletiveBuffer in room 290 to use a pre-filled text like (= gExpletive (Format @gExpletiveBuffer 290 1)) ; "Have a nice day." I get the crash on start up. (Attached picture)
If I define it to use the variable %s: (= gExpletive
(Format @gExpletiveBuffer 290 0) ;%s
)
It does not crash on startup, you can enter in a expletive text and if calling the @gExpletiveBuffer in your roomscript you do get it printed on screen. When changing rooms it will crash if the number of characters entered into the expletive is more than 8.
-
Question. How is gExpletive defined to begin with?
In the LSL games, the trite phrase and expletive are specifically defined as 20 words/40 characters In SCI Companion, that'd be (local ... [gExpletive 20] ...).
When changing rooms it will crash if the number of characters entered into the expletive is more than 8.
This kinda made me think, y'see? The 38 is supposed to limit the possible input length, but if the target buffer isn't actually at least that long...
(Edit: corrected, I misread the OG source)
-
Question. How is gExpletive defined to begin with?
In the LSL games, the trite phrase and expletive are specifically defined as 20 words/40 characters In SCI Companion, that'd be (local ... [gExpletive 20] ...).
(Edit: corrected, I misread the OG source)
I was looking at the original source and its defined in script 10. I see other comments in the code as you mentioned in the game.sh
filthLevelBuffer 170 ;** NOTE: 30 characters long
expletiveBuffer 200 ;** NOTE: 40 characters long
(expletiveI
(GetInput (Format @string expletive) 38
{Enter your favorite expletive:})
(if ( > (StrLen @string) 4)
(Format expletive @string)
)
)
I define it in the menubar.sc:
(MENU_EXPLETIVE
(GetInput (Format @temp4 gExpletive) 38
{Enter your favorite expletive:}
)
(if (> (StrLen @temp4) 4)
(Format gExpletive @temp4)
)
)
I also have these in my main.sc
gExpletive
;This is used for the expletive menu
gExpletiveBuffer
;This is the buffer used for the expletive menu
gFilthLevelBuffer
;This is the buffer used for the filth level
I've tried adding = 20 to the gExpletive and gExpletiveBuffer but it still crashes. Its gotta be something with the character length as using something with 8 characters works.
290.sc
(= gExpletive
(Format @gExpletiveBuffer 290 0) ;%s
)
(Format @gFilthLevelBuffer 290 0) ;%s
-
Like I said, that would be [gExpletive 20] in SCI Companion. gExpletive = 20 defines one variable preset to the number value 20, which is entirely different, while [gExpletive 20] would define gExpletive and then add nineteen more blank slots until the next global variable, which means there's space for 40 characters.
-
Like I said, that would be [gExpletive 20] in SCI Companion. gExpletive = 20 defines one variable preset to the number value 20, which is entirely different, while [gExpletive 20] would define gExpletive and then add nineteen more blank slots until the next global variable, which means there's space for 40 characters.
Aha! I did not know that. Thanks Kawa :)
Its seemed to have resolved the expletive issue. No crashing between rooms any-more :) But it has also created some bugs with the dying script when using the (Print (Format @string1 029 47 gExpletive) leaving the room and coming back and trying to die it get some random text added to my view. I need to troubleshoot it a little more.
Why does the sluicebox code not use this? It only declares it in the main.sc as a local gExpletiveBuffer and gExpletive.
-
(Print (Format @string1 029 47 gExpletive)
looks like you need to write @gExpletive instead? But one problem is that we don't have your code, so we are forced to guess all the time. I made some (admittedly vague) references to your variable declarations a long time ago.
-
Right solved.
I was not declaring my string1 correctly. Same problem as Kawa pointed out earlier. I needed to use [string1 40] in the local instead of what I was using string1.
From what I understand was going on here is its placing the gExpletive into string1 and it was not big enough to hold it hence the weirdness with the view naming error.
(Print (Format @string1 029 47 gExpletive)
Thanks again everyone :)