Room & Dimension Version 2 (Need betatesters)

[Basti50]

Odd, it should look something like this. At least it works on both git and gargoyle for me. Glulx seems to have problems with it though or maybe it’s just the long loading times, don’t have time to test it right now. Maybe you actually need a file extension for the Mac interpreters? :shrug:

[Erik_Temple]

It’s a bit hard to test, but it seems that the interpreter just crashes on startup if it can’t load the file. If the file does load, then the graphics/text doesn’t display, which suggests that the data isn’t loading properly. I’m not sure why this would be; Gargoyle in particular should be pretty much the same on both Windows and Mac. Here’s what I can summarize so far, based on my testing and what you say:

WinGlk/git (WinGit): file with no extension loads, and graphics display.
WinGlk/glulxe (WinGlulxe): file with no extension may or may not load.
GarGlk/git(?), Windows: file with no extension loads, and graphics display.
GarGlk/git/glulxe, Mac: file with no extension loads (?), but graphics do not display.
CocoaGlk/git/glulxe (Zoom): if file has .glkdata extension and is in the user’s home folder, file loads(?), but graphics do not display.

–Erik

[bcressey]

@Basti50

There also seems to be some sort of strange bug with either R&D or Gargoyle as this example always crashes with it when I try to move before doing anything else. The example seems to run fine in Git so I’m a bit puzzled what the problem could be. Different memory allocation maybe?

The stack trace shows the crash happens here, when characters are written into the input buffer that you supplied when you called glk_request_line_event.

You are probably passing an invalid memory address.

[Basti50]

@Erik

Could you try something out for me, if you find the time? Could you test out if Inform 7’s internal interpreter can handle the example, in case the Mac version even has one? Here is anything you should need to do that. You may need to create your own file though. In that case, just open the Cyberspace project, comment out the entire When play begins rule and replace it with

write "Placeholder" to built-up-file of Cyberspace;

then find the file and replace everything but the headline with the file it doesn’t want to read, then return the When play begins rule to its original form, then compile.

Also, can you tell me what kind of output this example creates for the different interpreters?

It should be (especially the two spaces between the words would be important)

F
i
r
s
t
[

]
S
e
c
o
n
d

T
h
i
r
d

[Basti50]

@bcressey

You are probably passing an invalid memory address.

Thank you for looking into this! Do you have any spontaneous idea how this could occur while it all works fine after doing anything but moving once?

[bcressey]

@ektemple

Note that Zoom will crash unless the text file has an extension of .glkdata (there may be other extensions that will work, not sure), but Gargoyle can’t have that extension or it will crash. Does anyone know if there is an extension that will work for all external files? If not, this seems like something like the Glk spec ought to require…

Gargoyle is not crashing in the case where the file has an extension. The game calls glk_fileref_create_by_name with the filename “CyberLayout” twice, and then spins in an infinite loop doing nothing.

Gargoyle will not match “CyberLayout” to anything other than a file called “CyberLayout” with no extension. Zoom assumes that a file with usage type data will have a .glkdata extension, so it looks for “CyberLayout.glkdata” file. If that fails I assume you wind up in the same scenario as with Gargoyle: the game tries twice and then spins forever.

Both garglk and cocoaglk are conforming to the spec, so as a practical matter your only recourse is to handle this in your code.

Does Inform allow you to ask for a file called “CyberLayout.glkdata” instead of the bare filename?

[bcressey]

@Basti50

Thank you for looking into this! Do you have any spontaneous idea how this could occur while it all works fine after doing anything but moving once?

I don’t have any insight beyond restating the issue in your terms: your code must be doing something on the first turn or when play begins that short-circuits the ordinary bookkeeping that takes place before a call to glk_request_line_event.

I downloaded the source Cyberspace and it looks like it probably happens in “open up text-window” or “follow the refresh windows rule”.

[Basti50]

@bcressey

The game calls glk_fileref_create_by_name with the filename “CyberLayout” twice, and then spins in an infinite loop doing nothing.

Yeah, the loop is supposed to run through the file until a ‘]]’ appears and since the file is empty that never happens. I did have the activity check for a minimum file length in a Before rule to abort the process but I didn’t know or forgot that the activity would still be initialized even when the rule fails, another thing I got to fix.

@bcressey

Does Inform allow you to ask for a file called “CyberLayout.glkdata” instead of the bare filename?

You mean like

File of Cyberspace Layout is called "CyberLayout.glkdata".

That doesn’t work since there are no dots allowed, although Inform 7’s interpreter will automatically assume that they are .glkdata, but that doesn’t help the other interpreters, apparently.

[Basti50]

I don’t have any insight beyond restating the issue in your terms

That is already more than I could ask for so thanks again

I was just wondering if you would be aware of any great differences between gargoyle and all the other interpreters that would cause it to crash but not the rest at least for the Windows version.

[Erik_Temple]

@bcressey

Gargoyle is not crashing in the case where the file has an extension. The game calls glk_fileref_create_by_name with the filename “CyberLayout” twice, and then spins in an infinite loop doing nothing.

Sorry, “crash” is just my imprecise way of saying “the interpreter UI ceases to respond, while the interpreter process continues, eating up 100% or so of the CPU, failing to terminate even after closing the window and quitting the application.” I should have said “hang”.

Of course, the extension should show a failure message for files that can’t be read, rather than failing into an infinite loop.

@bcressey

Does Inform allow you to ask for a file called “CyberLayout.glkdata” instead of the bare filename?

No, the I7 compiler throws up an error if you try to include a period in your filename. Inform believes that the game code must be agnostic about the file extension and that the interpreter will add its own extension if it likes. This works just fine if a game creates the file itself and we always use the same interpreter to play it, but it is a failure of design in these two cases:

1. An author wants to distribute his own file with his game, as here;
2. A player wants to switch from using Zoom to Gargoyle, or vice versa, after the file has been created.

So, it looks like rather than changing the spec, we need to get Graham to change Inform’s file-handling so that authors can exercise control over the extension. Does anyone know if Zoom would defer to the user-provided extension in creating a file, or if it would just add another .glkdata at the end, e.g. “CyberLayout.glkdata.glkdata”? (This would mean that, even though Case 1 was solved, Case 2 would still present difficulties.)

–Erik

[bcressey]

@Basti50

I was just wondering if you would be aware of any great differences between gargoyle and all the other interpreters that would cause it to crash but not the rest at least for the Windows version.

Invalid pointers are tricky. Sometimes you write to it and get a crash. Sometimes you silently corrupt something else. Sometimes you get lucky.

I don’t get the crash in the Cyberspace import file, just the crash version, if that helps narrow down the scope of code to review.

@ektemple

So, it looks like rather than changing the spec, we need to get Graham to change Inform’s file-handling so that authors can exercise control over the extension. Does anyone know if Zoom would defer to the user-provided extension in creating a file, or if it would just add another .glkdata at the end, e.g. “CyberLayout.glkdata.glkdata”?

It would append a second .glkdata extension, based on this code.

[zarf (Andrew Plotkin)]

This works just fine if a game creates the file itself and we always use the same interpreter to play it, but it is a failure of design in these two cases

This is in my bailiwick, but I don’t think the right answer is to push file-suffix control all the way in to the game file.

I’ve posted a separate thread: Harmonizing Glk file suffixes?

Any interpreter changes will take a long time, however. I’d say the best option for today, if you want to distribute data with your game, is to embed the data in the source code directly, as text.

[Basti50]

@bcressey

I don’t get the crash in the Cyberspace import file, just the crash version, if that helps narrow down the scope of code to review.

The crashes had only occurred with 30x30 simple-top-down-displays, which is another oddity. So far, I haven’t found another constellation for gargoyle to crash but I’ll create a test loop and see if there is any pattern to this.

[bcressey]

In lieu of a file extension, you could follow up the call to glk_fileref_create_by_name() with a call to glk_fileref_create_by_prompt(), to let the user find the file. Ugly, but at least it gives you a chance of ending up with the data you’re looking for.

I don’t really like Zoom’s behavior - if an author requests a file called “CyberLayout”, and that file exists, it seems wrong for the library to append .glkdata to the filename and then fail to open it for reading.

However, Inform 7 does seem to allow you to have two distinct files with the same name:

The binary File of Binary Data is called "file". 
The File of Text Data is called "file". 

I haven’t tested this, but Zoom should be able to read and write to separate files (file.glkdata and file.txt) where Gargoyle couldn’t.

If so, Gargoyle’s implementation is broken for Inform. What I don’t know is whether it is legal for Glk. The spec has this comment in it:

Another example: on a platform where file type is specified by filename suffix, the library will add an appropriate suffix based on the usage

But this strikes me as descriptive rather than prescriptive - advising authors of what might happen rather than dictating parameters for the implementation. If not, and extensions are required on platforms that support extensions, those extensions should be specified.

EDIT: Oops, missed zarf’s response.

[Basti50]

@Basti50

The crashes had only occurred with 30x30 simple-top-down-displays, which is another oddity. So far, I haven’t found another constellation for gargoyle to crash but I’ll create a test loop and see if there is any pattern to this.

Great, now I can’t find the right configuration to reproduce the bug anymore. Consider this issue solved until I find the problem again

[Erik_Temple]

@Basti50

Could you try something out for me, if you find the time? Could you test out if Inform 7’s internal interpreter can handle the example, in case the Mac version even has one? Here is anything you should need to do that.

The Mac IDE interpreter is a modified version of Zoom. I can get this to run in the IDE as well, but the result is the same: none of the graphics show up. They are in the filepath, and they are packaged into the blorb if I build one, but they are never drawn. The text version doesn’t print either–the output is exactly the same as I described above.

@Basti50

Also, can you tell me what kind of output this example creates for the different interpreters?

The output is the same for both Zoom and Gargoyle, including the two lines between each section.

–Erik

[Basti50]

@ektemple

The output is the same for both Zoom and Gargoyle, including the two lines between each section.

I appreciate that you find the time for some test-runs. Looks like I’ll have to try a step-by-step analysis.

Does this example create the following output?

Reading the file: File of Cyberspace Layout
[[
.
]]
Starting the loop
Current letter: .
New current letter: .
Current letter:

Read: line break followed by close bracket

Loop done
Map layout: 1/1/1

Floor

[Erik_Temple]

Copied and pasted out of Gargoyle/git:

[code]Reading the file: File of Cyberspace Layout

[[

.

]]
Starting the loop
Current letter:

Read: line break followed by next line
New current letter:

Current letter: .
New current letter: .
Current letter:

Read: line break followed by next line

Loop done
Map layout: 0/3/1

g_t_border[/code]

–Erik

[Basti50]

Thanks!

Hm, crud, looks like the problem comes from those extra line breaks between the period and brackets that are added for no apparent reason. Can’t think of any easy solution for that, other than offering two separate R&D releases which take this into account

[Erik_Temple]

Could you post-process the data to ignore or eliminate line breaks? The file seems to use brackets as the primary semantic marker for sections, so that maybe the line breaks are redundant anyway?