Ok, working on a game that I started maybe 2 years ago, abandoned and now hoping to finish. I’m adding a new feature where the player has to look for a charm in an area (preferably with SEARCH FOR). I want the player to have specify which charm they’re looking for in an area, but not allow general searching. SEARCH and SEARCH FOR CHARM will not work, probably display a message to be specific, but SEARCH FOR MERMAID CHARM would work if they’re in the right location. Is rewriting the name of the charm the best way to do this (starts off with name ‘mermaid’ ‘chxrm’, and when they pick it up it changes the second name to ‘charm’), or is there a better way to do this? Thanks!
Changing the name property will work. But you should define the extra word with a comma in it (",charm") – that will make the word genuinely untypable.
For more flexible ways of conditionally parsing object names, see my page eblong.com/zarf/inftricks/tip_parsename.html
You could also define a “search for” command that uses a scope token. The charm objects would be off-stage, and would be accessible only to that one command. Then you wouldn’t have to change the names at all; the charms would be out-of-scope for any normal command.
Well, that’s almost the idea. I actually plan on giving the bronze charms the conceal attribute and then rewrite the before-take to basically check for concealment and if found print the standard “Item not found” message (so the player is led to believe the charm is not there). Only by using a new verb (SEARCH FOR) would they be able to find and acquire them (SEARCH FOR will first find the specific charm refered to, remove concealment and then attemp to take it since there’s a carrying capacity limit in place).
I’ll try that comma trick and see if I can get that to work. Would I also need to add a name that includes charm as well, like name ‘bronze’ ‘,charm’ ‘bronze charm’, or would it just read the bronze and be happy to work (and I’ll probably comma out the bronze too, so they don’t get hints about multiple charms in the same location)?
Actually, just looked at the link you sent, think that will work perfectly. Check for concealment, if there then ignore charm and bronze. If no concealment than parse normally. Thanks.
Thought I’d post my eventual solution for anyone who wants to know. Took three tries to get it right though, I’ll post all three and why the first two don’t work (so people don’t make the same mistakes as me).
Method 1: Ignore the words I don’t watch matched. FAIL
I took one look at the parse name function and thought this was in the bag. Just ignore the words I don’t want matched in the item and all would be well. Here’s the code for that:
parse_name[ wd num;
wd = NextWord();
while (WordInProperty(wd, self, name))
{ if (self has concealed)
{ if (wd == 'charm' || wd == 'bronze')
{ continue; }
}
num++;
wd = NextWord();
}
return num;
],
I actually don’t remember if this worked with TAKE TANGLE or not, but it didn’t matter to me as TAKE BRONZE or TAKE CHARM would ultimately cause an infinite loop. Apparently if it didn’t find a word it would keep looping until it found one, and since the only word it could find was to be ignored… Scrapped that idea and tried a second idea.
Method 2: Track two separate counts and return the relevant one. FAIL
This idea was based on the idea that I could return one count for normal parsing and one for when the item is concealed and that would work. Here’s the code:
parse_name[ wd nc cc;
nc=0; ! Normal Parsing
cc=0; ! Concealed Parsing
wd = NextWord();
while (WordInProperty(wd, self, name))
{ if (wd ~= 'charm' || wd ~= 'bronze') { cc++; }
nc++;
wd = NextWord();
}
if (self has concealed) { return cc; } else { return nc; }
],
Now this method seems to work better. TAKE BRONZE and TAKE CHARM are blocked, but TAKE TANGLE is allowed. In fact if I hadn’t tried TAKE TANGLE CHARM I would have said it was good. But combining TANGLE with either BRONZE or CHARM results in it being blocked. Apparently unless the number of words being returned is the same as the number of words inputted it’s not a match. At least that’s what I figure because in the end I finally had an aha moment and tried this.
Method 3: Track two separate counts and return based on concealed count. SUCCESS
The code starts the same as in Method #2, but replace the final if statment with this:
if (self has concealed)
{ if (cc > 0)
{ return nc; }
else
{ return cc; }
} else {
return nc;
}
Basically the idea is that if the object is concealed and the concealed count found anything, then return the normal count (as if it wasn’t concealed), otherwise return the concealed count which since it’s less than the input (possibly) will fail. And of course, if not concealed than return normal count. This worked, even with TAKE BRONZE TANGLE CHARM.
Hopefully this can help other people out. Thanks for putting me on the right path with parse_name.