The project I’ve been working on involves some alteration to the way movement between rooms occurs. I’ve had no problems freeing most of the commands using “Understand … as something new”. But no matter what I do, the command “[direction]” remains in the Index, and no amount of code that I write seems to alter the behavior of those commands if rooms remain connected by the standard directions. I can prevent it by writing instructions to output text instead of moving, as the documentation suggests in certain examples, but not alter the basic action itself.
Am I missing or misunderstanding something about Inform 7?
Except that preserves the behavior I’m trying to alter: how ‘moving a direction’ works. (At least, assuming I understand what you’ve written, which isn’t certain.)
It’s the basic behavior of “moving a direction” that I am trying to alter.
The Standard Library action is “going”; I’m assuming you want to replace that with your own action instead (which here I’ve called “moving”). Is that not what you want?
If you really want to change the basic behavior of going a direction, you can override the rules defining it, from Section SR4/3 - Standard actions which move the actor in the Standard Rules.
This is the merely imagine going rule:
say "Your astral projection floats lazily to the [noun]."
The merely imagine going rule is listed instead of the move player and vehicle rule in the carry out going rulebook.
But for most cases it should be easier to replace the action with a different one, as Daniel suggested, or just add more check/carry out/report rules for the going action without replacing the standard ones.
And alter the command “[direction]”. I don’t understand why the code that affects other commands don’t override this one – it remains in the Index, and in the behavior of the test game, no matter what I do.
“[direction]” mapping to the going action is hard-coded into the parser in a way that’s difficult to change, which is why I recommend redirecting the “going” action into another action instead of trying to change the parser results.
I agree with @Draconis and @vi’s advice, as that syntax is built into the way Inform parses commands on a base level, and it is easier to just redirect attempts to use the going action, or disable the action’s functionality altogether. If you for some reason you really want to squash out that specific syntax, you can do some trickery with manual parsing of the player’s command.
Understand nothing as going.
After reading a command:
if the player's command matches "[direction]":
say "The laws of movement don't apply here.";
reject the player's command.
I would still recommend using a Before going rule or something similar, as it just seems a lot more natural, and I don’t know what kinds of problems the above solution could potentially cause.
The irony is that’s precisely what the game is about: certain approaches to design being taken for granted.
Unfortunately, I didn’t realize when beginning the project that the problem went all the way down to the structure of the parser – I’d thought that the methods given for altering commands would actually, y’know, work.
So it turns out that my point is more valid than I ever realized, and that will probably make it impossible to make the game.
As I understand your suggestion (probably poorly), that would seem to work, but I believe it would prevent me from using relative, dynamic directions as well as the static directions Inform 7 seems to take for granted.
I should probably just accept that the design isn’t feasible within Inform at my skill level.
If I knew why, I wouldn’t have started this thread!
Other alterations to different commands and verbs change both game behavior and the Index, but my attempts to free “[direction]” and alter going’s behavior just don’t work.
The last time I had problems getting Inform 7 to behave the way the documentation said it should, I brought the issue here, and it turned out Glulx was designed not to act that way. I wondered if perhaps there were similar issues again.
I’ve been deleting the code that didn’t work as I went along, so it’s hard to offer you examples. But here one: I wanted ‘left’ to be a direction people could use, as in ‘turn left’ or ‘go left’ or just ‘left’, but the abbreviation ‘l’ is used to represent ‘look’. I used Understand “l” as something new. Immediately that letter ceased triggering descriptions of the room and began being understood as another form of the word left, as I had indicated when defining the directions.
You haven’t said what you want to do. (EDIT: sorry – posted this as you were posting your most recent message!) But all the examples given so far do alter the behavior of the direction commands.
If you want more examples, you could look at the source of my Advent games (IFDB). All of them rearrange how standard Inform movement works – either changing how directions work, or how rooms are connected, or both. The source code is on my web site (https://eblong.com/zarf/if.html).
(Mostly with “Instead of going” rules, but “First setting action variables for going” was helpful for certain direction effects as well.)
I spent some time last night wrestling with Inform, and I think I can refine my question a bit.
I’ve successfully redefined the command ‘l’ so that it can stand for ‘left’ rather than ‘look’.
Examining the Index: Commands for my compiled file, I see that there are three commands that are relevant to what I’m trying to do: “[direction]”, “go”, and “go [direction]”.
I type the following lines of code:
Relativegoing is an action applying to one thing.
Understand the command “[direction]” as something new.
Understand the command “go” as something new.
Understand “go [direction]” and “[direction]” as relativegoing.
I know that this is incomplete. Rechecking the Index: Commands, there is a new entry for “go [direction]” that references relativegoing, but there are TWO entries for “[direction]”, one of which references going and one relativegoing.
I open the story page to examine the test scenario I’ve created. If I type “go north”, I receive the message “You must name something more substantial”, which indicates that the action I’ve attempted isn’t properly defined enough to execute. Fine and good, since I’ve left out the relevant code I attempted before. But, if I type “north”, I end up in the room north of the starting location.
When I attempted to write code that modified the action of going, it produced results – but not for the command of simply entering a direction. Any of the standard compass direction commands executed normally – which wasn’t supposed to happen – and the custom code didn’t execute.
I think this is related to there being two entries for “[direction]”, in violation of what the documentation and previous use of the command-altering code led me to expect. Why is that there?
The issue is that “Understand…as something new” depends on there being a verb at the beginning of the grammar line (for deep I6 reasons), and “[direction]” doesn’t have one. Which means it can’t be redefined this way.
That’s why I’d recommend redirecting the action after it’s been parsed, rather than trying to alter the parsing itself.
Before going a direction:
try relativegoing the noun instead.
This should apply to both GO NORTH and simply NORTH. The parser is very hard to alter in Inform, but redirecting actions is straightforward.
(P.S. The reason for the “You must name something more substantial” is because when an action applies to “one thing”, that actually means “one touchable thing”, and you can’t touch north. You have to specify “one visible thing” to remove the touching requirement. Yes, this is wildly unintuitive.)
I will also say—I deeply understand the frustration that comes with this sort of parser hacking. If you really want to rework the parser in ways Inform doesn’t support, your best bet is to switch to another language. Inform has some very deep-seated assumptions about what your world model should look like, and breaking those is always painful (which is why Miss Gosling moved from Inform to Dialog).
