Menu Bar Issues

[NilG]

Hi again, a couple of lingering questions I have (and quite possibly the last I'll have, at least for a while).

I'm encountering two problems/unexpected behaviors with my menu bar options:

1)  As the attached image shows, the text for "Inventory" is screwed up.  I've tried changing this text to Inv and a couple of other things, but for reasons I can't figure out, this particular string is consistently getting mangled regardless of what's in it, while the others seem fine.

2)  When I hit Esc throughout play, my Hints On/Off box pops up.  This should be triggered by Ctrl-H, and I don't see any reason that Esc would also trigger.

My best guess for these issues, of course, is coder error, haha.  This is the init for my MenuBar script, where I assume the problems are:

Code: [Select]

(class TheMenuBar of MenuBar
(properties
state 0
)

(method (init)
(AddMenu { Game_} {About Game`^b:Help`#1:Toggle Hints`^h})
(AddMenu
{ File_}
{Restart Game`#9:Save Game`#5:Restore Game`#7:--! :Quit`^q}
)
(AddMenu
{ Action_}
{Pause Game`^p:Inventory`^i:--!:Retype`#3:Look At`^l:Read`^r:Recall`^e:Ask About`^a:Tell About`^t:--! :Colors`^c}
)
(AddMenu
{ Speed_}
{Change...`^s:--!:Faster`+:Normal`=:Slower`-}
)
(if (DoSound sndSET_SOUND)
(AddMenu { Sound_} {Volume...`^v:Turn Off`#2=1})
else
(AddMenu { Sound_} {Volume...`^v:Turn On`#2=1})
)
(if (< (Graph grGET_COLOURS) 9)
(SetMenu MENU_COLOURS 32 0)
else
(SetMenu MENU_COLOURS smMENU_SAID '/color')
)
(SetMenu MENU_SAVE smMENU_SAID 'save[/game]')
(SetMenu MENU_RESTORE smMENU_SAID 'restore[/game]')
(SetMenu MENU_RESTART smMENU_SAID 'restart[/game]')
(SetMenu MENU_READ smMENU_SAID 'read[/book]')
(SetMenu MENU_HINTS smMENU_SAID 'hint')
(SetMenu MENU_QUIT smMENU_SAID 'done[/game]')
(SetMenu MENU_PAUSE smMENU_SAID 'delay[/game]')
(SetMenu MENU_INVENTORY smMENU_SAID 'all')
)

Does anything look off here that could account for either of these issues?  I've got to be missing something.

[Kawa]

Directly copy-pasting this and substituting $0103 and $0306 for MENU_HINTS and MENU_READ, I can't reproduce the  in a fresh template. So that checks out the part you posted here.

I'm reminded of the last time I tried to build a menu to demonstrate the SCI11+ features, and used the wrong separator character. Fun times figuring out why it rendered so slowly.

[troflip]

Could be some kind of memory corruption (although the switch from lowercase v to uppercase is suspicious).

What does the string look like in the compiled script resource? (Script->Disassemble)
What happens if you add a character before the v in inventory? Does the corruption shift? Or not?

[NilG]

That sounds fun for sure, ech.  I tried copying just the surrounding Inventory bit from QFG1 or 2 and the issue persists, I really don't see anything wrong with the syntax, as much as I look at it.

I ran a few tests; interestingly, it seems that the third and fourth letters become a capital V and a long space no matter what I put in there.  Intventory, Inmventory, and Invtentory all look like the original picture with the exception of the fact that the "e" then appears such as "InV  entory"

The attached two show if I use just "Inv" which ends up showing the ^i at the end, and "Stuff" for good measure, which shows the same behavior as any of the above "Inventories."

So something's pissing it off about the third and fourth letters, plus it's showing the actual ^i command for some reason if the text is short enough.  Also, both Ctrl-I and Tab do work to bring up the inventory, so it's functionally all there.


Just ran a couple more tests:

1)  Swap Pause Game and Inventory and now Inventory is fine and Pause Game is messed up, except in this case it's the 4th and 5th letters that get screwed up.  Interesting, as both options are the same number of chars.

2)  Stick "Inventory" anywhere in the chain below the divider in with Read, Recall, etc, and it's fine.  The whole damn list shows just fine.

So at least I can do that, but the why of it...

[troflip]

Like we suggested, your syntax is fine. Sounds like something is writing to the memory in that location though.

Did you check if this happens at runtime or compile time?

[NilG]

Oops, my bad.  This means it occurs at runtime?  Which I guess would also point to the memory corruption/conflict?

Code: [Select]

string_06a3 "Pause Game`^p:Inventory`^i:--!:Retype`#3:Look At`^l:Read`^r:Recall`^e:Ask About`^a:Tell About`^t:--! :Colors`^c"
If so, I can begrudgingly move the Inventory option to an inferior position in the list.  Life, somehow, would continue.  Probably.

EDIT:  Soooo, I put Inventory down below the divider before Retype and Tab/Ctrl-I stopped working.  If I stick it below Retype, Tab/Ctrl-I function as retype and F3 does squat.  I guess if there's something causing an issue in the memory there, it's going to cause some kind of tangible issue regardless. 

[troflip]

Yeah, you need to nail down what's causing the memory corruption. If you attempt to work around it, it'll probably just show up elsewhere, perhaps in a more difficult to debug spot.

Does the debugger built in to SCI let you set memory write breakpoints? I forget...

At least you should be able to put a bp on TheMenuBar's init method and see if the corruption has already happened there. I dunno know if SCI copies the strings you pass in into some other memory, or just references the originals in script. Shouldn't be too difficult to figure out though.

Are you doing anything "weird" anywhere else?

[NilG]

I may be way off, bp = base pointer?  Besides pushing and popping, assembly's foreign to me.  Not something I'd be adverse to looking into, though.  But again, I could be way off base in my understanding.

I don't think I have the know how to do anything particularly weird, haha.  I didn't tool with the MenuBar script much beyond necessity.  On the other hand, I very likely have some convoluted code throughout just from inexperience and only a partial grasp of the language.

[troflip]

bp probably means breakpoint.

Have you tried to get your game running in ScummVM? It has much better error checking - if you're stomping script strings it might spew some warnings or something. And it has a well-documented debugger that (I'm almost sure) has write breakpoints, so it'll break when a particular memory location is written to.

Another thing you could do to narrow down where this happens is make a procedure that prints out the string. Then call that procedure at various times in that script. Like:

Code: [Select]

(procedure (PrintBadMem)
(FormatPrint {%s} {Pause Game`^p:Inventory`^i:--!:Retype`#3:Look At`^l:Read`^r:Recall`^e:Ask About`^a:Tell About`^t:--! :Colors`^c})
)

SCI Companion coalesces identical strings, if this procedure is placed *after* the original reference to the string in the script file, the position in memory of the string should remain unchanged.

Although I kind of suspect the real problem is more complicated. Such as
- Maybe you're force unloading the script (via DisposeLoad in Main.sc?) and still calling code in it?

[NilG]

I'll have to try stepping through as suggested and see what happens.

It hasn't run through ScummVM yet; I used SVM once years ago to play through Sam and Max a bit, but am not super familiar with it.  It seems to play other fan games quite well, but I'm getting some kind of error attempting to load the game, a hashing issue with the resources that's mentioned elsewhere on this forum.  I'll play with it, though; theoretically it's working with fan SCI0 games and has for years, so there's probably something to be done.

Don't *think* DisposeLoad's tanking it from a glance, but I'll definitely take a look through things for that sort of possibility as well, not a thing I'd considered for sure.

[NilG]

Decided to revisit this a bit today, as I'm moving onto a new section of the game and figure it's probably worth figuring out memory issues sooner rather than later...

I've confirmed that DisposeLoad isn't disposing of the MenuBar script in Main.sc (and double-checked the script constants to make sure I didn't get that confused somewhere.

I made sure the latest ScummVM was installed, but get the following when I try to load it:

Code: [Select]

The game in 'C:\Users\nil_g\Documents\Projects\Games\Sect of Achturan\The Sect
of Achturan\' seems to be an unknown SCI [SCI0, SCI01, SCI10, SCI11, SCI32]
engine game variant.

Please report the following data to the ScummVM team at
https://bugs.scummvm.org/ along with the name of the game you tried to add and
its version, language, etc.:

Matched game IDs: astrochicken, christmas1988, christmas1990, iceman, camelot,
longbow, ecoquest, funseeker, hoyle1, hoyle2, hoyle3, jones, kq1sci, kq4sci,
laurabow, lsl1sci, lsl2, lsl5, cnick-lsl, cnick-kq, cnick-laurabow,
cnick-longbow, cnick-sq, mothergoose256, msastrochicken, pq2, qfg1, qfg2,
sq1sci, sq3, sci-fanmade

  {"resource.001", 0, "ae5701f8065566ae0083be1717c9a7d5", 956919},
  {"resource.map", 0, "9ada910254421dc90fe7692567b2c799", 1614},
I've seen this issue noted on the forum, although can't find it for the life of me right now, so I'll take another look when I'm a little more together to see if I can get that running.

I've also plugged in the PrintBadMem procedure, but found it's returning as expected when I call it in the title screen/first room, although the menubar is already displaying wrong by then (so I assume it already should be coalescing).  The string looks right, so I'm not sure if this tells us anything or if, just as likely, I'm doing something wrong.

I did notice that throughout the game the incorrect characters on display within the Inventory text appear to change.  They also changed to a "> " when I added/ran with the PrintBadMem procedure.  Perhaps this can help track down where things are occurring?

Because I'm so green at programming, I'm trying to wrap my head around memory population and order.  Do include and use statements get substituted during preprocessing or linking?  Does this even affect the order of memory population, or am I just wrong altogether?  I've started delving a little deeper into coding, but it's still pretty alien to me.  I'm sure I can find these answers somewhere else, if it's a lot.

But unfortunately, I'm still struggling to figure out where the issue here might lie.  If memory's getting overwritten/corrupted, does the fact that it's only like two or three letters mean that it's just plugging in like 3 bytes where it shouldn't be?  Am I wrong in assuming that that means there's probably something screwed up somewhere else, wherever it's expect that memory to be in line with whatever else it's supposed to be doing?

Sigh.  Guess I won't give up my day job.

[troflip]

Because I'm so green at programming, I'm trying to wrap my head around memory population and order.  Do include and use statements get substituted during preprocessing or linking?  Does this even affect the order of memory population, or am I just wrong altogether?  I've started delving a little deeper into coding, but it's still pretty alien to me.  I'm sure I can find these answers somewhere else, if it's a lot.

include's are basically a preprocessing thing.

use's just help the compiler resolve class names or public procedure names. Ideally we probably wouldn't even need them, but I guess they could help resolve duplicate procedure names (public procedure with same name defined in multiple files... but why do that?). I suspect use statements were just a performance thing for Sierra, or maybe they used them because it helped make it clear which script file depended on which others?

But unfortunately, I'm still struggling to figure out where the issue here might lie.  If memory's getting overwritten/corrupted, does the fact that it's only like two or three letters mean that it's just plugging in like 3 bytes where it shouldn't be?  Am I wrong in assuming that that means there's probably something screwed up somewhere else, wherever it's expect that memory to be in line with whatever else it's supposed to be doing?

Yes, that would be a good guess. That's why I suspected it might be the case that the MenuBar script is being unloaded or something.

I think ScummVM uses a checksum thingy to try to figure out which version of SCI it should be running. But I thought there was a way to tell it "this is an SCI0 game from SCI Studio/SCI Companion".

[Kawa]

I think it was naming your main class the same as an existing game? Same way the SCI11 template is named SQ5?

[NilG]

That could be it, regarding ScummVM; I've renamed it and now it's saying it can't find game data, so I'll step through that set of stuff to see if I can figure anything out.

I've found that I can reproduce in the template game by copying the game.sh and a slightly modified version of MenuBar.sc (just modded to remove references to globals/publics in my Main).  Attaching here. if anyone's kind enough and inclined to take a look.  From what I can tell, the game.sh setup is right, and I'm guessing the problems would be more drastic if not, so that leaves something in MenuBar?

EDIT:  Alrighty, if I comment out this bit:

Code: [Select]

(if (< (Graph grGET_COLOURS) 9)
(SetMenu MENU_COLOURS 32 0)
else
(SetMenu MENU_COLOURS smMENU_SAID '/color')
)
the Inventory text is fixed and everything seems to work throughout the menu, except Colors which just does nothing at all.  Colors actually doesn't seem to work whether I leave the code in or not (which I'd failed to notice before), so not sure if it's related.  This bit appears verbatim to the template game, although I'm using Sierra Script here.  Not sure if the difference could be in that?  I'm not really certain what the first condition is checking/doing, so while it seems technically valid, I don't know if it's doing something weird.

Anyway, this seems to be the stomper, or at least it's making all the visible difference when I comment it out so far as I can tell...

[NilG]

Taking another look at this, now that I've switched to flags, gotten that working, and cleaned up a bunch of other stuff.

I see that Graph's a Kernel thing, and grGET_COLOURS is defined as 2, but I'm having some trouble figuring out just what this is doing.  Can/Does grGET_COLOURS get redefined to make this statement false in some cases?  Is there a reason this chunk could be screwing with my memory use?  As noted, the Colors function doesn't seem to work anyway in my game or when I plug those two above files into the template, though it does in the raw template, so I must still have something weird going on in my MenuBar script, but I'm having trouble seeing what it is.