This is a thread for public proposals for modifications of the file formats used by JJ2. The ones I'm proposing here would have no effect ingame but are instead to be used for storing data for use in editing programs, but if JJ2+ development resumes or the source code is released, proposals that would affect the game (e.g. ordering layer display by the unused layer z-index properties) would become feasible.


List of Locked Words in Data1 of .j2l files
J2L specification

The section "Unknown4" in the first data stream of level files, located between tile types and animated tiles, is 1024 (or 4096) bytes long. I've looked at over four thousand levels and it's all zeroes in every one of them, and I have seen no effect from modifying it either. I propose filling it in with a list of shorts pointing to words (as defined in Data3) which should be considered "locked" for the purposes of editing and primarily saving.

When saving a level, as described here and at greater length in the Reworder documentation, JCS (and also MLLE and WebJCS) goes through the level layer by layer (starting with 1 and ending at 8) and breaks the layer layout data into "words" of 4x1 tiles each. Two instances of the same four tiles (e.g. blank, blank, blank, blank) will, in the general case, use the same word, potentially lowering the .j2l filesize. If a set of four tiles contains an animated tile with an event on it, JCS/MLLE/WebJCS will automatically record this as a new word. While this allows trigger scenery (and other such events) to affect words used in background layers, it is impossible to affect words used in foreground layers without the use of Reworder.

The proposed "locked" words would be a list of always-identical-to-one-another words which independent (=fanmade) level editors such as MLLE and WebJCS would respect on saving. For instance, in ReworderEx1.j2l, word #64 includes the animated tiles to make the top half of the scarab beetle appear in the foreground. The word appears in layer 2, where it is visible to the player, and in layer 4, where trigger scenery is applied to it. Saving in JCS eradicates this connection and creates two separate words in place of one. If #64 were included in the list of locked words, an independent level editor would override its usual "event on animated tile equals a new word" behavior and bind the instance in layer 4 to the instance in layer 2. (Note that the word number itself might not still be 64 after further edits, and so the list of locked words would have to be number-independent and moreover recalculated on every save.)

This proposal includes recommendations for how to save levels (i.e. overrule the usual word-defining behavior) but not for editing levels. Individual implementations may decide how to handle the case of a user wishing to edit the tiles of a locked word, as well as providing interfaces for locking or unlocking words in the first place.


Smart Flipped Tiles in Data1 of .j2t files
J2T specification

.j2t files include several [MAXTILES]-long (=1024 or 4096) strings of unused bytes, including Unknown2, which is actually 4*MAXTILES long. I've tested it in over one thousand tilesets and it was all zeroes every time. I propose filling the first half of it with shorts pointing for any tile x to the tile y within the tileset that is equivalent (in mask) to tile x flipped and yet tiles properly with nonflipped tiles.

For instance, consider Castle. Flipping tile 2,2 -- the upper-left wall corner piece against a background block -- will result in an upper-right wall corner piece, yet one that does not look right combined with other nonflipped tiles. (In this particular case, the grooves on the floor are in the wrong direction.) The smart flipped tile list would include a pointer to tile 9,2 -- the upper-right wall corner piece. An independent level editor would then provide users with an option of smart flipping a selection tile by tile (as an alternative to actual graphical flipping), resulting in a selection with a mask equivalent to that of the selection flipped the regular way, but one which tiles properly with ordinary tiles. Since many CTF levels have symmetrical layouts, a simple action to automate the laying out of the other half would reduce development time considerably.

To delve briefly into actual values: tile 2,2 corresponds to tile #11, and tile 9,2 to tile #18. The 11th short within the Unknown2 section would thus have a value of 18, and the 18th short would have a value of 11. If a tile with no set smart flipped value (i.e. a value of 0) is smart flipped, it should remain the same tile.

(To the best of my knowledge there are currently no independent tileset editors, largely because there is little pressing need for one. This would be one incentive for the creation of a program. Another is allowing tileset designers finer control over tile-by-tile transparency. For instance, Scorpio Key includes a palette tile. Since the only real use for a palette tile is things like 8-bit textured backgrounds and 8-bit water -- a level designer rarely places a palette tile in their level -- I made the palette tile serve as the typical invisible block tile by specifying in the .j2t that the tile is fully transparent. Unfortunately, I had to do this manually using j2ff and a hex editor, because no independent tileset editor exists.)


Alternate Tiles in Data1 of .j2t files

This is essentially the same idea as the above, with the same sort of implementation, but without specifying that the alternate tile pointed to has to be the flipped equivalent. Instead, tileset designers could decide on a tile-by-tile basis which tile best counts as "alternate." For example, a tileset with cave tiles (e.g. Carrotus, Diamondus) could have caveless tiles include pointers to the caved equivalents, and vice versa. Tile 6,4 in Diamondus would include a pointer to tile 8,6, and so on. However, this needn't only be used for a caved/caveless distinction; a tileset with two different colors of certain tiles, e.g. many of the gems in CrysilisV, could include pointers from one color to another to let the level designer quickly swap individual gems back and forth without having to find all the right tiles manually.

Storagewise, these pointers would occupy the latter half of Unknown2, since it's 4*MAXTILES long and the pointers would all be shorts and thus only 2*MAXTILES long.