Error updating to new "room" format (with pre-creation code)

[sorlok_reaves]

When I try to load my iji.egm file, I get the following error:

Code: [Select]

java.io.IOException: Unexpected end of file reached at filepos: 971
at org.lateralgm.file.GmStreamDecoder.read(GmStreamDecoder.java:80)
at org.lateralgm.file.GmStreamDecoder.read(GmStreamDecoder.java:59)
at org.lateralgm.file.GmStreamDecoder.readStr(GmStreamDecoder.java:132)
at org.enigma.file.EFileReader$RoomGmDataReader.readData(EFileReader.java:1194)
...
It is clear that this is caused by the Room decoder looking for the "pre-creation" event that was just added recently.

Edit: Actually, it might be from translation/rotation/scale? Either way, the engine is expecting something in the room binary blob that is not there, so it is over-reading.

Unfortunately, I have no idea how to recover from this error. Consider:

• I am storing Iji unzipped in a directory (which I then zip up into an EGM file).
• The room_x.rmg file is a binary file
• Apparently the room editor now looks for the missing properties  in the .rmg file?

So do I have to manually edit every .rmg file in a hex editor? Or is there some way for the plugin to auto-detect if it is loading an old rmg file and then add the the missing properties? I don't mind doing this once or twice, but if the .rmg format is going to change frequently, then I would recommend adding versioning.

Edit: Or perhaps someone could provide a script to update .rmg files when the format changes?

[egofree]

I knew this would happen. 
I am the one who modified the file reader and writer for egm files. At first, i wrote a very simple versioning system which would allow to test if we are dealing with an old version of egm files. But IsmAvatar, the creator of LateralGm, asked me to drop the support for old version of egm files. I said this would be a dangerous situation, but she said she would take care of this. As she is rarely present on this forum , i will present my temporary solution : a modified version of enigma.jar : https://dl.dropboxusercontent.com/u/29802501/enigma.jar. This should be put in enigma-dev/plugins folder and replace the original one. But before, make sure you make a backup of the original one. This version of enigma.jar should be used only for converting old egm into the new format. It will not read new properties, but it will write them. When you have loaded your projects, and saved them, delete this version and put back the original one. Tell me if you have any problems.

[Josh @ Dreamland]

The point of EGM is that, since it is completely text based with named attributes, it should be incredibly hard to break. Are rooms being stored as binaries?

[IsmAvatar]

Yes, Josh. LGM doesn't quite fully honor the spirit of EGM yet. There's an experimental textual format for rooms, but nobody's working on it currently, so to avoid scope creeping that into a simple "let's add a checkbox", egofree just added the setting into the rooms binary format.

Of course, to complicate the matter, the room binary format isn't even versioned, so this was inevitable. As ego said, I said I'd deal with any issues that arise, but it looks like ego beat me to the punch.

[sorlok_reaves]

Thanks for addressing this so quickly! I'll try out the converter after work.

[Goombert]

I think we should have just added a version number....

Especially considering it is a format constantly in alpha/beta...

Consider that no format would be truly "final" but EGM has been stable enough to get the job done for some time now.

[sorlok_reaves]

Just tested it, and everything seems to work. Much thanks!

In terms of moving forward, I would suggest using a version number for binary formats only, as text-based formats are fairly easy to keep track of (as they list their own properties). If that's not possible, then a converter like the one used in this forum thread is sufficient (for me at least).

[Josh @ Dreamland]

That's fine, Ism; EGM needs some formatting overhaul, anyway. We use that EEF format I made up to store objects, as I understand it, and in hindsight that was my dumbest EGM suggestion. We were better off solving the YAML problem at hand—that is, the problem where code whitespace might not be preserved—by inserting a comment before the code, eg,

Code: (yaml) [Select]

name: object0
events:
  -create:
    id: 0
    subid: 0
    code: |
      // User code begins here
        var haha; // This is the first line of actual user code
        var i_started_this_code_at_an_indent_of_2;
      return 0; // This is the last line of actual user code, which has less indent than the rest of the code, but won't trip the YAML parser because of our comment above
    applies-to: self
  -destroy:
...
My suggestion for rooms is just an SVG-like blob of points.

Code: [Select]

  instance-format: object-name, x, y
  instances: obj_player 320 240 obj_wall 0 0 obj_wall 0 32 obj_wall 0 64

We can be more meta if we want to save space and do something more like SVG does:

Code: [Select]

  objects:
    a: obj_player
    b: obj_wall
    c: obj_bat
  instance-format: object-name, x, y
  instances: a 320 240 b 0 0 b 0 32 b 0 64 ... b 0 32 c 128 128 c 416 128

For reasons of beauty, redundancy, and capacity, you could extend the shorthand space to a..z..A..Z..aa..az..ba..bz...Aa..Az...ZZ..., give precedence to shorthand identifiers, and allow just naming objects. So "obj_player 320 240 w 0 0 w 32 0 w 64 0 w 96 0..." would be completely fine as long as w is bound to obj_wall. In the case where there's an object named a, the shorthand gets precedence. You can be cutesy and assign shorthands based on the first character (or first character after object/obj_).

Just my 2¢, broadcast as usual.