code works perfect, however it just says i cast spell. I wonder how to add an action to the spells?
Test chamber is a room. A target is in the test chamber.
A spell is a kind of thing. A spell is always proper-named
Casting it on is an action applying to two visible things.
Carry out casting it on:
say "With a fluorish, you cast [noun] on [the second noun]."
To decide what action name is the action-to-be: (- action_to_be -).
Rule for printing a parser error when the latest parser error is the noun did not make sense in that context error and the action-to-be is the casting it on action:
say "That's not a spell!"
Understand "cast [any spell] on/at [something]" as casting it on.
Understand "[any spell] [something]" as casting it on.
[SPELL BOOK]
Frotz is a spell.
Plugh is a spell.
Translucent is a spell.
A rat is in the Test chamber.
This is a somewhat confounding code excerpt, since you’re using somewhat nonstandard approaches to parser errors while asking a very straightforward question about the basic ways Inform processes actions – did you write all of it from scratch, or copy it from some other example or consult ChatGPT? I ask because the short answer is “just put the relevant code in a carry out rule” but I’m guessing that might not be super helpful and it might be more useful to take a step back and point you to the relevant docs for action processing, walk through what this excerpt does, and so on.
Cool, no worries! So to just start with the specific question you’ve asked, the easiest way to make your spells do something is to write a carry out rule that takes effect when the player casts the appropriate spell. So something like (this is not real code since I don’t know how you’ve got your game set up):
Last carry out casting translucent on:
Say "Now you can see into the guts of [the second noun].";
Now the second noun is see-through.
The “last” is there to make sure the rule is evaluated after the default carry out rule you’ve already written that tells the player they’ve cast the spell, since it wouldn’t make sense to have the spell take effect before the player sees that they’ve cast it. And then “casting translucent on” in the header means the rule only applies when the player casts translucent, rather than frotz or plugh or whatever else. “Now the second noun is see-through” is just something I made up, but I assume you’d want an object property somewhere allowing you to mark whether or not it’s translucent, which you then might use as part of an if…else tree as part of the object’s description – so this line would flip it from opaque to see-through.
Now, if you’re nodding along to all of the above, great! But if any of it seemed a little confusing, or you didn’t know exactly what all the terms meant, I’d definitely recommend doing some background reading first. If it’s just the details of how different rules apply to action evaluation that are confusing, there’s a helpful chart in the docs that can clear that up. But if you’ve got more questions than that, it’s probably worth working through at least the first couple of chapters of Writing With Inform – working through all of the docs isn’t that rewarding (I’ve never done it, at least), but reading chapters 1-7 and checking out some of the related examples can give you a really solid grounding for starting to mess around with Inform, and then it’s easy enough to dig back into the docs as you run across issues.
If the docs aren’t a good fit for your learning style, there are also lots of other resources to help learning Inform, too – some that are more focused on building out a game bit by bit, others that are aimed at experienced programmers who might be wrong-footed by some of Inform’s idiosyncracies, and so on. So I guess my next question is just whether you’ve tried reading Writing With Inform, and if so, has that been helpful or do you feel like a different approach might make life easier?
Greetings! I hope you enjoy learning about Inform 7 as much as I do. The code is odd, and while some of it works you probably won’t be happy with it in the long run. I think Mike is probably looking at that (he is!).
I recently rebooted my blog about learning Inform. Here are the post-reboot articles. The oldest post is at the bottom, so scroll down if you want to start at the beginning. I cover introductory stuff like making rooms, substituting text, and basic action processing.
Just as an additional note, I’d make spells be a kind of value rather than a kind of thing, since they don’t meaningfully have a “location” or anything.
No, my default is to use a kind of value if there’s a small, enumerated list of options defined all at once and a kind of concept if I’ll be making them all across the source, so I’d do values for spells. Would the parsing be significantly better with concepts?
I don’t know if it’s significantly better, but I find that the synonym handling for objects is easier to deal with. Also if there’s any risk of disambiguation questions, you need objects.
Thank you, Mike, for your explanations regarding the use of a ‘last carry out’ rule within the action processing rules; as always, I learn something from you.
Tell me, in the case mentioned by the thread’s author, does this rule indeed belong to the same action processing workflow as the ‘Carry out casting it on’ rule, which would then be executed before multiple more specific ‘last carry out’ rules? Is that the intent of what you’re suggesting? If so, I find it very useful. Magic is marginal in the universe of my WIP, and sane people dread it, but the use cases for this coding technique are countless.
Another question: don’t you think it would be better to isolate the display of the actual spell result in a ‘report’ rule, by declaring an action variable of the ‘text’ type, fed by the ‘Last carry out’ rule? I try to do this as much as possible. In this particular case, it would, for example, allow for constructing a text with a common base for all spells, to which only the specific details are added. This way, text substitutions could be concentrated at the level of the common base to work on diversity and variety of text in just one place in the program.
(Sorry for the delayed reply, keeping up with the forum during Comp time is tough!)
For the first part, yeah, my understanding is that all the carry out rules run as a block, with the most-specific one or ones (determined by number of conditions) running first by default. You can manually shift rules around (“rule X is listed before rule Y in rulebook Z”), but I at least find that a little unwieldy, so first/last to just jam things to the beginning or the end often winds up being easier where you don’t need to do anything too complex.
And for the second part, yes, I personally wouldn’t put a simple “say” statement in a carry out rule that would apply to multiple actions; if I were starting from scratch I’d probably define casting a spell as a kind of action, since that’ll make it much easier to wrangle things in the probable situation where some spells apply to no objects, some to one, and some to two, and then write a generic “report casting a spell” rule that would fire at the end.
(In practice, though, I’d probably just cram the say statements telling the player what they just did into the spells’ respective carry out rules, rather than doing a generic case and writing a separate rule, since that’s both a little less work and affords more control over the specifics of how the player experiences each spell).
Understood. Don’t worry about the response time—I’m not expecting you to be at my beck and call . Thanks for the explanations; indeed, in a game where the spellbook contains a significant library of magical actions, I would also go for creating a set of action processing rules for each spell to manage the wide variety of effects.
. Thanks for the explanations; indeed, in a game where the spellbook contains a significant library of magical actions, I would also go for creating a set of action processing rules for each spell to manage the wide variety of effects.