Inventory problem

[amirkle]

Hello friends. I've been working on my game for a year and a half now. It's been a slow process, 'cause I'm working solo, plus I have no background in programming, so it's like walking through a dark forest with a dying candle...  But i'm pulling through.

I came across a scary point today, though: after adding an inventory item to the inventory script, my game wouldn't load anymore. i get an error no. 5 (have no clue what it means). the game works fine if i delete the new inventory item, which makes me suspect i got too many items on my inventory list. problem is, i can't possibly make it to the end of the game without adding at least 10 more items. Got the story in my head and all, and i'm afraid I've come to a dead end. Let me say I DO have a lot of items on the Inv list, and that my scripts are badly written, the outcome of not coming from the programming world and not knowing any effective codes. I'm improvising as i go, and the game is pretty long already. I can actually smell the end, but without adding some more Inv items... probably can't be done.   please, any tips??

[Kawa]

E_BAD_SELECTOR. Try running the game on a debug build (attached) so you can see the full error: "'%s' is not a selector for %s.".

Also, how many items is many?

[amirkle]

E_BAD_SELECTOR. Try running the game on a debug build (attached) so you can see the full error: "'%s' is not a selector for %s.".

Also, how many items is many?

It works with as many as 38 Inv items. the 39th crashes the game...
can't run the file you sent for some reason.

[amirkle]

also, after crashing, i get this message:

"Timed out trying to start debugging functionality. This requires a compatible template game." at the output box

[Kawa]

I'd really appreciate if you could tell me more besides "can't run for some reason". I can't help you without such information.

Just to be sure, I dropped SCI.EXE into the folders for King's Quest 6, Larry 6, and Freddy Pharkas. Only Larry 6 refused to run outright because it uses the menu system. So that just makes me real curious as to what possible reasons we could be missing here.

[amirkle]

well, when I try to open the file I get a message it can't run on my pc. When I try to open it as an administrator it says it can't find it..

[Kawa]

It's a DOS program, like SIERRA.EXE is. You can't run those as-is. Rename SIERRA.EXE to anything else, then rename SCI.EXE to SIERRA.EXE and hit that run or debug button in SCI Companion.

Edit: looking at your screenshots again, also don't forget to put it in the same folder as your game.

[amirkle]

ok, got it!

does this one mean anything to you?

[amirkle]

ok, got it!

does this one mean anything to you?

I also get this one:

[Kawa]

Huh. I did not expect that. As I begin writing this, I'm officially stumped. That does not look like a selector name... more like some weird-ass script error ends up trying to invoke a selector with that absurdly-high number.

Seriously? 31890? The highest selectors are #4096 through #4103, and even they stand alone! The highest regular non-system selector in Gabriel Knight 2 is #918. So that's pretty out there.

But wait, it gets better! In the source code for the interpreter, if GetSelectorName fails to load a selector name, it just returns the buffer it was given untouched, so "7c92" isn't even the selector number -- it's just whatever happened to be in the memory area that the routine showing this error (or the "oops" one in a regular build) happens to contain! So this is next to useless after all that effort to teach you the basics of retrocomputing, except to show that it's a (doubly?) invalid selector.


What's nice is that the second screenshot can theoretically be used to find out where the issue happens exactly. Given a copy of the script file containing templateInventory and a copy of its disassembly, one might be able to deduce more about the problem's cause and possibly a solution.

But I may have an easier solution for your problem regardless. Or a workaround at any rate. Codename Iceman has several separate inventory sets throughout the game, spanning 34 items in total¹. so you might want to consider not adding all 40-something items in one go.

Perhaps the most sturdy solution would be to bite the bullet and do what the oops error said: rethink your strategy and try taking a different approach to the situation. Do you really need that many items? After all, that error is addressed to the developer, not the player.



¹: what's particularly interesting is that LSL6 has 42 items in total and KQ6 a whopping 52.

[lskovlun]

After all, that error is addressed to the developer, not the player.

Are you sure about that...? Developers would see the more specific error message. If not the player, the only people I can imagine the "Oops..." message would be addressed to are the beta testers; and I don't know what build they got. For all I know, it might include the debugger. Also, they changed the message. It was different in the very first SCI interpreters. "You have encountered an internal error" or some such.

Bonus info: I once put the "Oops..." message in a comment in something I was writing at work. Just as a comment, of course.

[troflip]

Doesn't the debug build of the interpreter have stack trace functionality? What's the stack trace? Should be an easy way to narrow down what's causing the problem.

Kawa's suggestion that something bad happened which resulted in trying to call an object with a ridiculous selector seems reasonable. As for what the root cause of *that* would be, my random guesses are:
- Some bug in SCI Companion's compiler
- Some kind of out of memory thing because you're using so much memory with inventory items (which are loaded all the time)
- Some bug in your new inventory item (pretty easily ruled out by removing other items and keeping your new item in)

[amirkle]

Doesn't the debug build of the interpreter have stack trace functionality? What's the stack trace? Should be an easy way to narrow down what's causing the problem.

Kawa's suggestion that something bad happened which resulted in trying to call an object with a ridiculous selector seems reasonable. As for what the root cause of *that* would be, my random guesses are:
- Some bug in SCI Companion's compiler
- Some kind of out of memory thing because you're using so much memory with inventory items (which are loaded all the time)
- Some bug in your new inventory item (pretty easily ruled out by removing other items and keeping your new item in)

Yeah, I guess the problem has got to do with over-usage of memory.
wish there was a way to go around it, or to enlarge the possible memory usage. I guess i'll just have to figure out a way to cut on inventory items somehow and finish the game as long as i still have some memory to rely on...

unless you guys have any idea as to how to solve the issue otherwise?

[Kawa]

unless you guys have any idea as to how to solve the issue otherwise?

Memory limits because all these items are loaded at all times?

Like I said, check out Codename Iceman:

Code: [Select]

;;; tahitiInv.sc, #371
;;; --------------------

(instance tahitiInv of Code
(properties)

(method (init)
(gInv add: Black_Book Change Key Earring)
)

(method (dispose)
(gInv delete: Black_Book Change Key Earring)
(DisposeScript 371)
)
)

(instance Black_Book of InvI
(properties
said '/book[<black,address,call]'
view {tahitiInv}
loop 1
value 1
name "Black Book"
)
)

(instance Change of InvI
(properties
said '/change,coin'
view {Black Book}
loop 2
value 1
)
)

(instance Key of InvI
(properties
said '/key'
view {Black Book}
loop 1
value 1
)
)

(instance Earring of InvI
(properties
said '/earring'
view 313
value 1
)
)
That's all the items you can use in Tahiti. Then there's #372 subInv.sc that defines another 15 items that you can only use while in the submarine and related areas. #819 preloadCode.sc shows that you gotta load the new and dispose the old, lest you get all 18 items for Tahiti and the submarine loaded at the same time.

[troflip]

Find the root cause before concluding that the problem is your memory usage (speaking of... what IS your memory usage?). It actually seems really weird that you would run out of memory right at the game start if you add that one extra inventory item, but not if you play the game for a while with one less inventory item. Right?

Again,
- what's the stack trace when the crash occurs?
- have you established that it's the addition of one more inventory item that's causing the problem, instead of that *specific* inventory item?

So many easy things you can do to help root cause the problem.