New guy can't code

Probably.

Regarding the punctuation problem, what do you mean about “the font won’t match up”? If it’s outside the quote marks it’s just for Inform, it won’t be shown to the player.

Testing has proved this to be a lie. /maury

where the bold stuff is fixed letter spacing font and the non-bold period at the end is the regular variable letter spacing font.

The original text is available for download on the same page as the PDF: http://www.musicwords.net/if/i7hb.htm. You’ll need OpenOffice or something that can open an OpenOffice document, but that’s trivial.

The Creative Commons License at the end of the Handbook is explicit: You have the right to freely make adaptations.

On the whole, I feel an organized update (with me as the coordinator) would probably be better than having five people rush off in five different directions with it. But you’re free to do what you like.

I have done some additional work on it already. I’ve revised more than 100 pages.

Then the situation isn’t as bleak as you painted it. :slight_smile: Glad to hear it.

… that’d be something nice. a revised handbook brought up to date for numbnutses like me. :slight_smile:

It’s because you have the period—inside the quotes—in two different places. They both print. Move them both outside the quotation marks and they’ll disappear.

Assuming you’re commenting on my message, perhaps I should clarify that the version of the Handbook available for download is still the 2009 version. The updated chapters have not been uploaded.

I could be talked into finishing the new version – but some authoritative technical assistance would be needed. A way to replicate the behavior of that vanished extension is not likely to be the only technical issue that would need to be addressed. Posting questions to the forum is hit-or-miss. I feel disinclined to go on with the project given the very real probability that some future question would likewise prove unanswerable, or at any rate not answered.

but i have

say "[fixed]text.".

because without that period it won’t run. and if i do it like that, it has two periods.

AND! it turns all the text afterwards in fixed as well. so i have to [variable] right after that and then it freaks out on that!

so right now i’m using

say "[fixed]text. [variable]more text".

which wasn’t what i was going for but it’s an in-between solution.

It won’t run if you have this?

say "[fixed]text".

it will run. but it will make everything, even player commands and any text that follows, as fixed. (until the game text gets to change format again)

the only way i see around that would be to put “variable” in front of EVERYTHING but even that wouldn’t be a perfect fix. and it’s a bit out of scale to do something so invasive and massive for somethign so … buh.

I’d love to help in any way that I can, but I simply might not be able to, given my beginner status with I7. I’m keen, just not that knowledgeable (yet). However if you were to consider using a (for example) private Google doc, then multiple users could edit the document collaboratively, concurrently. Crowd-editing, kind of, but only for those you allow.

But I guess the problems are larger than the method of editing the document.

Your “Carry Out” reading rule has a period on it. That’s where the extra period comes from.

I just removed the period FROM THE WARRANT TEXT (removing the period from the carry out rule was also removing a necessary line break), added a bedroom and a bed, and I’m getting the behaviour you want.

[code]The bedroom is a room. The bed is in the bedroom.

A thing has some text called the reading-material. The reading-material of a thing is usually “”.

The warrant is on the bed. The description is “Arrest warrant for [bold type]Vres Ruuga[roman type], by Judge Sahraan.” Understand “arrest” and “warrant” as the warrant.

The reading-material of the warrant is “[fixed letter spacing]This is a test[variable letter spacing]”

Understand the command “read” as something new.
Reading is an action applying to one thing and requiring light. Understand “read [something]” as reading.

Check reading:
if the reading-material of the noun is “”:
say "Nothing is printed on [the noun].” instead.

Carry out reading:
say “[reading-material of the noun].”[/code]

Technically, the period is displayed as variable spacing, I guess, but in the IDE that’s a completely invisible nuance. Do you need it? Because if so you can try instead:

[code]The reading-material of the warrant is “[fixed letter spacing]This is a test.[variable letter spacing]”

Carry out reading:
say “[reading-material of the noun][line break]”[/code]

Peter’s code works. I think the underlying problem is that you’re bumping up against some of the complications of exactly how you can permissibly end a line in Inform 7.

Your original code had this:

The reading-material of the warrant is "[fixed letter spacing]This is a test.[variable letter spacing]" Understand the command "read" as something new.

As you said, Inform didn’t like this because it lacked a period at the very end of the line. And if you omit the period from this:

Carry out reading:
	say "[reading-material of the noun]."[/code]

Inform won't like this either.

But Peter's code: 

[code]The reading-material of the warrant is "[fixed letter spacing]This is a test.[variable letter spacing]"

Carry out reading:
	say "[reading-material of the noun][line break]"

does work, even without periods. What gives?

Basically, Inform knows that a code block ends when it sees a period at the end of the line. That’s why

Carry out reading: say "[reading-material of the noun][line break]".

will work no matter how you space it.

But it also recognizes that a code block has ended when you have a normal sentence-ending punctuation inside the quotes, like this:

Carry out reading: say "[reading-material of the noun]."

It doesn’t need another period after the quotes, because it knows that the period inside the quotes is ending the code.

But this:

The reading-material of the warrant is "[fixed letter spacing]This is a test.[variable letter spacing]"

doesn’t end with a period inside the quotes! So Inform doesn’t know it’s ending a code block.

However, if Inform sees an entire blank line (two carriage returns) it knows that the code block has ended. That’s why this works:

[code[The reading-material of the warrant is “[fixed letter spacing]This is a test.[variable letter spacing]”

Carry out reading:
say “[reading-material of the noun][line break]”[/code]

(again, assuming that there’s a blank line after the last line).

So, to summarize, this works:

Lab is a room. The description of Lab is "this is a punctuationless description". A rock is in Lab.

because of the period. And this works:

[code]Lab is a room. The description of Lab is “this is a punctuationless description”

A rock is in Lab.[/code]

because of the blank line. But this fails:

Lab is a room. The description of Lab is "this is a punctuationless description" A rock is in Lab.

For the exact same reason, these work:

Lab is a room. "[fixed letter spacing]This shows up in fixed letter spacing.[roman type]". A rock is in Lab.

[code]Lab is a room. “[fixed letter spacing]This shows up in fixed letter spacing.[roman type]”

A rock is in Lab.[/code]

But this fails:

Lab is a room. "[fixed letter spacing]This shows up in fixed letter spacing.[roman type]" A rock is in Lab.

To summarize the summary, if you’ve got a line with quotation marks, and it’s failing to compile with a confusing message that runs it together with the next line of code, put in a period after the quotation mark.

Sorry for the dual-purpose thread, folks. Maybe the moderators can split this discussion into a new thread, but that might be more trouble than it’s worth.

I’ve never used a private Google doc, but you’re right – the problem isn’t really about editing. I’m a professional editor, and have been for many years. Also, I can test my own code examples and make sure they work. (Suggested refinements are always welcome, however!) What I can’t easily do is fix extensions that are broken. Consolidated Multiple Actions is, in my opinion, necessary to allow Inform to produce modern, professional-looking output in certain situations – and it’s broken.

I’m pretty sure there are other extensions that various people might like to use that are also broken. (Secret Doors, for instance. I was able to fix that one myself.) The root problem is the way I7 relies on extensions but also insists on breaking them. None of us can fix the root problem – only Graham can fix it – so our only option is to fix the broken extensions. And some of them are pretty darn complicated.

The fact that there is no mention of procedural rules in the current documentation suggests strongly to me that there is no documentation on how to fix broken extensions. That’s what is needed. It would be a WONDERFUL addition to the Handbook – but it’s beyond my technical ability to write it. If someone else can write that, documenting all of the commonly or even occasionally encountered problems with older extensions, I can use it to fix the extensions that are actually needed by the examples in the Handbook.

Win-win.

I’m all for that, but really, I’ll already be very happy with a doofus-grade handbook I can wrap my head around.

I have to re-read a lot of the posts in these threads just to get what’s going on.

So yes. “doofus-grade”.

Because right now my Inform7 experience still involves a healthy heap of swearing at the computer.

Honestly, I’m not as clever as people think I am.

Jim, feel free to start a new thread so you’re not talking over the coding questions.

The change logs used to be included in the documentation. I don’t know why they aren’t any more.

Too big, I think. They’re on the Inform website, on the download page for their respective versions (e.g.). The one that really has all the information you need for updating is the 6L02 log. Sections 5j and 5k are particularly relevant. (Also downloadable as an epub!)

With the ever-changing code, would it be an option to publish it on a user-editable wiki-type platform?

Hey guys! That discussion has moved here :slight_smile: