Dealing with implicit action reporting

As I’ve said in other threads, this sort of thing bothers me because it doesn’t make sense, and I’d like to fix it, or at least make the reporting a little more sensible:

[code]>wear hat
(first taking Granny’s hat)
That seems to belong to Granny.

inventory
You are carrying nothing.[/code]

Could one just write a series of commands like:

[code]Instead of eating something (called the food) when the player isn’t carrying the food:
say “You aren’t carrying it”.

Instead of wearing something (called the clothes) when the player isn’t carrying the clothes:
say “You aren’t carrying it”. [/code]

And if so, how many such commands are there to write?

Alternatively, should I take David Fisher’s custom messages and just change “first taking the object” to “first trying to take the object”?

Will either of these ideas have unintended consequences?

Thanks!

I found something that may be pertinent to the question: the text capture extension by Eric Eve. His usage instructions may shed light on the matter (the relevant line emphasised by my bolding it):

Basically, I suspect you may be content with the solution you mentioned. You problem might largely be worked around by restricting what can be implicitly taken to such items that are “public” or at the very least not enclosed, worn or possessed by another person. If you think the limitation that Eric addresses may crop up later on, the extension may be a better choice and/or complement.

Hope this is helpful.

Absolutely. Another way is just to rewrite the “implicit taking” function so it only adds the “(first taking whatever)” after the player has actually taken whatever. For example if you add the following:

Rule for implicitly taking anything: try silently taking the noun; if the player carries the noun: say "(first taking [the noun])[command clarification break]"; otherwise: do nothing.
You’ll now see this when trying to wear the hat:

>wear hat That seems to belong to Granny.
with no other changes to the functionality of implicit taking.

WOW! Only a One Year turnaround time for a response!

:laughing:

I think I “solved” the problem by changing the reporting to “first trying to take”.

However, the other two suggestions are very helpful. I’ll look into them, as I was never very happy with just adding “trying”.

I just looked through “unanswered posts” and figured what the hell, can’t be more than a week or so old. :smiley:

I’ve got to ask the both of you as more experienced I7 developers, what are the most salient things to watch out for when dealing with post-processing of text? I mean, if we assume you’re not bottlenecked by an extremely slow system in other ways, are there any other common limits to the method of trapping and refining commands that didn’t go through in the first place?

@ShaeSays

[size=50]Oops, since the post was at the top of the subforum I just glanced at the “Dec” part without noticing the “8/9” part.[/size]

I’m just going to blame Eleas and say the whole thing was his fault. :laughing:

[size=50]Does anyone else besides me think the forum experience here could be made better with a larger selection of smilies to choose from?[/size]

In any case, since implicit actions are the normal behavior of Inform and getting rid of them (if one wants to) is relegated to a stray line here or there in the documentation, this info was worth a fresh look anyway.

@Eleas

I’m not sure what you mean; could you provide a general example of something you’re trying to do? I work on an ancient computer, so if anyone is likely to know about what makes Inform go ssllooww it’s me, and the only things I’ve ever noticed that cause a big performance hit are every turn rules with lots of repeating through things. I’ve never noticed any slowdowns while text was being processed, but on the other hand I don’t normally do things that run through large sections of indexed text either.