[adv3Lite] "debug doers" can't handle "|" separated command?

Authoring TADS
1

Hi Eric and other adv3Lite users,

I’m trying to learn how the DEBUG command in adv3Lite works, and found a glitch in the way DEBUG DOERS display the command if it’s defined as one of the options using “|” separator in the Doer definition.

Example:

[code]#charset “us-ascii”

#include <tads.h>
#include “advlite.h”

versionInfo: GameID
name = ‘Bug Report Sample’
byline = ‘by Ming Hua’
desc = ‘Sample code for bug report about the DEBUG DOERS command of
adv3Lite.’
;
gameMain: GameMainDef
initialPlayerChar = me
;

startRoom: Room ‘Start Room’
"This is where the game starts. The only thing noticable here is a big
black lever. "
;

  • lever: Lever ‘lever; big black’
    "A black stick in a slot. It can be pushed forward or pulled back. "

    isFixed = true
    ;

  • me: Thing ‘you’
    isFixed = true
    proper = true
    person = 2
    contType = Carrier
    ownsContents = true
    ;

Doer ‘push lever north|south|west|east’
execAction( cmd ) {
"You can only push the lever forward, not other directions. ";
abort;
}
;

Doer ‘push lever up’
execAction( cmd ) {
"The lever is horizontal. ";
abort;
}
;

leverTest: Test ‘lever’
[
‘x lever’,
‘pull lever’,
‘push lever’,
‘debug doers’,
‘push lever north’,
‘push lever up’
]
;[/code]

Output:

[code]>test lever
Testing sequence: “lever”.

x lever
A black stick in a slot. It can be pushed forward or pulled back.

pull lever
Done.

push lever
Done.

debug doers
Debugging options:
actions = off
doers = on
messages = off
spelling = off

push lever north
[Executing Doer; cmd = ‘south|west|east’]
You can only push the lever forward, not other directions.

push lever up
[Executing Doer; cmd = ‘push lever up’]
The lever is horizontal.[/code]
As you can see, the debug output for PUSH LEVER NORTH gives the command as “south|west|east” instead of “push lever north”.

I tried to figure this out by myself, but the actionTab code in debug.t is too advanced for me.

BTW, speaking of levers, does anyone know why the Lever class is not a subclass of Fixture?

2

I’m away from home on holiday at the the moment, so I can’t really deal with this right now. Well, I can’t correct my master copy, but I can tell you what’s causing the problem and how to fix it.

The standard output filter treats the | separator as alternating between present and past tense options, with the results you see, so the output from debugging a Doer needs to bypass this filter.

The fix is to change the definition of Command.execDoer(lst) in command.t so that it reads:

    execDoer(lst)
    {
        /* find the list of matching Doers */
        local dlst = DoerCmd.findDoers(lst);
      
        IfDebug(doers, oSay('''[Executing Doer; cmd = '<<dlst[1].cmd>>']\n''') );    // CHANGE THIS STATEMENT
        dlst[1].exec(self);
        
    }

By the way, it’s not a good idea to use cmd as the name of the parameter/argument in methods on Doer as here:

Doer 'push lever north|south|west|east'
    execAction( cmd ) {
        "You can only push the lever forward, not other directions. ";
        abort;
    }
;

Since cmd is the name of a property of Doer (the property you define via the template), and having a property and a local variable with the same name is like to cause problems.

By ‘anyone’ I suppose you mean me, since no one else would have had any hand in the decision! The answer is that I don’t immediately recall why I did it that way. Would it upset anyone if Lever was changed to inherit from Fixture in the next release?

3

Hi Eric!

I know you are on vacation which is the reason I posted here instead of emailing you, hoping someone else may give an answer before you are back from vacation. But obviously you still help people on your holiday! Thanks so much.

This works as you said.

Noted. Such is the side effect of relying on templates. After reading more about Doers, it turns out if I don’t like “c”, “curCmd” is the proper parameter name for Doers’ execAction().

If you are going to do that, please also have a look at the Button class in the same gadget.t, they both have isFixed = true, but neither inherits from Fixture.

4

That reminds me why I may not have done this. The Fixture class is defined in the optional extras.t module. If Lever and Button were subclassed from Fixture, you’d have to have extras.t present if you wanted to use gadget.t. I suppose in practice most people would have it, but my intention was to make adv3Lite as modular as possible and keep this kind of dependency to a minimum.

5

Aha, so there indeed is a reason. In that case though, you may want to reconsider the Settable class in gadget.t, since it inherits from Fixture, and therefore currently gadget.t depends on extras.t anyway.