2.00 *New* terrain/objects-related discussion topic

[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.