When the player moves north, the game dialogue appears as so:
n
North Room
This is the north room.
But if I move them to the North Room using “move the player” in code after, say, they climb a slope and the game checks they haven’t broken a leg, it appears thus:
climb slope
North Room
This is the north room.
How can I make Inform display the blank line above the room description, as if they had typed “n”?
Thanks for reading!
Interesting question. Arguably this is a bug.
The cheap way is to add a “say” statement to the action:
Instead of climbing the slope:
say "You drag yourself up the slope.";
move the player to North-Room.The sideways way is to use a normal movement, and put the broken-leg check in a check rule instead:
Check going east from the Valley:
instead say "Ow."
Instead of climbing the slope:
try going east.The hacky way is to set a library flag directly. I don’t know how this call interacts with other line-break situations, but it works for this one:
To say going look break -- running on: (- GoingLookBreak(); -).
Instead of climbing the slope:
say going look break;
move the player to North-Room.The best solution in any case is not to use “move the player” if it can be avoided.
Reading between the lines, you probably have something like this:
Instead of climbing the slope when the location is downhill:
if the player has a broken leg:
say "You can't climb with a broken leg.";
otherwise:
move the player to the hilltop.
You should just connect the rooms normally and redirect the climbing the slope action to going north (or up or wherever) action and let the action succeed in the right circumstances:
[code]Instead of climbing the slope:
try going north.
Check going north from downhill when the player has a broken leg:
say “You can’t climb with a broken leg.” instead.[/code]
This is (arguably) cleaner and avoids the description formatting issue.
(edit: I only now realized that zarf already suggested this.)
Perfect, thanks very much for the help. Out of interest, is there any advantage to using:
Check going north from downhill when the player has a broken leg:
say "You can't climb with a broken leg." instead.
rather than:
Instead of going north from downhill when the player has a broken leg:
say "You can't climb with a broken leg."
Many thanks again!
The effect should be similar either way for a relatively simple rule like that. No matter which you use, everything from “carry out” and later in the process will be overridden.
I think it’s considered more “common” to use Instead of for the situation, but it’s ultimately your choice.
The documentation recommends using instead/before/after for one-off exception handling like this, and check/carry out/report for big systematic changes with a lot of moving parts.
Following these guidelines can help to keep your code neater and to avoid subtle malbehavior. But as aa points out, in a small project, the difference is usually academic.
It should be a good idea to be consistent, however. Either consistently use check rules with when/while clauses (Check doing this while these special circumstances hold: do that instead) to handle exceptions to standard behaviour or consistently use instead rules (Instead of doing this: do that).
Inform runs more specific rules before more general ones; so «Check going up in purgatory while carrying the very heavy burden of sin: instead say “No way!”» will be considered (and possibly stop the action) before «Check going up: if the player is not on the top, continue the action; otherwise instead say “You’ve already achieved the summit of existence.”» can do anything. But that only holds for rules that belong to the same rulebook: so an instead rule such as «Instead of going up in purgatory: say “Saved!”; move the player to paradise.» will be considered and work whatever magic it works before any check rule gets a chance to intervene, even if there are check rules as specific as «Check going up in purgatory while carrying the very heavy burden of sin: …».