Compiling with Inform 5

Authoring Inform 6
1

Hi, I’m compiling a game with inform 5.5 but does not accept accents or ñ.

I save the document before compiling with UTF-8 but is only accepting Ansi.

Any idea?

2

Memory is dim, but I think that I5 supported abbreviations like

@~n @:u @`e @'e @^o

UTF8 in the source code is only supported by the latest Inform 6.33 (not yet formally released).

3

Not working, I wrote that and I saved with ansi…

4

Nope, I was wrong. Sorry.

It’s @@ followed by a decimal number, as defined in the table at the end of inform-fiction.org/zmachine/stan … ect03.html . So “@@206” for ñ, “@@157” for ü, etc.

The Inform 5 manual is available: ifarchive.org/if-archive/infocom … manual.pdf

5

Than you, Zarf, that helps!

6

Hi there, i thought it was working but that code it’s only showing a few characters starting with @@161 = ¡, no “ñ” or accents.

What can I do?

7

Try the ASCII value after the @@, instead of the Z-machine alphabet code? I don’t know, I haven’t done it in years. You’ve got the manual.

8

Not working either. That manual doesnt seem for inform 5.5. For example there is not Zcharacter directive in this inform…

9

The code is working in a part of the code, the one written in the perl script to extract the data to the inf. Any other idea?

10

Thanks to ddddd here it is a simplified example of the error. How can I print a Zcharacter passing through output_stream? Instead of ñ is printing I with another symbol:

[code]array big_buffer -> 2048;
global print_buffer;

[ Main;
! (i)
@output_stream 3 big_buffer ;
print “@@206”;
@output_stream -3;

! (ii)
print "@@206>";

! (iii)
flush_buffer();
print_buffer = big_buffer + 2;
@print_table print_buffer 1;
quit;

];

[ flush_buffer
no_new_line ! INPUT: If non-zero, never print NL.
a c;
@output_stream -3;
if (big_buffer–>0 ~= 0) {
a = big_buffer+2;
c = big_buffer–>0;
@print_table a c 1;
if (no_new_line == 0) new_line;
}
];

[/code]

11

The @print_table opcode is not generally used these days. It’s possible that interpreters aren’t handling it right. Actually, as I try a few, the behavior of @print_table is totally inconsistent. Don’t use it.

This is what I’d do in Inform 6:

[ flush_buffer len ix;
    len = big_buffer-->0;
    for (ix=0 : ix<len : ix++)
        print (char) big_buffer->(2+ix);
    new_line;
];

This may require tweaking for Inform 5.

On the other hand, if you’ve got the “print (object) obj;” syntax straightened out, you may be able to use Inform 6.

12

Thank you, it’s working! I think this is finally solved! :slight_smile:

13

For a big game, in order to work, I had to changed it to this and its giving the problem again:

[ flush_buffer len ix; @output_stream -3; len = big_buffer-->0; for (ix=0 : ix<len : ix++) print (char) big_buffer->(2+ix); new_line; ];

So, the problem is the output_stream?

Update: Probably the print_table again. I have it all over the code…

14

Every “@output_stream -3” should be matched with (closing) an opening “@output_stream 3”. It’s probably a mistake to have it standing alone like that.

You also can’t nest these open/close pairs.

15

After the changes and remove the print_table code, it’s working.

However, when playing online in parchment, the new room location overwrites the old one without removing it. It only happens in parchment, playing in the computer is working fine.

Here’s the code I see in relation to that:

SortItems(location, new_sorted); ! This must be done anyway. if (location ~= old_location) { redraw_needed = 1; old_location = location; }

16

You mean, the buffer winds up looking like “Crawle a Building”, with a shorter name overwriting an older longer one? Or is this appearing in the status line?

Could be a Parchment bug.

17

Curio, I think it’s important to mention that the code is comming from scott2zip, not standard Inform libraries, but yes… if it’s working OK on other interpreters I suppose it’s a Parchment bug/limitation too.

Does this happens without the print_table patch?

18

Yes, the first case, overwritting a longer one. As ddddd said it comes from the scott2zip perl code that creates an inform 5 code.

No, it happens after the print_table patch…

19

Don’t know how the patch affects this. It just do a replacement of the @print_table calls to a function based on zarf’s code…

[ print__table__alternative a len ix; for (ix=0 : ix<len : ix++) print (char) a->(ix); ];

… and I can’t reproduce the issue.

The routine DrawStatusWindow seems to be erasing the upper window:

if (window_size ~= 0) { @erase_window 1; }

20

I made the descriptions equally long, in order to solve this problem. Thank you all,