I7: Try Silently Generating Line Break

So I’ve got a sequence of events running during a scene, and during a “to say” phrase, I’m trying to seat the player. Unfortunately it seems to be gaining an extra line break from somewhere and I can’t seem to track down where. My expectation was that “try silently…” wouldn’t print anything so I’m assuming the line-break is getting inserted before the call to Begin-sitting but the generated I6 is being less than edifying!

Simplified example:

[code]“Test” by Rob Myall

Garden is a room. The chair is a fixed in place enterable supporter in Garden.

When play begins:
say “You sit[Begin-sitting].”

To say Begin-sitting:
try silently entering a random visible supporter.
[/code]

Output:

That’s a tough one. I think you’re running into the I7 feature that tries to put a paragraph break between messages printed in different rules. You’re right that a “try silently” shouldn’t trigger that, because it’s not printing anything, but maybe the action mechanism doesn’t realize that.

The best I can suggest is to rework your code. Option one, use an ordinary phrase rather than a say phrase:

When play begins:
	say "You sit.";
	begin-sitting;

To Begin-sitting:
	try silently entering a random visible supporter.

Option two, move the player directly rather than using an entering action:

When play begins:
	say "You sit[Begin-sitting].";

To say Begin-sitting:
	surreptitiously move the player to a random visible supporter.

Thanks.

Unfortunately this particular instance is already nested inside a “to say” phrase so option 1 is a bit of a pain; I guess I could refactor the table lookup to a set of rules rather than straight text to give the extra flexibility.

I’d missed “surreptitiously move…”; that seems to work in this instance.

I’ll hunt it down and see if I can file a bug report. Silent actions should be silent.

Wow, it’s in ProcessRulebook(), which is recursive. The relevant piece is this: } else { if ((say__p) && (bits & RS_NOSKIPS == 0)) DivideParagraphPoint(); rv = indirect(substituted_rule); if (rv == 2) rv = reason_the_action_failed; else if (rv) rv = substituted_rule; }
Where say__p is true because “you sit” was printed, and the other condition allows anything except Activities to pass through.

The I7 way to work around is this:[code]
The pending paragraph break is a truth state that varies.
The pending paragraph break variable translates into I6 as “say__p”.

To say Begin-sitting:
now pending paragraph break is false;
try silently entering a random visible supporter.[/code]
I’ll file a bug report wondering if ProcessRulebook() should have a line prepended for this case.

(EDIT: Done with possible solution.)

Thanks Ron.

I’ve been having a lot of similar issues. One way to solve it is to place the token somewhere else, like this:

[code]“Test” by Rob Myall

Garden is a room. The chair is a fixed in place enterable supporter in Garden.

When play begins:
say “[Begin-sitting]You sit.”

To say Begin-sitting:
try silently entering a random visible supporter.[/code]

The problem is you’ll have to pay attention, because you can end up with extra lines you don’t want. Another solution is to add something to your to say phrase:

[code]“Test” by Rob Myall

Garden is a room. The chair is a fixed in place enterable supporter in Garden.

When play begins:
say “You sit[Begin-sitting].”

To say Begin-sitting:
say run paragraph on;
try silently entering a random visible supporter.[/code]

But, once again, this spreads to all the line, and you can have lines missing.

These are, of course, workarounds. I use [place to say phrase here with commands instead of prints] a lot, and I have to battle with it sometimes.

EDIT:

I tried to juggle the [] code around, and found that:

When play begins: say "You sit.[Begin-sitting]" [the token after the full stop]
And:

When play begins: say "You sit."
Prints in the exactly same way, so it may be better than putting it in the beginning, as I suggested before.

Yes, littering it with [run paragraph on] was an option (technically, it’s doing the same thing as Ron’s suggestion of setting say__p back to false) but it’ll just end with lots of proliferation that is liable to be a bugfixing nightmare so I was hesitant to go down that route when “try silently” really should be silent. At least with the “pending paragraph break” solution, I’ve got something easy to search for and remove if the core bug gets fixed.

Moving the included “[Begin-sitting]” might work in this test example, but because I was already nested inside another to-say statement, it wasn’t solving the problem in the place I was using it and I was still getting an extra line-break in some cases.

Keep in mind, though, that “try silently” is only supposed to be silent if a check rule doesn’t say anything. It processes the Before, Instead, check and carry out rulebooks, but skips the report rulebook (not sure what it does with the After rulebook).

Er, Mikee you sure about that? Check rules are silenced. [code]Place is a room. Bob is a man in place.

persuasion: rule succeeds.

Instead of waiting, try silently Bob jumping.[/code]Entering WAIT to make Bob silently jump prints nothing, as expected. The block jumping rule is indeed a check rule.

If you remove the word “silently” from that example, you still get no output. But if you remove the word Bob, you see “You jump on the spot, fruitlessly.”

Most check rules only print output if the actor is the player - otherwise they delegate the output to the “unsuccessful attempt by” rulebook. Didn’t you write an “unsuccessful PC attempt” extension?

It’s been ages. I was surprised there were instances when dead silence could happen, is all. Thanks.

It is a bit surprising. I expected to see “Bob is unable to do that.” But perhaps the unsuccessful attempt rules only run when asking Bob to try something?