Noun dict entry

[Flimbo]

Is there any way to find out the exact dict entry (noun) used by the player for the direct object of an action?

I thought checking word[2] could do... how naive :shock:

Thanks in advance,
G

[Roody_Yogurt]

Welcome to the forum! Sorry to make you wait. There might be an easier way, but this would probably work:

Code: Select all

     local i
     for &#40;i=2; i<=words; i++&#41;
     &#123;
     if InList&#40;object, noun, word&#91;i&#93;&#41;
	     break	
     &#125;

After that, word should refer to the noun. If you did something like this:

Code: Select all

     local i,j
     for &#40;i=2; i<=words; i++&#41;
     &#123;
     j = InList&#40;object, noun, word&#91;i&#93;&#41;
     if j 
	     break	
     &#125;

Then you can refer to the word with "object.noun #j". So whichever.

Let us know if you need something more situation-specific. I didn't test these so I'm assuming it works.

[Roody_Yogurt]

You should also be able to do it with ObjWord:

Code: Select all

     local i
     for &#40;i=2; i<=words; i++&#41;
     &#123;
	  if ObjWord&#40;word&#91;i&#93;,object&#41; = noun
	     break	
     &#125;

(Again, word is now refer to the noun word the player used.)

Now, from the original question, it's hard to guess how familiar with Hugo you are so far. All of the examples listed so far will work in cases where parsing has already determined the object, like in a verb routine or an object's before.object routines.

[Flimbo]

Many thanks Roody.

At a quick glance, both your suggestions will do.
Elegant coding too. Dammit!

It all started because of this "PC" scenery object that (admittedly for the sake of detail) I described as follows:

"Your personal computer is a fairly standard piece of equipment: case, keyboard, monitor and the ubiquitous mouse."

... which quickly brought me to code a separate scenery object for each of those parts.

As my .hex file grew heavier, I wondered if I could have got to the same result implementing a single PC object.
Such thing ended up with lots of nouns and synonims attached: "pc", "computer", "system", "case", "keyboard", "mouse", "screen", "display", "monitor"... hence my need of itercepting the exact dictionary entry used by the player, in order to provide the correct response to a simple "examine" command; that happening through a before.object routine.

Later on, things heated up, since the player may reasonably "move the mouse" or "switch off the screen" while leaving the pc on, or "switch the pc off" leaving the screen in stand-by mode, or quirkly try to "press the ESCAPE key on the mouse" instead of on the keyboard, which of course demands a proper reply... Soon the PC object became cumbersome and overly elaborated, so I dropped it and returned to the separate scenery objects.
Still, I'd be curious to compare how different the size of the .hex file would be between the two implementations.

At last, I mulled over how much time I should devote to irrelevant coding.
I could have easily made that computer an anonimous, scarcely interactive entity, but how old fashioned would have it been? Those old Infocom games weren't that bad, though ;-)

I guess it's only a matter of compromise...

[Roody_Yogurt]

Glad that worked for you. Personally, I'm a fan of keeping things simple (or trying to). To me, there's nothing wrong with telling the player (or strongly hinting) how to interact with things. I think the Lurking Horror PC is a good example.

I might even go so far as to have a computer object with its usage instruction ("You could turn it on if you wanted to.") in its description, and have all of its components ("mouse","monitor","keyboard",etc.) be part of the room's extra_scenery property (getting the "You don't need to refer to that." message).

If I did want to support all of those things, I'd probably create an object class that is part_of computer and create objects for all of those things, writing specific messages where necessary, having other commands point give a "correct usage" response, and possibly have some commands redirect to the computer.

Of course, there is no correct answer, but making these design decisions is part of the fun of writing IF, I think.

[Flimbo]

Thanks for the suggestion and sorry for my late reply.

The Lurking Horror's PC is exactly what I was thinking when I wrote my previous post.

I am starting to experiment with components right now, since they may solve an issue I have with another object.
As far as I understand, components are quiet objects linked to a main object. As such, when the latter is moved, components are moved along with it, but they can be individually treated.
Is my understanding correct?

[Roody_Yogurt]

Yup, the "part_of" property is actually just an alias to "found_in", so you can refer to those objects wherever the "parent" object is (but it's not actually in the room according to the object tree).

The default >GET COMPONENT response is "You can't separate <the> from <the>.", but you could modify that if you so desired.