# Going at speed

I am trying to set up a distance system to better use the Variable Time Control extension, and believe I have something that should work (three-column lookup table: room, room, distance) and that allows me to be modular with regards to speed (multiplier on vehicles and people). It currently works with going, but, since the system should let me, I would like to add verbs for different movement speeds; most basically running. I have added “the speed gone at (matched as ‘at’)” as an action variable to the going action, and it seems like the easiest way to implement running would be simply “try going at 10 instead.” Unfortunately, if I read the docs correctly, I can’t set action variables like this. The simplest method I can think of would be to create a new “going at” action that the current “going” would redirect to, but I don’t want to recreate the original. Is there anything easier?

You could set the action variable via a global variable. A short I6 inclusion lets you do this with the syntax you want:[code]There is a room.

Speed given is a truth state that varies.
The speed to try is a number that varies.

The going action has a number called the speed gone at (matched as “at”).

Setting action variables for going (this is the set speed gone at rule):
if speed given is true:
now the speed gone at is the speed to try;
now speed given is false;
otherwise:
now the speed gone at is one [default value].

To try (doing something - an action) at (speed - a number): (-
(+ the speed to try +) = {speed};
(+ speed given +) = true;
{doing something};
-).[/code]
There might be a cleaner way I’m not thinking of.

I’m not sure if it’s possible or not, but I put the time advance (only thing I need speed for) in a “Carry out” rule. Is there any way to test if the “going” was triggered directly or through some other action? I know I could use a truth state (Running→now redirect is true; try going), but is there anything cleaner?

Not really.* The solution you propose is more or less how the Standard Rules solve the problem: the looking action has an action variable called `the room-describing action'' which is set the same way as`the speed gone at’’ in the code above.

*Well, technically, yes. You can plumb Inform’s internal data structures to find out how many actions are currently active:```Include (- [ CountActiveActions i extent result; result=0; for(i=MStack_Top:(i>0)&&(extent=MStack-->i):){ i=i+extent; if(MStack-->(i+1)==(+ the action-processing rulebook +)) ++result; } return result; ]; -). To decide what number is the number of actions going on: (- CountActiveActions() -).``` For a directly triggered action, that count will be one. But indirect triggering can happen other ways, persuasion for instance, and it’s maybe a bad idea to depend on undocumented internals.

All right, so I think I’ve gotten something that should work:```Running is an action applying to one visible thing with past participle "ran". Understand "run" and "run [direction]" as running. Carry out an actor running (this is the redirect running to going rule): unless the actor is in an enterable vehicle: now the going-redirect is true; now the redirect-speed is 45; [[ Not the only method; can't just check for 0 ]] try the actor going.```
Unfortunately, Inform seems to have found that running will always redirect to going, and has simplified that by automatically understanding the former as the latter. This has the slight problem of not running the rest of the code; even if I put in a “say ‘Running’;” at the beginning of the rule, nothing happens. Is there any way to postpone the shift so I can set the variables before the going action is triggered?

Also, while I was testing my time advancement rules, I found that failed actions take the normal seconds_per_turn. Is there any way to check if an action was stopped (e.g. “>take east”) to set a “take no time;”?

It’s not that Inform has discovered that running redirects to going, it’s that “run” is already built into the standard rules as a synonym for “go,” so your understand line doesn’t succeed in doing anything. (I think.) Try inserting this before your code for running:

``Understand the command "run" as something new.``

Yeah, that fixed it. Now I just seem to have a problem with the noun not carrying over to going for evaluation—I get the “specify a compass direction” error even if I say to “>run west”. I’ve looked and from the documentation it doesn’t seem like I’d need to say anything like “try going X;”, but the results make me think that I might be missing something.

And with that other question, Inform seems to have some interesting behaviour. “>take ground” (ground object not implemented) works as expected, neither using a turn nor advancing the time. “>take east” (even without an exit to that direction) says that I “must name something more substantial” but still increments both the turn count and the time. Is there any easy way (easier than editing the rules) to get both—and any other actions with this problem—to do the former?

Oops, I missed this first time: at the end of your carry out running rule, instead of “try the actor going” you should have “try the actor going the noun.” “The noun” is the thing that your action applies to (as in “one visible thing”), which in this case is the specified direction. As it is, you’re redirecting running in any direction to going with no direction specified.

Well that’s simple enough. Just not exactly English syntax—the hardest parts when coding using a system mirroring language are when it doesn’t. Anyway, that solves the walking-running dichotomy, which just leaves the inconsistent turn advancement. And then I just have to actually create a game to use all this stuff. (I do have an idea, but need to get a map first. Which involves watching fifty episodes, and taking screenshots to piece together the world. After the animators decided that they didn’t overly care about keeping the world particularly consistent. Fun!)

Yeah, the tricky thing is that directions aren’t really nouns as we understand them, but if we tried them to implement them as something different it would be a huge mess (I assume).

If you want your code to read a little more idiomatically I guess you could do something like this:

```Carry out running a direction (called that way): [put your code for running here]; try going that way.```