Extension updating advice

I’ve posted some notes from my own experience updating extensions to be fully 6L02-compatible. It’s probably incomplete advice, but it’s here.

Even if you’re not otherwise really running into trouble, you may be interested in this point: the convention that the Standard Rules follow, and that I followed in my extensions, is that parser error messages addressed to the player (“You’ll need to enter a number.”) should not be adapted from second-person singular, because they do not apply to the protagonist. For instance, it would not make sense to say “He needed to enter a number” about the third person, past-tense protagonist.

Huh. I’d have thought it would.

If you’re describing someone standing in front of a safe, maybe, but if you’re describing what needs to be typed into the keyboard by the player, and there’s no keyboard equivalent in front of the protagonist, then it wouldn’t.

AAaaah. I’d failed to understand that, apologies.

EDIT - Changing from third-person to second-person like that would be a bit jarring, normally, even though it’d probably be clear on context. I’d lean towards making those second-person deviations italicised, which is another convention in itself, but I guess it would be hard/impossible for an extension author to manage this, since there’s no telling what sort of game the extension will be used in.

I suppose if a set of rules were identified as being “player-directed”, an author could do something like “Before printing a player-directed rule: say italic type”, and such (rouding it off with “say roman type” at the end, naturally).

Just woolgathering, thinking aloud. Probably not worth the trouble.

This is actually something that we were just talking about on the mud:

Some authors like to put such messages in square brackets, or italicize them, or otherwise set them off – so I think it would indeed be a reasonable feature to tag these somehow so that they can be universally handled.

(I’ve now filed a suggestion for this: inform7.uservoice.com/forums/57 … ch-respons )

It sounds to me like the Responses system makes it possible to do that in an extension. I propose an “Extradiagetic Responses” extension.

The problem is someone still has to systematically decide which extensions are extradiegetic and which are not. And then as soon as you install an extension where such decisions haven’t been made, your parser becomes inconsistent. I agree that future built-in support for this would be cool.

My (old) extensions had a semi-consistent way of marking such parser messages and letting the author style them. I’ve temporarily removed this from my extensions updated for the new build, since it involves hand-meddling with each individual message. With responses, it would be easier to do this without mucking with the message itself, probably with a Table of Extradiegetic Messages that gets consulted whenever you print a response, but I haven’t had time to look into doing something like that yet.

Aren’t responses a kind of enumerated value? I think you should be able to add properties to them, such as “A response can be extradiegetic. A response is usually not extradiegetic.” and then manipulate your new property (“Before issuing the response text of an extradiegetic response: switch to out-of-story mode.”) Does this work? If not, why not? This would require manually marking all the parser error responses as extradiegetic (something that could easily go in an extension, I would think), but then other extension authors could also include such markings in a “for use with Extradiegetic Responses” section, or if some extension author has failed to do this (but still used Responses properly), you could go ahead and do it yourself.

I think Aaron is saying that you could, but he’d like it better if Inform conventions forced all extension authors to do it themselves.

Responses are a kind of enumerated value but they don’t have property storage. That could be added if I7 wanted to go that way, of course.

Seems like a strange special case. Was the worry that the responses system is kind of complicated and memory-intensive as it is without also allowing them to have properties?

You’d have to ask Graham.

Several kinds of value are enumerable (that is, you can repeat through them) but non-property-able: truth state, use option, verb, table name, action name.