Restoring EcoQuest 2's debug functionality

[lskovlun]

Don't forget to (UnLoad rsSCRIPT x) if it exists but isn't a Room!

Better yet, use DisposeScript. That way, you don't leave little turds in the class table, for example.

[lwc]

You're right, there is a lot of inconsistency in how things are done. If I had a list of all possible TP room numbers I could probably create a clickable list, but I'm torn between leaving what's already in the debugRm code and adding QoL improvements.

Here you go, please everyone help fill it up!
But this raises another bug, as the teleport menu doesn't allow more than 3 digits, while according to this there are many 4 digit rooms (at least all of them aren't standard anyway).

Attached below is a version bundled with Kawa's SCI.EXE that includes DBGHELP.000-DBGHELP.002 and SCI.EXE_Interpeter_README.txt

Note the readme there keeps referring to KQ6's folder.

[doomlazer]

Ok, This seems to work pretty well:

Code: [Select]

(KEY_ALT_t
(if gModelessDialog
(gModelessDialog dispose:)
)
(if (> (= temp207 (GetNumber {Which room number?})) 0)
(if
(and
(ResCheck rsSCRIPT temp207)
(IsObject (ScriptID temp207 0))
((ScriptID temp207 0) isKindOf: Rm)
)
(global2 newRoom: temp207)
else
(Print addTextF: {%d is not a valid Room.} temp207 init:)
;(DisposeScript rsSCRIPT temp207)
(DisposeScript temp207) ;thx lskovlun for catching this bug
)
)
)

For the 'Where to?' script I default to the INTRO if the room is invalid. That change requires adding 1.scr and 1.hep as patch files of course.

Maybe ALT-T should fail silently instead of printing an error message?

lwc, I've removed the KQ6 references and added the room list to the readme. I believe the reason 'Where to?' only accepts 3 digits is because there are no real rooms above 999. 1000+ is mostly talker scripts and other stuff.

Updated version attached.

Edit: removed outdated attachement.

[lwc]

I don't like skipping to the intro since it disables the mouse for a bit. Can alt+t be allowed during it?

As for alt+t I agree it should fail silently, as right now it crashes the game for wrong room numbers.

I think the readme shouldn't try to list rooms as it's a work in progress. A link should suffice for now.

BTW, how come you include 1.hep and 98.hep but not 0.hep and 988.hep?

[doomlazer]

Whoops, The debug room patch files were out of date. Try the version below.

When it goes to the intro I'm able to ALT-T within 3 seconds. Is that too long?

I've removed the room list and left the TCRF link in the readme.

Edit: removed bad attachment.

[lskovlun]

Code: [Select]

(DisposeScript rsSCRIPT temp207)
should have been

Code: [Select]

(DisposeScript temp207)
otherwise it won't dispose the right script, and may even crash if you happen to be in room 130 (= rsSCRIPT).

[doomlazer]

...otherwise it won't dispose the right script, and may even crash if you happen to be in room 130 (= rsSCRIPT).

Thank you for catching that!

BTW, how come you include 1.hep and 98.hep but not 0.hep and 988.hep?

1.hep isn't required. I've removed it.

I'm a bad person to explain this, but SCI1 .hep patches store the string literals (e.g. {Where to, Mac?}) and other stuff. The actual scripts in .scr point to the string location in the .hep.

If you export a .scr patch file with new or modified string literals you must export the .hep or the strings won't work correctly in-game because it's referencing the out of date heap contained in the games resource.xxx files. Adding new local vars, class instances, and procedures are other changes that require updating the heap.

ALT-T should fail silently now.

[lskovlun]

Come to think of it, there's another conceptual problem here. Loading a script to check whether it's a room is quite a strain on heap memory, since you're essentially loading a second room while the first is still there (and before making the decision to change rooms or not). ScummVM will live with it, but SSCI might run out of memory.

[Collector]

Looks like there are only 33 rooms.That is discount the rooms that don't have a hep associated with them and crashes on load. Those room numbers are 40, 100, 160, 200, 220, 240, 260, 280, 290, 300, 330, 360, 380, 390, 400, 420, 440, 500, 530, 560, 580, 600, 630, 680, 700, 730, 800, 820, 840, 860, 870, 880, and 890.

I would also note that upon teleportation to the new room it starts as if the room was normally entered the first time. Some rooms will crash the game if invoked from another room as opposed to TPing from the start, I assume before certain flags are set.

[doomlazer]

Looks like there are only 33 rooms.That is discount the rooms that don't have a hep associated with them and crashes on load. Those room numbers are 40, 100, 160, 200, 220, 240, 260, 280, 290, 300, 330, 360, 380, 390, 400, 420, 440, 500, 530, 560, 580, 600, 630, 680, 700, 730, 800, 820, 840, 860, 870, 880, and 890.

I would also note that upon teleportation to the new room it starts as if the room was normally entered the first time. Some rooms will crash the game if invoked from another room as opposed to TPing from the start, I assume before certain flags are set.

There is at least one additional room not in your list. Pic 500 is reused for room 501, which is directly south of rm500. EcoQuest 1 did the same thing with fish apartments, redecorating with 'addToPic' props.

There are also what appear to be rooms that are actually 'insets'. The safe script (503) is still room 500, but uses DrawPic to load a black background and views 503 & 504 - giving the appearance of a separate room. PQ2 did something similar for desk drawers and lockers which surprised me.

Come to think of it, there's another conceptual problem here. Loading a script to check whether it's a room is quite a strain on heap memory, since you're essentially loading a second room while the first is still there (and before making the decision to change rooms or not). ScummVM will live with it, but SSCI might run out of memory.

Ugh, good point. I did a quick test by disabling the 'newRoom:' code in ALT-T so I don't actually teleport, then checking heap with ALT-M before and after.

From the jungle to rm501:
free heap before: 19032
free heap after: 16512
exported 501.scr size: 9.05KB

From the jungle to rm530:
free heap before: 19032
free heap after: 13492
exported 530.scr size: 11.32KB

This indicates to me that the scripts aren't loading the entire target room, but without knowing how much free heap is available in every situation it still could crash when it previously wouldn't without the new checks. Should this change be reverted or do the benefits outweigh the risks? 

[doomlazer]

After some more testing I believe the new TP code to be unstable. It consistently crashes when doing the following:

Where to? -> Chibola -> ALT-T -> 220

Reverted patch attached below.

[Collector]

Yeah, I had noticed that 500 was reused, but forgot to count it. I think there may be at least one more, but can't recall off hand.

[Collector]

You cannot display the interpreter debug commends as it is called by the same as the script debugger '?'.

[doomlazer]

You cannot display the interpreter debug commends as it is called by the same as the script debugger '?'.

Nice catch. Should I switch the debugRm help to ALT-H?

[doomlazer]

Wait a sec, I think the interpreter debug help works even with ? for the debugRm. You just need to LShift-RShift-'-' first, then the internal debugger takes precedence for the help command.