1
SCI Syntax Help / Re: Importing a Character (a la Quest for Glory)
« Last post by Kawa on Today at 01:19:30 PM »True enough on being a custom format.
Recent Posts
2
SCI Syntax Help / Re: Importing a Character (a la Quest for Glory)
« Last post by MusicallyInspired on Today at 09:16:56 AM »I doubt it's a standard SCI save file. I haven't looked into it at all, but my guess is it's more likely a completely custom format in byte code that they scripted the games to understand. AGDI's QFG2VGA remake (made in AGS) will also understand these files and produce a new one for use in QFG3 onward.
3
SCI Development Tools / Re: Decompilation Archive
« Last post by EricOakford on Yesterday at 11:06:29 PM »Here is my work on QFG1VGA.
With the exceptions of a few scripts, everything seems to compile okay. I even enabled the hidden "Where to, Hero?" dialog at startup, so you can test each individual room!
I was thinking of doing a patch that would fix various script bugs in the game, and restore some unused messages and interactivity. This source could work well as the basis.
This code is best compiled without any SCR and HEP patch files in the directory, so you can be sure that the game only uses the RESOURCE files. The scripts, of course, were decompiled from the patches to ensure that all official bug fixes are present.
Here is the compile log:
With the exceptions of a few scripts, everything seems to compile okay. I even enabled the hidden "Where to, Hero?" dialog at startup, so you can test each individual room!
I was thinking of doing a patch that would fix various script bugs in the game, and restore some unused messages and interactivity. This source could work well as the basis.
This code is best compiled without any SCR and HEP patch files in the directory, so you can be sure that the game only uses the RESOURCE files. The scripts, of course, were decompiled from the patches to ensure that all official bug fixes are present.
Here is the compile log:
Code: [Select]
Error: (WizardGame.sc) Duplicate label 'code_0448' Line: 145, col: 0
Error: (WizardGame.sc) Duplicate label 'code_0453' Line: 152, col: 0
Error: (inputBox.sc) Undeclared identifier '--UNKNOWN-PROP-NAME--' . Line: 1281, col: 32
Error: (egoFight.sc) Undeclared identifier '--UNKNOWN-PROP-NAME--' . Line: 332, col: 32
252 scripts compiled.
--------------------------------
Time elapsed: 7.56 seconds.
4
SCI Syntax Help / Importing a Character (a la Quest for Glory)
« Last post by Doan Sephim on Yesterday at 09:10:10 PM »How'd they do this? I assume it saved a file that contains values for certain variables, but what how would one accomplish actually importing this into another program?
5
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by troflip on Yesterday at 05:33:29 PM »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.
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.
6
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by Kawa on Yesterday at 05:30:36 PM »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.
7
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by amirkle on Yesterday at 05:20:01 PM »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?
8
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by troflip on Yesterday at 05:09:36 PM »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)
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)
9
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by lskovlun on Yesterday at 04:28:01 PM »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.
10
SCI Community How To's & Tutorials / Re: Inventory problem
« Last post by Kawa on Yesterday at 04:01:03 PM »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 effortto 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.
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
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.
SMF 2.0.14 |
SMF © 2017, Simple Machines
Simple Audio Video Embedder
Page created in 0.37 seconds with 17 queries.