Restoring EcoQuest 2's debug functionality

[doomlazer]

I am reminded of of how a debug build of the interpreter was added to the restoration of the KQ6 debuger. Not sure of how intact the debug functions/commands in EQ2 is or how feasible it might be to restore these. Not sure how useful just teleport is without being able to set flags or even get inventory items.

I had forgotten about the interpreter's internal debugger. I just tested Kawa's SCI.EXE that I added to the KQ6 debug restoration and it seems to work fine in EQ2. With their permission I'd be happy to buddle that into what I've been working on here.

As for the second part of your comment I might be misunderstanding, but all the normal stuff is already in 98.scr. I had to add a second page of the help for the mouse commands, which might be causing confusion. Here is the first page of the debug help:


I spot checked a few commands (yes, setting flag 1 freezes the cursor), but haven't done an exhaustive text. I did notice that the 'get inventory item' formatting leaves a bit to be desired.


The cursor should change to the arrow while selecting invItems too. Maybe I should spend some more time cleaning things up?

 

[doomlazer]

Previously, I was just setting Adam's position to the mouse x/y in Ego_988, ignoring this code already in the debugRm script:

Code: [Select]

(emALT
(event claimed: 1)
(= temp217
(if global109
global109
else
(User alterEgo:)
)
)
(gEgo setMotion: 0)
(while (!= evMOUSERELEASE ((= temp0 (Event new:)) type:))
(temp217
x: (temp0 x:)
y: (- (temp0 y:) 10)
startUpd:
)
(Animate (gCast elements:) 0)
(temp0 dispose:)
)
(temp0 dispose:)
)

But if you're going to do something you might as well go all the way, right? So now I'm reshaping the event in Ego_988 and passing it on to the debugRm:

Code: [Select]

(if (== (event modifiers?) emALT)
(event type: evMOUSEBUTTON modifiers: emALT) ;modify event type and send to debugRm
((ScriptID 98) handleEvent: event)
else

ALT-Click now makes Adam follow the mouse pointer until you release the button. This is much more 'historically' accurate.

I also fixed the "I want it ALL!" alignment and change to the pointer cursor while using the ALT-I menu.

Attached are the updated patches and source code.

ToDo:
Add Kawa's SCI.EXE interpreter if approved.
Fix an issue with ALT-O freezing on exit.
Switch to pointer cursor for ALT-G, K & L and maybe improve formatting.
LeftShift-Click and RightShift-Click should trigger ALT-E and ALT-R respectively.
ALT-J doesn't exist in debugRm script. Port it from another game?
Investigate ALT-S which seems to have no effect.
Additional testing.


 

[lwc]

Nice! I have to say though I don't notice any change in Get Inventory and I also don't see some of the items your screenshot showed.

I think the Get Inventory screen should also close once you pick something.

Here's also something interesting - in room 860 the instant movement is ignored in the lower part of the screen.

[doomlazer]

Weird, in most rooms the inventory alignment is fine and it shows the full list of items. In the jungle where I was testing it's a partial list like in my screen shot a few posts up. I'll have to look into that.

Yes, I see what you mean in rm 860. There is a script that overrides it so that Adam can hop around the small islands. It's similar to the village when Adam is in the mud - a script is overriding his walking and 'warp' doesn't work until he climbs out. Stuff like that is probably beyond the scope of what can be fixed. It's expected that debugging will cause some strangeness. I'll fix what's possible, otherwise we just have to let some things go.

Technically, the intended behavior of ALT-I is not to close when choosing individual items. This is so you can select more than one item without repeatedly pressing ALT-I. It does close if you select 'I want them all!' or 'outta here'. It's just how sierra did it in most SCI1 debuggers that I've seen.

[Kawa]

I had forgotten about the interpreter's internal debugger. I just tested Kawa's SCI.EXE that I added to the KQ6 debug restoration and it seems to work fine in EQ2. With their permission I'd be happy to buddle that into what I've been working on here.

You are already permitted.

[lwc]

Technically, the intended behavior of ALT-I is not to close when choosing individual items. This is so you can select more than one item without repeatedly pressing ALT-I. It does close if you select 'I want them all!' or 'outta here'. It's just how sierra did it in most SCI1 debuggers that I've seen.

I guess I'm used to Quest for Glory's debuggers (plural as in all games), in which it presents a box and have you type a number, then you click enter and the box disappears. But admittedly a closed list is much more comfortable, I wish teleporting just presented all rooms.

[Collector]

The help menu is not popping up for me. Is it something other than ALT-H?

[lwc]

The help menu is not popping up for me. Is it something other than ALT-H?

It's Shift+/

[Collector]

What about DBGHELP.000?

[doomlazer]

You are already permitted.

TY!

I guess I'm used to Quest for Glory's debuggers (plural as in all games), in which it presents a box and have you type a number, then you click enter and the box disappears. But admittedly a closed list is much more comfortable, I wish teleporting just presented all rooms.

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.

What about DBGHELP.000?

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

[Kawa]

Having a clickable list is one thing, but I feel like entering room numbers by hand gives a nice little feel of Danger.

After all, what if you could actually teleport and accidentally end up inside a wall, or the ground? It's a dangerous power! Entering the wrong number on startup and crashing back to DOS is actually the best possible failure scenario.

[doomlazer]

Haha, that's a great way to look at it!

[Kawa]

Another way to do it could be to, given the target in x, to use (ResCheck rsSCRIPT x) to see if the script exists, then use (ScriptID x 0) and Object::isKindOf to see if it's a Room. That way you can restrict entering non-room numbers without needing a whole list. Don't forget to (UnLoad rsSCRIPT x) if it exists but isn't a Room!

[doomlazer]

That seems to work, except for when the target script's public export 0 is a procedure (e.g. script 255) and not a resource; which gives the 'OOPS!' error 4.

Is there any way to test for that?

[Kawa]

You mean, if it's a procedure not a class instance. Any way, you want IsObject to check for that case. Not sure what to do if there's more than one non-Room thing in the export table though...