2.00 *New* terrain/objects-related discussion topic

[namida]

It's pretty clear that - no matter how sure I am that a proper binary format is preferable to NeoLemmix's design - some people are never going to give up on insisting that their way, and only their way, is supported. As much as I'd rather do it the way I prefer, and the way that I see working best for NX2 - more than this, I would rather avoid a situation where development stalls forever (or worse, I decide I've had enough of the arguments and cancel the project) over debate regarding how to use graphic sets. So - fine, directory structure it is. And no, no other formats will be supported, except semi-automated conversion (not direct use) of legacy formats.

Now that that's out of the way, let's try and at least have a reasonable discussion on how they'll be implemented, and what features should be supported. Also - how exactly, under such a framework (since I think if we're going to go for this structure, we may as well abandon any notion of a "graphic set" beyond as a way to categorize pieces into seperate sub-folders), should features that are usually tied to the graphic set - such as brick color, one-way arrow graphics, etc be handled? Should they be specified on a per-level basis, or should there be "header" type files which contain different combinations of these? Etc.

[namida]

My preliminary thoughts on how to lay this out:

<Main graphic "set" directory>
Folders here should reflect the author of a graphic set. Some names may be "reserved" (not enforced in any way, but usage discouraged so that they can be used for specific purposes - eg. "Official", "Cheapo", etc).

<Within these folders>
Folders here should reflect the graphic sets themself. eg. "Dirt". Styles of the same names from different authors could be combined by default in the editor - somewhere in the metainfo should specify which ones are the base set and which are addons, perhaps also which author's style is being added to (to avoid oddities occuring when, say, Alice makes "Grass" style, Bob adds to it, Carol makes her own "Grass" style that's completely unrelated, and Doug (yeah, I don't know what the 4th name in this series is) adds to that one).

<Within these folders>
Terrains and objects - possibly divided into two seperate subfolders? Individual pieces would be identified by "<Author>/<Style>/<Piece>".

Terrains
- Images for each resolution. (What's the best naming system to differentiate?) Only one resolution is required.
- Optional: Physics mask, which shows which pixels are solid, non-solid, steel, etc. If not found, autogenerates based on the 1x resolution image, or if that isn't found, from downscaling the smallest one.

Objects
- Images for each resolution. Same naming system would be used as for terrains. Again, only one resolution is required.
>>> should there be some kind of choice here, where it can either be a strip, or seperate images for each frame? The former would require explicitly specifying how many frames.
- Trigger area mask.
- Metadata; eg. trigger area type, the offset from the image of the trigger area mask image (to allow for negative position trigger areas; just in case); trigger point (for receivers, etc), etc.

Gadgets (one-way arrows, pickup skills, etc)
- Images for each resolution. Only one needs to exist.

General graphic set metadata
- A single file of course. Anything that relates to the set as a whole.


Note: Don't worry for now about "how will old levels work with this?". I have a plan for that, and can discuss it more closer to when I'm coding level loading / saving / handling.

[geoo]

Individual pieces would be identified by "<Author>/<Style>/<Piece>".

I think this is a good way to do it, yeah.
You have an interesting point about multiple people having graphics sets of the same name. Allowing the meta-info file for a graphics set to specify a graphics set which this set is an extension to allows to maintain authorship for each individual tile. In lix right now, if you add a tile to someone else's tile set it will go into the original creator's folder and not in yours.

Images for each resolution. (What's the best naming system to differentiate?) Only one resolution is required.

Considering your point about the pre-extensions in like, e.g. tile.S.png specifying a steel tile, I wonder if this could be all avoided by rather than sticking to naming schemes, there could just be folders called "1x", "2x", "mask", "meta-info". For most terrain tiles, you'd only have one resolution, no mask and no meta-info, so just dumping a bunch of pictures in the 1x or 2x folder would give you a working tile set sans objects. meta-info would contain text files specifying if a tile is steel or whatever else it can be, and defaults to non-steel/whatever is most common if no meta-info is present.

Should there be some kind of choice here, where it can either be a strip, or seperate images for each frame? The former would require explicitly specifying how many frames.

In lix the former is used and the number of frames is auto-detected as there's a border around each frame. Not sure if this is the best way to handle it. The number of frames can be written into the meta-info file which has to exist anyway. I think eidcut can convert a strip into a sequence of images, but some authors might prefer one, some the other, so supporting both might be handy. For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames? And should those frames follow a numbering scheme, or should each of the images be specified in the meta-info file?


Some other questions:

Alpha handling, how to determine what is solid and what isn't? If full alpha pngs are going to be supported, this is an interesting question that also pertains to LixD. Should a mask actually belong to a terrain piece? I was wondering, if full alpha blending is supported for level design, then overlaying a lot of low-alpha (almost transparent) regions will give a high-alpha (almost opaque) region which would still be non-solid as none of the original regions were solid. Should just a bitmap for the whole level be created internally, anything pixel that, at the end, has alpha-value >= 0.5 is solid, and anything that has alpha value < 0.5 becomes non-solid, and maybe even overwritten with the background color to reduce ambiguity for the player? I don't know what the best solution for alpha handling is.

If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?

Tiles that are partially steel: As mentioned in another topic, do we really need this? One use I can see though is VGASpec levels that use steel, as mentioned somewhere. It's a bit cumbersome for these, but I can't think of a workaround that doesn't introduce new functionality (like a traditional steel area tile or something).

How, internally, should a level refer to a terrain piece/object it uses? Straight-forward answer: base path. (E.g. namida/forest/trunk, and the game infers that the image is in namida/forest/1x/trunk.png, the meta-info in namida/forest/meta-info/trunk.txt, etc). This works a lot more nicely in a text based level format as such paths are variable length of course.

Should sub-folders be supported for organizing tile sets better? For instance, my construction tile set has sub-folders for concrete blocks, wall pieces, metal rods, so the main folder doesn't flow over. Is this desirable? Implementation-wise it shouldn't be too much harder if tiles are referred to as described in the previous paragraph. If folders are used for different resolutions and meta-info however, and some tiles are in the main construction folder and some in the concrete, wall folders, the main folder would contain "1x", "2x", "mask", "meta-info", "concrete", "wall", the latter two having different semantics from the former 4 which seems a bit unelegant.

[Nepster]

Overall this sounds sensible. Some thoughts resp. questions nevertheless (none really important):

1) Perhaps have the name of the graphic set first and subfolders for various authors. Graphic names feel somehow more important than authors, so they should go first. And then Alice could indicate her folder as the main one by including the general graphic set metadata file; all other folders (that may not include a general metadata file!) are automatically seen as addons without need to specify this.

2) I see no need to separate the objects from the terrain pieces by introducing subfolders.

3) Depending on our decision on "arbitrary trigger areas vs. only rectangular ones", maybe one does not need specific trigger area masks, but can include this info in the general metainfo file.

4) Strips for objects have the advantage to reduce the number of files in the folder and one cannot accidentally delete one of the frames in the middle. Number of frames, size of object, ... can go into the metainfo file.

5) In what respect are one-way-walls different from all other objects, so that they need extra handling?

6) Do we need to add things like the hatch, pick-up skills, ... to each style folder, even if they are the same each time? Perhaps one can have one folder "General" for such objects, which are included automatically in every style.

7) What information would the general graphic set metafile store exactly?

PS: Written while geoo was posting and not adapted wrt. his arguments.

[namida]

I'll come back to your post geoo - most of Nepster's questions I can answer quite quickly so I'll cover those now.

1) Perhaps have the name of the graphic set first and subfolders for various authors. Graphic names feel somehow more important than authors, so they should go first. And then Alice could indicate her folder as the main one by including the general graphic set metadata file; all other folders (that may not include a general metadata file!) are automatically seen as addons without need to specify this.

7) What information would the general graphic set metafile store exactly?

The reason is in case, for whatever reason, two authors make entirely different sets with the same name. And the connection to Q7 here - one thing it would contain is which author's set it's an addon to. Of course, because of the ability to combine multiple graphic sets (or rather, discarding them as anything beyond a categorization scheme for pieces), there's no reason it really matters, other than editor interface.

2) I see no need to separate the objects from the terrain pieces by introducing subfolders.

If the whole point of a folder structure is to make it easier to modify / improve, then shouldn't it be kept tidy by keeping the two seperate?

3) Depending on our decision on "arbitrary trigger areas vs. only rectangular ones", maybe one does not need specific trigger area masks, but can include this info in the general metainfo file.

This is possible. But I think arbitrary areas is the way to go - even rectangular ones can be abused, and good reasons to use arbitrary ones have been presented, eg. circular buzzsaws, diagonal lasers.

4) Strips for objects have the advantage to reduce the number of files in the folder and one cannot accidentally delete one of the frames in the middle. Number of frames, size of object, ... can go into the metainfo file.

That's true, but it can be convenient to work on each frame as a seperate image. Perhaps both methods should be supported?

5) In what respect are one-way-walls different from all other objects, so that they need extra handling?

They're not being treated as objects. Think of them as more like steel areas from L1, or like Cheapo's implementation of one-way walls. In this regard; they aren't objects as such, just a graphic. Although - I did just get an idea as I wrote this; perhaps they can simply be implemented as resizable objects?

6) Do we need to add things like the hatch, pick-up skills, ... to each style folder, even if they are the same each time? Perhaps one can have one folder "General" for such objects, which are included automatically in every style.

No. Essentially, the idea of a "graphic set" will only be a way to group pieces together; a level can arbitrarily mix-and-match them. Even before deciding to go with this structure, since use of multiple graphic sets in one level was a planned feature, no graphic set would need to have those pieces, because a level author could just use them from another set. With that being said, I do plan to have a "default" set containing objects of most types, apart from ones that tend to be specialised.

[namida]

Considering your point about the pre-extensions in like, e.g. tile.S.png specifying a steel tile, I wonder if this could be all avoided by rather than sticking to naming schemes, there could just be folders called "1x", "2x", "mask", "meta-info".

That's a workable idea.

For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames?

Not sure what you're meaning here?

And should those frames follow a numbering scheme, or should each of the images be specified in the meta-info file?

I think this is a case where being numbered is perfectly fine. Having to specify them in the meta-info file is an inconvenience.

<alpha blending>

Yeah, I'm not entirely sure on it either. A user option can be provided to erase any misleading pixels; using this would ultimately be the best option to avoid confusion (at some eye-candy cost). Exactly how to handle mask autogeneration when alpha is involved is something I'm not entirely sure about either.

If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?

This sounds like a shortcut with potentially nasty results, which could be avoided by enforcing use of a mask (at least when a 1x image is not present). Perhaps NX2 should auto-generate a mask the first time it encounters a piece without one? However, this could raise problems if the piece is a WIP and the user doesn't realise this has happened.

Tiles that are partially steel: As mentioned in another topic, do we really need this? One use I can see though is VGASpec levels that use steel, as mentioned somewhere. It's a bit cumbersome for these, but I can't think of a workaround that doesn't introduce new functionality (like a traditional steel area tile or something).

Steel areas for this purpose become very tedious to place if the steel isn't straight-edged. One perhaps tidier workaround would be to create a "subset" images of the main one, only containing the steel parts, and place that over the top of the main one (and it could then be marked as steel).

Should sub-folders be supported for organizing tile sets better? For instance, my construction tile set has sub-folders for concrete blocks, wall pieces, metal rods, so the main folder doesn't flow over. Is this desirable? Implementation-wise it shouldn't be too much harder if tiles are referred to as described in the previous paragraph. If folders are used for different resolutions and meta-info however, and some tiles are in the main construction folder and some in the concrete, wall folders, the main folder would contain "1x", "2x", "mask", "meta-info", "concrete", "wall", the latter two having different semantics from the former 4 which seems a bit unelegant.

The obvious thing to come to mind would be to not allow subfolders in a folder that has pieces in it. However, this seems unnessecerially restrictive.

[Nepster]

...namida's answers to my questions...

All of them good points, but concerning one-way-walls: Perhaps I misunderstood somthing, but I thought the main idea was to separate the visual display of arrows from the mechanic-wise important area the OWW covers. So we have:
a) An area indicating where the terrain should be a OWW, which is stored in each .lvl-file. How one defines this area in the editor might very much depend on how you want to save this area in the level file, but this is totally independant of the question which style to use or how to store any graphic files, no?
b) Visual display of arrows: This is a set of pictures, together with a meta-info file stating "These are left/right/down arrows for OWW" (and other relevant things) and only this has to be stored in some style folder. These "objects" are then displayed on the OWW.
How to associate the OWW-area in the editor to the correct graphic set also depends on how OWW areas are stored within the level file, imo.

If a graphics set exists for 2x, and the masks are inferred from the images, and now someone adds new 1x tiles, this might change physics. (Not sure if this is ever gonna happen, I mean who would downscale 2x images for this?) Should the graphics set meta-info file allow to specify which resolution to infer the masks from, so that in this case it would infer from the 2x imagery instead the newly added graphics?

This sounds like a shortcut with potentially nasty results, which could be avoided by enforcing use of a mask (at least when a 1x image is not present). Perhaps NX2 should auto-generate a mask the first time it encounters a piece without one? However, this could raise problems if the piece is a WIP and the user doesn't realise this has happened.

And what happens if the user deletes this NX2-generated mask at some time after adding the 1x image? It might be noted, that the same issue may occur if 2x tiles are added later. Who guarantees that the terrain displayed there fits the terrain mask generated by the 1x tile?

[geoo]

For the list of separate images, should then a subfolder of "1x" exist, named like the object, that contains all its frames?

Not sure what you're meaning here?

If there's an animated object, say, water, in a tile set, say forest, at 1x resolution. Should its animation frames be forest/1x/water/0.png, forest/1x/water/1.png and so on with meta-info forest/meta-info/water.txt, or would you propose a naming convention like forest/1x/water_0.png, forest/1x/water_1.png and so on? Then how would you determine if this is a list of individual objects/tiles, or all belonging to the same objects? I guess the meta-info could indicate that there's such a thing called water, and it has a certain number of frames, following the default naming scheme (i.e. water_0.png and so on).

[namida]

a) An area indicating where the terrain should be a OWW, which is stored in each .lvl-file. How one defines this area in the editor might very much depend on how you want to save this area in the level file, but this is totally independant of the question which style to use or how to store any graphic files, no?

Correct.

b) Visual display of arrows: This is a set of pictures, together with a meta-info file stating "These are left/right/down arrows for OWW" (and other relevant things) and only this has to be stored in some style folder. These "objects" are then displayed on the OWW.
How to associate the OWW-area in the editor to the correct graphic set also depends on how OWW areas are stored within the level file, imo.

Essentially, the one-way wall (mechanics wise) is placed like a steel area (non-autosteel). The graphic is then applied to those areas - the way I'm seeing it at the moment, the choice of graphic is done either per one-way area (in which case, it could simply be an object that allows resizing, but is only applied to specifically-marked terrain), or per level.

And what happens if the user deletes this NX2-generated mask at some time after adding the 1x image? It might be noted, that the same issue may occur if 2x tiles are added later. Who guarantees that the terrain displayed there fits the terrain mask generated by the 1x tile?

The core design rule is - physics remain the same regardless of resolution. In that regard, the mask must remain the same regardless of resolution. So, it is up to the designer to ensure the higher-resolution image matches the mask.

If there's an animated object, say, water, in a tile set, say forest, at 1x resolution. Should its animation frames be forest/1x/water/0.png, forest/1x/water/1.png and so on with meta-info forest/meta-info/water.txt, or would you propose a naming convention like forest/1x/water_0.png, forest/1x/water_1.png and so on? Then how would you determine if this is a list of individual objects/tiles, or all belonging to the same objects? I guess the meta-info could indicate that there's such a thing called water, and it has a certain number of frames, following the default naming scheme (i.e. water_0.png and so on).

The first idea here makes sense - although would it not be better to use (using the same example) forest/water/1x/0.png?

[Simon]

Only some loose ideas for now.

I assume NL2 can be set to display 1x graphics, even if there is no 1x tile, and the game will downscale the wanted nx tile appropriately. I also assume that the mask is a 1x image.

I feel like the game shouldn't ever autogenerate 1x tiles or masks in the data dir. It should downscale to 1x while loading a tile that lacks a 1x version. If no mask is given, the game should infer regions from the downscaled image with a standard rule, but not write any of this to the data dir.

1x is special. Maybe don't make a subdirectory for 1x, and put whatever would have gone in the 1x directory into the parent directory. Maybe make the 1x directory nonetheless, for consistency.

I believe forest/water/1x/0.png is slightly better than forest/1x/water/0.png. We can put meta-info that's independent from scaling into a file forest/water/meta.txt. It matches my mental model better: Tilesets have tiles, tiles have properties and occasionally come in several resolutions.

I have no idea whether people like it better to edit anims with all frames in one file, or with each frame in a separate file. I'm only used to having them all in one file, that makes for fast color replacement, transparency settings etc. that apply to all frames.

Do you support nesting directories arbitrarily deep, or do you expect that dirs at a certain nesting level are always tiles?

-- Simon

[namida]

I feel like the game shouldn't ever autogenerate 1x tiles or masks in the data dir. It should downscale to 1x while loading a tile that lacks a 1x version. If no mask is given, the game should infer regions from the downscaled image with a standard rule, but not write any of this to the data dir.

In this case, should a guideline exist that the creator of a tile should always provide a physics mask if a 1x resolution image does not exist? Or do you think the best method is to specify which resolution to autogenerate it based on (using 1x as a default - or in the absence of a 1x image, the lowest-resolution (or maybe highest-resolution?) image that is supplied)?

I have no idea whether people like it better to edit anims with all frames in one file, or with each frame in a separate file. I'm only used to having them all in one file, that makes for fast color replacement, transparency settings etc. that apply to all frames.

In my experience, making modifications to existing ones is easier with all-in-one file, but depending on the type of object, creating an entirely new one is often a much tidier process with seperate files for each frame. This is why I'm wondering if ultimately, it may be worth supporting both.

Do you support nesting directories arbitrarily deep, or do you expect that dirs at a certain nesting level are always tiles?

The first two levels would have special handling, due to the fact that same second-level names (with different first-level ones) can be treated as addons rather than standalone sets. Beyond that, I'm not sure what the best way to handle this is - as geoo mentioned, it could be untidy if say, the main folder contains some pieces (and thus has "1x" "2x" etc subfolders) but also has subfolders that contain more pieces. One possible solution (and IIRC I suggested this already) is a scheme where a folder either contains pieces or contains subfolders (ie: it cannot contain pieces as well as containing subfolders). Equally possible is not enforcing this at a technical level (instead just treating the "keyword" names to not treat as subfolders), and simply making it a guideline for creators.

[Simon]

Guideline for masks: Haven't thought about it enough, will reserve answering for later.

Do you want to make subdirectories for every tile, even if it is a single image in one resolution without mask?

I haven't thought about it since much, but there's this idea: Assume a set comes in only one resolution. It can be awkward to have myset/piece00/1x/tile.png, myset/piece01/1x/tile.png, and so on. Reason: Each subdir would have only one image, and many programs are good at thumbnails for all images in a given dir, but rarely recurse through subdirs.

This again suggests something closer to geoo's directory structure (myset/1x/piece00.png, myset/1x/piece01.png, ...), or thinking it through anew.

Maybe don't enforce such a structure, and scan the pathname for /2x/ instead. If it is found, it's a 2x piece, if nothing is found, it's a 1x piece.

Anticipate what will happen most of the time, and allow that to be straightforward.

Maybe I'm worrying too much, and the nested dirs are OK with only 1 file inside. It's a cosmetical idea. Requiring one directory per tile, even if it's a most trivial tile, can be interesting, too.

Directories that mix both tiles and subdirs: If the rules become easier without such mixed dirs, feel free to forbid mixed dirs.

-- Simon

[geoo]

Implementation-wise the myset/piece00/1x/tile.png is cleaner.

But for a graphics set designer it's more convenient to have one folder with all the images. Most tiles won't have meta info or anything like that, so having to navigate into another folder for that is not that much of an issue I think, unlike having to navigate into a new folder for each new tile (and creating those in the first place).

The structure also lends itself to natural nesting. Only obtaining the identifier from the image path is a little less straight forward as the '1x' or whatever resolution is available has to be cut out in the middle of the path, rather than just truncated from the end.
Allowing to sort tiles into subfolders thematically creates the following issue (depending on how objects are implemented): if objects in the 1x/2x/... subfolder are represented as a folder containing the individual frames rather than a single image with all frames, as then the only way to distinguish it from a subfolder of tiles is looking for corresponding meta-info. This meta-info file will have to exist, so it's always possible to distinguish, but implementation-wise a bit more complicated. For the graphics set designer though it should be obvious what is a folder of terrain and what are the frames of an object.

[namida]

Alright, I've finished modifying the graphic set / piece handling code to exclusively suit a folder-based structure. (Tidied up a few other things at the same time.) I haven't yet implemented saving or loading; since we're still discussing the exact implementation, I'll first work on replacing the existing rectangular trigger area code with code that allows for arbitrary areas.

If we go back to the idea of seperating terrain and objects - perhaps one way to avoid mess in this regard is to have entirely seperate folder trees for the two. In other words, the structure would be:

<author>
..<set>
....TERRAIN
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
....OBJECT
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
......<piece.png, piece.ini, etc>
....GADGET
......<piece.png>
......<piece.png>
......<piece.png>


I am starting to question at what point dividing it up will go against the idea that a folder structure is supposed to be friendlier to the content creators (but then again, since I never really understood that idea in the first place...), though - having to navigate through a hundred different folders seems a lot less user-friendly to me, than having a proprietary format with a tool that can quickly pull out the relevant image. But I do think that keeping terrain and objects seperate, at some level, is a logical decision either way.

Within these folders - I'm thinking the best idea (ignoring any questions of sub-categorization - the more I think about that, the more I'm questioning if we really need it, since there's no reason you couldn't just have a couple of related "sets") is to keep the metadata (including mask images) in the main folder, with subfolders being used exclusively for the various resolution images. I don't know that I like the idea of keeping a 1x image in the main folder rather than a 1x resolution subdirectory, primarily because this would imply that a 1x image is obligatory and only the other resolutions are optional (when in reality, the only requirement is that one resolution is provided - it doesn't nessecerially have to be 1x).

[namida]

Eh, I kinda ended up doing things in the exact opposite order of what I suggested. Although I didn't code anything for handling the graphic loading/saving yet, I came up with a sample folder structure - based on the low and hi res pairs of psychedelic set that I've made. Sample graphic set folder attached.

Note the following:
1. I still intend to support arbitrary trigger areas. However, since I see rectangles as still being the most common case, I've also allowed these to be defined in the metadata text file. My idea is that in the case that both are present, the image should override - however maybe also a warning should be generated if a single piece specifies a trigger area via both methods?
2. Note the difference between "trigger area" in some objects, and "trigger point" in others (the window and the receiver). This is because any object that can receive a lemming will use a point, not an area - which is important when it comes to objects that can do both - ie: two-way teleporters and single-object teleporters.
3. My idea of handling masking for terrain pieces is that - if no mask is present, it autogenerates it based on which pixels are or aren't transparent (how to handle semitransparency is not yet determined), by default from the 1x image, but perhaps the metadata (perhaps a graphic-set-global setting should be allowed here, so it doesn't have to be specified per-image) can specify to use a different resolution, in cases where the author has no intent of creating 1x images (which is fair enough, since they can be autogenerated from the 2x ones - but there needs to be some way to ensure that physics won't change if a 1x image is later added, which is why I'm thinking require either (a) a mask, (b) a 1x image, or (c) an explicit specification to use a different resolution to auto-generate masks).
4. Note how three of the stairs images specify an "offset" for the 2x image. This is because the leftmost column in them is intended to be displayed one pixel to the left of the terrain piece's position. An alternative might be to modify the graphic set itself to account for this (by repositioning the graphic in the 1x image), then patching old-format levels when loading / converting them. EDIT: I am indeed thinking that modifying the graphic set itself (and patching old levels when loading) is the better option.
5. The "brick_pink" and "brick_yellow" pieces are indeed new; they don't exist in the current version of the Psychedelic set. But they're also quite logical additions, seeing that brick_red and brick_green already existed, and bricks_4x4 and bricks_2x2 include yellow and pink pieces as well as red and green ones.

The contents may be freely used for any purpose, including in other engines.

[namida]

Basic loading algorithm for terrain. Let me know if you think there's a better method:

1. Check that the collection (ie: author name and style name combination)'s folder exists. If not, throw an error.
2. If it does, check that either a mask, a metainfo file, or a 1x resolution image exists - as it is compulsory to have at least one of these three things.
3. If it does, scan for all available resolution folders, and load the appropriate images.
4. If a mask exists, load it. If not, generate one from the appropriate source image (the 1x image, unless the metadata file says otherwise).

The mask image pixels are interpreted as follows, with those lower down the list taking priority in the event that multiple criteria are fulfilled:
1. The default fallback option (which in practice, is any "colorful" pixel) is that the pixel can support one-way walls and is solid.
2. A white pixel (defined as R, G, B > 192) will be solid, and will not become steel, but also will not cancel steel if the pixel it's placed on is already steel.
3. A gray pixel (defined as 192 >= R, G, B > 64) will be solid, and will be treated as steel.
4. A black pixel (defined as 64 >= R, G, B) will be solid, and will not become steel, and will also turn a steel pixel back to normal if it overlaps.
5. A transparent pixel (defined as 64 > A) will be non-solid.

The reason for the "not steel, but doesn't cancel steel" becomes apparent when considering levels like Taxing 7 or Mayhem 1, that have a lot of pieces that are overlaid over steel but are clearly not intended to actually cancel the steel. I foresee the level data being able to override these default settings of pieces, so it's just one means towards the same end; discussion may be needed as to what conventions should be encouraged in this regard.

In the case of autogenerating a mask, alpha = 128 is the cutoff at or above which a pixel is treated as solid (once resampled down to a 1x resolution, if need be). In such a case, solid pixels are the steel-cancelling variety (as this is likely to be the most commonly-used type). Perhaps the metadata should be able to override this? EDIT: Metadata can override this now.


Saving is a bit more straightforward. My rule here is - no shortcuts when saving! So there's no specifying in a metadata file "use steel pixels, not normal ones" or "default to this resolution"; rather, it will always save a proper mask.

So, it's simply:

1. Delete any existing metadata file / images (otherwise, we may end up with a situation where if we were immediately to load it again, we may end up with different contents, due to files already existing).
2. Save the mask. The mask is already in memory regardless of whether one existed when loading (it autogenerates it in memory if none exists, rather than working around needing one).
3. Save each resolution's image to the appropriate subfolder.

When saving, the following mask colors are used (corresponding to the same number in the above list), in ARGB order - although any other value (within the tolerances mentioned) will also work fine:
1. 0xFFFF0000
2. 0xFFFFFFFF
3. 0xFF808080
4. 0xFF000000
5. 0x00000000

Similar processes will go for objects, though one major question here - should it save a strip, or a series of individual frames? I think we need to find out which is the more popular preference (I could implement both - but let's be honest, given that there was such a strong opinion in favor of a folder structure, I'm expecting that most people won't be saving pieces from the editor anyway, instead preferring to manipulate them directly, since otherwise the whole fuss would've been for nothing if people plan to use specialised tools anyway). If there's no strong preference either way, most likely I'll go with saving as seperate image files, as that's a lot less work to implement.

[Nepster]

Some (likely very naive) questions concerning the mask pixel interpretation:

1) Why do we need type 4 pixels? Don't they behave precisely like type 1 pixels?

2) Why do we actually need type 2 pixels? One may get essentially the same effect by specifying globally (i.e. for all terrain pieces at once) in the level file either
- a pixel is steel if the upmost terrain piece that defines a solid pixel there is a type 3 pixel.
- a pixel is steel if there exists some terrain piece specifying a steel piece there.

3) Why do we even need to distinguish between type 2, 3 or 4 in the mask? I don't see a reason to use more than one type in one terrain piece and then it would be cleaner and more flexible to have an option in the editor to specify the precise type. (But see my argument below, that having such an option at all is undesired.)

4) As a player I associate non-solid pixels with black ones. So I would prefer to have the same colour scheme in the mask image. This has an additional advantage when viewing with other programs: Black is always distinguishing, but transparent pixels might be displayed e.g. as white.
Note that I only discuss colour choices for the mask, not for the actual image.

5) I think we should discourage very much the use of type 2 and 4 pixels. The default should be "looks like steel, is steel" and "looks like normal terrain, is normal terrain". Everything else just feels like a bad joke on the player.
In practice this means: Type 2 and 4 will always default to type 1 pixels. I am not even sure, whether we need any option in the new editor to change this. New levels should use the default option and for the few L1 levels that need this, one could manually change it in the raw .lvl file.
PS: If you have an option in the new editor to change this, then you need to cook up (for the editor) a good way to communicate to the level designer, which pixels are currently steel and which are not. Additional work to code for a feature, for which I see no future use...
PPS: Note that this is essentially a suggestion to remove the options "SimpleAutosteel/DisableManualSteel/ClassicSteel" from the editor and only keep "Autosteel". Has anyone actually used an option apart from "Autosteel", except for levels made in traditional Lemmix?

6) Metadata should NEVER override the steel-cancelling pixel property. If I use a terrain piece, I expect it to have the default property, until told otherwise. Changing this default property should be widely visible, e.g. by coming with a separate mask, not by changing a line in the metainfo file that can easily be missed.

7) Just to get my expectations right: I assume that most usual terrain pieces (except steel pieces and those that exist only in higher resolutions) will have neither a mask nor a metainfo file. The mask will be autogenerated from the 1x image and there are no additional infos that need to be stored in a metainfo file. Correct?

8) Saving... This reads like you are expecting users to use a specific program to create new terrain pieces. Then please be aware that some users (like me) will just create .pngs using completely different programs and just dump the result in the style folder (after properly naming it, ...).

[namida]

1) Why do we need type 4 pixels? Don't they behave precisely like type 1 pixels?

Primary use for Type 1 is in VGASPEC-type pieces, where you're going to want some but not all of the piece to be one-way-capable. In the case of regular terrain pieces, I'd see it as more likely that the user would override the piece's default setting in the editor (for the individual usage of that piece).

2) Why do we actually need type 2 pixels? One may get essentially the same effect by specifying globally (i.e. for all terrain pieces at once) in the level file either
- a pixel is steel if the upmost terrain piece that defines a solid pixel there is a type 3 pixel.
- a pixel is steel if there exists some terrain piece specifying a steel piece there.

Not sure what you're meaning here?

3) Why do we even need to distinguish between type 2, 3 or 4 in the mask? I don't see a reason to use more than one type in one terrain piece and then it would be cleaner and more flexible to have an option in the editor to specify the precise type. (But see my argument below, that having such an option at all is undesired.)

See answer to 1.

4) As a player I associate non-solid pixels with black ones. So I would prefer to have the same colour scheme in the mask image. This has an additional advantage when viewing with other programs: Black is always distinguishing, but transparent pixels might be displayed e.g. as white.
Note that I only discuss colour choices for the mask, not for the actual image.

This is a fair point, and I can most certianly change this.

5) I think we should discourage very much the use of type 2 and 4 pixels. The default should be "looks like steel, is steel" and "looks like normal terrain, is normal terrain". Everything else just feels like a bad joke on the player.
In practice this means: Type 2 and 4 will always default to type 1 pixels. I am not even sure, whether we need any option in the new editor to change this. New levels should use the default option and for the few L1 levels that need this, one could manually change it in the raw .lvl file.
PS: If you have an option in the new editor to change this, then you need to cook up (for the editor) a good way to communicate to the level designer, which pixels are currently steel and which are not. Additional work to code for a feature, for which I see no future use...
PPS: Note that this is essentially a suggestion to remove the options "SimpleAutosteel/DisableManualSteel/ClassicSteel" from the editor and only keep "Autosteel". Has anyone actually used an option apart from "Autosteel", except for levels made in traditional Lemmix?

I already explained the main usage for type 2. Type 4 is pretty much what, under current NeoLemmix, is what any pixel on a non-steel piece would be. I don't know why we would want to discourage that?

6) Metadata should NEVER override the steel-cancelling pixel property. If I use a terrain piece, I expect it to have the default property, until told otherwise. Changing this default property should be widely visible, e.g. by coming with a separate mask, not by changing a line in the metainfo file that can easily be missed.

Since the default is the most common, the presence of the line at all in the metadata should suggest something's up. If you were seeking to change this on an existing piece, you'd most likely either create a mask (thus overriding it), or notice that the piece has metadata, which is pretty much only either specifying the default pixel type for solid pixels, or specifying what resolution to auto-generate a mask from.

7) Just to get my expectations right: I assume that most usual terrain pieces (except steel pieces and those that exist only in higher resolutions) will have neither a mask nor a metainfo file. The mask will be autogenerated from the 1x image and there are no additional infos that need to be stored in a metainfo file. Correct?

Correct.

8) Saving... This reads like you are expecting users to use a specific program to create new terrain pieces. Then please be aware that some users (like me) will just create .pngs using completely different programs and just dump the result in the style folder (after properly naming it, ...).

Yes, I'm aware of this. I'm not even sure how worthwhile it is to create a piece editor; certianly it won't be a high priority now. But the way I see it, it's better to implement the underlying functionality of saving pieces now, than have to work it in later.

[Nepster]

Sorry, I completely misunderstood the function of type 1 pixels, see point 9). So let me explain some of my unclear arguments and add a few more:

2a) My basic questions were:
- Assume all terrain pieces have type 4 pixels (or type 3 in case of steel). May we then reproduce the L1 levels by changing the definition of type 4 into the one of type 2, globally once-and-for-all and for all terrain pieces at the same time (possibly by a command in the .lvl file)?
- Does it give enough options to level designer, if they have to choose between using only type 2 or only type 4 pixels?

3a) Apart from typos in my previous argument, here is it again: Do we need terrain pieces, that have both type 2 and 4 pixels? If no, then why not let the level designer decide on this as an option in the editor (assuming we want to encourage the use of type 2 pixels), and remove the distinction in the mask file?
Regarding type 1 pixels, please see point 10).

5a) The original argument suffered greatly from my misunderstanding of type 4 pixels. So the question is now: Do we want to encourage or discourage the use of type 2 pixels? I am very much in favour of strongly discouraging the use of type 2 pixels.
If we want to discourage using type 2 pixels, then should we even allow their use are a regular editor option? I would say: No.
The correct L1 levels could still be created via a master editor kept secret by namida, that has options to use type 2 pixels.
(This argument is off-topic for the general discussion and was made to respond to namida's sentence "discussion may be needed as to what conventions should be encouraged in this regard.")

9) Shouldn't be type 4 be the default fall-back option, if it is the way NeoLemmix treats almost all terrain pieces and type 1 is only for VGASPECs?

10) So type 1 behaves exactly like type 4, except that the one-way option is automatically enabled? If yes, then why is the following procedure impossible: Create your VGASPEC using type 4 pixels, load it into the editor and enable one-way by hand. Then, as the one-way-areas can have arbitrary sizes now in V2.00, select precisely the required pixels for the one-way area.

[namida]

2a) My basic questions were:
- Assume all terrain pieces have type 4 pixels (or type 3 in case of steel). May we then reproduce the L1 levels by changing the definition of type 4 into the one of type 2, globally once-and-for-all and for all terrain pieces at the same time (possibly by a command in the .lvl file)?
- Does it give enough options to level designer, if they have to choose between using only type 2 or only type 4 pixels?

If I'm understanding you correctly, the options would be roughly the same as the current steel options - perhaps not at a technical level, but to the end user?
And they would not have to choose - the way I see this is that an individual piece in a level can specify (possibly with the level as a whole also specifying a default) to either "use mask" in which case all areas are as the mask specifies (which could be a mixture of multiple types), or otherwise to specifically change all solid pixels to a certain type (perhaps with some limitations - mainly, using it to allow one-way walls on pieces that don't outright specify this).
To compare to current NeoLemmix, hopefully this clears it up:
Type 1: This would be equivalent to a pixel of a normal terrain piece with the "One Way" flag enabled.
Type 2: This would be equivalent to a pixel of a normal terrain piece with "Simple Autosteel" enabled.
Type 3: This would be equivalent to a pixel of a steel terrain piece (or a pixel covered by a steel area).
Type 4: This would be equivalent to a pixel of a normal terrain piece with "Simple Autosteel" disabled - or in other words, the "normal" scenario.
Type 5: This one shouldn't need explanation.

3a) Apart from typos in my previous argument, here is it again: Do we need terrain pieces, that have both type 2 and 4 pixels? If no, then why not let the level designer decide on this as an option in the editor (assuming we want to encourage the use of type 2 pixels), and remove the distinction in the mask file?
Regarding type 1 pixels, please see point 10).

I don't see them ever being used together in a terrain piece, but it's easier to allow it than to not allow it. Pieces I could see Type 2 being used in would be, for example, the moss pieces in the Dirt set (that are often overlaid on top of steel as decoration, but are not intended to remove the steel). Since there might be valid uses where the steel should be cancelled - or perhaps usage of other pieces in such a way that steel should not be cancelled (grass on top of the steel, maybe?), this is why an option will also exist in the level format; but this option would be more limited, it would be either "use the properties (which may be mixed) from the mask" or "change all solid pixels to <insert any type here>".

5a) The original argument suffered greatly from my misunderstanding of type 4 pixels. So the question is now: Do we want to encourage or discourage the use of type 2 pixels? I am very much in favour of strongly discouraging the use of type 2 pixels.
If we want to discourage using type 2 pixels, then should we even allow their use are a regular editor option? I would say: No.
The correct L1 levels could still be created via a master editor kept secret by namida, that has options to use type 2 pixels.
(This argument is off-topic for the general discussion and was made to respond to namida's sentence "discussion may be needed as to what conventions should be encouraged in this regard.")

The editor would need to at least preserve the setting if it finds it in a loaded level. And when we get to that point, it would almost be more work to hide the option. Discouraging use doesn't have to mean hiding it. I also don't like the idea of a "secret" editor version (and besides, open source would mean anyone could simply modify the editor to add / unlock the option). More likely would be, at most, some kind of "secret" key combination to unlock it - but I probably just wouldn't hide it at all.

9) Shouldn't be type 4 be the default fall-back option, if it is the way NeoLemmix treats almost all terrain pieces and type 1 is only for VGASPECs?

The main logic is - aside from non-solid (which is a transparent pixel), all the main functions are shades of gray; and all possible shades are covered. Thus, colored pixels become Type 1. However, this can certianly be changed.

10) So type 1 behaves exactly like type 4, except that the one-way option is automatically enabled? If yes, then why is the following procedure impossible: Create your VGASPEC using type 4 pixels, load it into the editor and enable one-way by hand. Then, as the one-way-areas can have arbitrary sizes now in V2.00, select precisely the required pixels for the one-way area.

Firstly - a VGASPEC may well have both one-way areas and steel. Of course, this could still be done manually with steel areas (or by specifying the steel, but not the one-way pixels, on the mask). However - suppose the one-way area you want to create has rough edges with other terrain. Do you really want to sit there manually placing however many one-way areas it takes to neatly cover that, rather than just quickly marking it in the mask (with edges as rough as you like) and placing one large one-way wall over it?

So it's not that you can't do what you describe - it's just a lot less convenient. (One possible alternative is to make the "vgaspec" level out of multiple pieces, with some representing the one-way areas specifically, but this doesn't seem to offer any advantage over using the mask).

[Nepster]

Thanks for all the answers.

I don't see them ever being used together in a terrain piece, but it's easier to allow it than to not allow it. Pieces I could see Type 2 being used in would be, for example, the moss pieces in the Dirt set (that are often overlaid on top of steel as decoration, but are not intended to remove the steel). Since there might be valid uses where the steel should be cancelled - or perhaps usage of other pieces in such a way that steel should not be cancelled (grass on top of the steel, maybe?), this is why an option will also exist in the level format; but this option would be more limited, it would be either "use the properties (which may be mixed) from the mask" or "change all solid pixels to <insert any type here>".

If you really think, that adding more types in the mask makes it easier to use, then fine. The only thing to avoid is, that level designers accidently place type 2 pixels, when wanting type 4 pixels (or vice versa).
Apart from that, I am still not sure if I want to see a mixture of different mechanics regarding terrain overwriting steel.

Firstly - a VGASPEC may well have both one-way areas and steel. Of course, this could still be done manually with steel areas (or by specifying the steel, but not the one-way pixels, on the mask). However - suppose the one-way area you want to create has rough edges with other terrain. Do you really want to sit there manually placing however many one-way areas it takes to neatly cover that, rather than just quickly marking it in the mask (with edges as rough as you like) and placing one large one-way wall over it?

So it's not that you can't do what you describe - it's just a lot less convenient. (One possible alternative is to make the "vgaspec" level out of multiple pieces, with some representing the one-way areas specifically, but this doesn't seem to offer any advantage over using the mask).

Sorry for the steel part - I didn't mean to exclude type 3 pixels in my argument. Concerning the one-way area: If you want to implement them in the editor like the (non-Autosteel) steel area currently, then your argument makes sense. Somehow I thought you planned to implement it in some other way.