I’m having a bit of trouble with dobjFor() macros on an Openable Booth. I have a basic idea of check and verify from reading. I’m trying to do a failCheck to report and skip action, but the action seems to be running any way. When I type open pen I get “seems like a waste of time.”
sheepPen: Openable, Booth 'sheep pen*pens' 'sheep pen' @adamEveBarn
isLocked = true
isOpen = nil
dobjFor(Enter)
{
check(){
if(!isOpen)
{
failCheck('The pen is closed!');
}
}
action(){"Seems like a waste of time";}
}
dobjFor(Open)
{
check(){
if(!isLocked)
{
failCheck('The pen is locked!');
}
if(isOpen)
{
failCheck('The pen is open!');
}
}
action(){"Seems like a waste of time";}
}
;
A simple debug trick: when there’s a large set of if’s nested or otherwise, is useful keeping different the responses, even when the same response makes sense; in the snippet above, there’s two “seems like a waste of time”, and changing one will point to the branching path followed.
Piergiorgio, you just inspired me. If I added a little logic to the other couldn’t I cut back on code by calling one action as another? Is that what you mean?
sheepPen: Openable, Booth 'sheep pen*pens' 'sheep pen' @adamEveBarn
isLocked = true
isOpen = nil
dobjFor(Enter)
{
check(){
if(!isOpen || isLocked)
{
failCheck('The pen is closed!');
}
}
action(){"Seems like a waste of time";}
}
Call Open -> Run Enter
well, what I mean is that differentiating response gives an immediate check on actual branching path; for example, in your initial code, having, for example, "[open] seems like… and "[enter] seems like… will have shown immediately what path was followed, a substantial help in debugging logic operations.
OTOH, compacting the code reusing the same routines for different action is often the “right thing to do”, albeit with large maximum story files available, tend to be a “lost art” (I’m rather slow in coding IF, and I have a “no vaporware” policy, but suffice to say that some WIP code here is still Inform 5/z3)