T3: getExtraScopeItems

Edit: Never mind. I was running afoul of an objVisible preCond on the dig action. Got it working now. [end edit]

I’m setting up a situation where the PC needs to dig a hole. I’ve got the dirt floor (an instanceObject of a MultiInstance, since it can be in several locations) working. The thing is, the player may use the command ‘dig hole’. The hole is not in scope until after the action takes place, so I’m trying to use getExtraScopeItems(actor) in the instanceObject so that the player can use the command.

The hole is now in scope, but this is the result:

This is not the default response for objects that are not in scope (“You see no hole here.”), so I’m pretty sure getExtraScopeItems is doing its job. So why is the hole not visible?

I skimmed the “Redefining Scope” article in the Technical Manual, and it seems not to address this type of situation at all. It occurred to me that the hole might be in the dark, because it’s in nil, so I gave it a brightness of 3. That didn’t help. So I’m stuck. How do I make the hole available to that command?

Needless to say, the hole has dobjFor(Dig) defined, and also dobjFor(Default) to handle commands that would make no sense.

It looks like you’ve found a solution to the problem, but another approach which might be easier to implement than fiddling with scope is to use a dummy hole object that’s in the appropriate location to represent the hole before it’s dug and then make the dig command swap it out for the real hole:

+ dummyHole: Thing 'hole' 'hole'
    dobjFor(Dig)
    {
        verify {}
        action 
        { 
            "You dig a hole. "; 
            hole.moveInto(location);
            moveInto(nil);
        }
    
        
    }
    
    dobjFor(Default)
    {
        verify() { illogical ('You can\'t see any such thing. '); }
    }
    
;

hole: Container 'hole' 'hole'
  dobjFor(Dig) 
   {
        verify() { illogicalAlready ('You\'ve already dug it. '); }
    }

;

– Eric

Good suggestion, Eric. I love the fact that TADS gives us several ways to solve a design issue. Figuring out the optimal method is not always easy, however. I’ll test further to see if my method has undesired side effects.

Interesting. While doing my TADS translation, I was thinking about this for some time, because in Czech language we never “dig ground”, but always “dig hole in ground”. In the end I’ve solved this problem simply by making “hole” part of the verb itself - I’ve modified grammar rules and verb phrase of dig. The word “díru” means “hole” in accusative case:

VerbRule(Dig) ('vyhrabej' | 'vyhrab' | 'vyhrabat' | 'hrabej' | 'hrabat' | 'vyhlub' | 'vyhloubit') 'díru' ( | 'v' | 'do') singleDobj : DigAction verbPhrase = 'vyhloubit/hloub{íš}/vyhloubil{a} díru (v čem)' askDobjResponseProd = inSingleNoun ;But I’m not sure my approach is transferable into English language mainly because my format of vebPhrase is little different.

“Dig the ground” isn’t really idiomatic English either; I’d be much more likely to say “dig a hole in the ground” or even more so “dig in the ground.” But in IF I’d be pretty likely to try “dig ground,” because I don’t necessarily expect the parser to understand “dig in ground” and I definitely wouldn’t expect it to understand referring to an object that isn’t there like the “hole.” Extra prepositions like that can lead to guess-the-syntax problems.

Probably the best idea in English is to have the game understand both “dig the ground” and “dig in the ground.”

…and also because the ground might have synonyms “dirt”, “earth”, “soil” – “dig dirt” is a thing players might reasonably try.