Recently we had a discussion on the climber mechanics for V2.00 with respect to low terrain. Regardless what the rule is, it should be applied consistently. However in NeoLemmix V1.35C this is not the case!
If the wall is at least 8 pixels high, a lemming might climb it, even when there is terrain among the lowest 6 pixels. But if the wall is precisely 7 pixels high, he turns around ! The reason seems to be some too rigid terrain checks for hoisters.
Example level attached.

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

Quote

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?

Aside from the fact that this is not the issue of this particular topic (which is about the format of a single tile), 

Ok, then could you please explain what this poll is about? I thought namida wanted the users' opinion on whether to have
- single files = binary style files containing all terrain pieces of a single style
or
- collection of files = each style has one folder, where terrain pieces are stored as a bunch of .png/.gif/.bmp/whatever (and nothing in binary format).

Quote

<stuff about addons to tilesets>

You raise a good point here - and while I don't see it as nessecerially a definitive plus point for the folder scheme, one thing I do see here - is that there should probably be a way to "link" small addon sets to a default main set. Perhaps if combined with some naming guidelines to avoid conflicts (perhaps something along the lines of addon sets should contain the author's name (eg. "Nepster_Purple") while standalone sets should contain some kind of reference to their origin (eg: "LPII_Tree", not just "Tree"))... yeah okay, perhaps such a system could work. I guess it's time to throw away most of the graphic set code I've already written, then (at least hte code for individual pieces can remain)...

You are talking about a folder called "Nepster_Purple" containing several .png/... terrain pieces and not about one binary file "Nepster_Purple", correct?

Let me first give some advantages of "collection of files & adding single terrain pieces":
- If I create a completely new style, then this is a huge project and I would be very willing to use special tools to compress this into a useable format. For single terrain pieces, that I need for one level and that might have potential use for other levels, this is way too much work. Simply putting it in some folder is much faster and easier. (Btw. this is precisely the reason why I haven't created any terrain pieces yet.)
- Using a collection of files, one can easily distinguish between current and old versions of one style (at least if the difference lies in addition of further terrain pieces; telling apart changes of images themselves is hard in any case). Telling apart - likely identically named - binary files is much harder.
- On a slightly different note: Assume the editor is telling me that purple_Nepster_SingleCell is missing. With a collection of files I can easily check whether a downloaded style folder contains this piece or not. With binary files, I have to load it into the editor and try loading the level until I know.

I've already mentioned several times that one potential problem is people ending up with mixed versions of a graphic set (ie: some pieces not up to date, some that are), or an incomplete version of it;

See my points 1a) and 1b) here and your answer to it. Again if an error message says that purple_Nepster_SingleCell is missing, then this file is much easier to find in a collection of files instead of compressed binary ones. And with your strict naming rules for additional terrain pieces, merging style folders will be fast and easy compared to merging binary style files.
For arguments that binary style files have the same potential problem, see the rest of my post.

...and if multiple people are adding graphics to a single set, without it being a proper coordinated effort, this has huge potential to cause mess.

Much, much more so if they are adding to binary style files. A collection of files has the advantage that names of terrain pieces are very likely unique; in binaries everone will start with adding terrain piece "29" to the Purple style, which is guaranteed to create a huge mess.

Don't add to other ones (unless they're your own, or it's a widely-agreed change); create a new graphic set for your new pieces and use the two in combination.

OK, let's see what happens then: I create a new style Purple_Nepster_Addition containing exactly two terrain pieces. Then so does e.g. IchoTolot and GigaLems and we have suddenly four different styles one can load, each called Purple and most of them containing only one or two terrain pieces.
Next suppose I create a level using the traditional purple style and all three additions. Then I can either
- ship it with all three additional style files: But players will never know whether the IchoTolot and GigaLem ones are the current version (unlikely) or something very old (likely), so they cannot simply copy them into his folder.
- or rip IchoTolot's and GigaLem's style files and copy these pieces into my style addition: But even assuming other are fine with plagiarism of their terrain pieces, there will be a huge overlap between style files soon and why would we want this?
A few weeks later I require another terrain piece for Purple. The question is now: Do I create a new style file Purple_Nepster_Addition_2 or do I add the new pieces to Purple_Nepster_Addition? The first one has the same problems as with additions from other people, the second one has the problem to distinguish between current and old versions.

Putting all my additional terrain pieces (even for different style sets) into one Nepster_Addition is creating additional problems as well: First of all I do want to browse all purple style pieces in the same folder, not having to switch to other folders and not having to skip dozens of completely irrelevant terrain pieces for other styles. Secondly I want that other people are aware of my additional pieces and use them in their levels if that helps them. If I only have a single binary Nepster_Addition file, then they have to load it, go through all terrain pieces to see whether I have additional purple pieces or not. It is much better if they are already loaded automatically in the purple style, or at least collected in one Purple_Addition folder.

Apart from all of that, I do not see a difference between a new binary style file Purple_Nepster_Addition containing exactly one terrain piece and adding the terrain piece itself without all the style fluff around it. Well, except that creating a new binary style file is more work...

With a binary file, it's much more clear that such a method won't hold up for very long, and that making use of the multiple-sets-in-a-level feature is more effective.

Not sure what you are trying to tell me here.

Summary: If I only wanted to create completely new styles, then the current system would be fine for me. But making small additions to existing style sets is precisely the big advantage of a collection of files.
Regardless of our decision here, all additions to styles have to be collected and be available at one single location (i.e.not only posted somewhere on this forum). Otherwise we get compatibility issues.

PS: Sorry for turning this into a discussion yet again .

It just ran a script over the community pack, and not taking into account eraser pieces, 163/240 levels actually use tiles/objects from at least 2 different styles. A lot more often than it might appear on first glance. I guess the usage is more subtle, and when used, it's done in such a way that the tiles fit well and look nice. I believe often it's also objects being borrowed, as you don't always have equivalents in all tilesets.
Mixing tilesets is desired (see Epic tilesets for Lemmini/Lemmix), and excessively used in Lix.

Interesting; when I went through these levels per hand, I noticed only about 30 levels really using different tiles and a few more for decoration. Could you please run the script again ignoring objects (e.g. almost all levels with water and many levels with traps are counted, because those objects are mostly concentrated in one or two styles in Lix).

Yet another way to look at this is to consider a very low overhang, and consider lowering the top of the wall until it is short enough to become a walkable step (where the lemming can just hoist itself up the step as a walker--more accurately a "jump")...

Good argument.

To be somewhat fair, I think I'm the only one who's been pointing out that the low overhang having an effect on the climber isn't necessarily that obvious.

And I agree that it is not obvious. And I seem to be the only one pointing out that low overhangs being ignored isn't obvious either (from a mechanical point of view).

Maybe a better gauge is to determine how many levels would be affected (both positively as well as negatively) by the change...

There will be quite a few negatively affected levels (e.g. regarding the brown stairs in the pillar style). Many of them don't require this climber mechanic, but it opens up more possibilities and alternative solutions.

...especially if we are talking about a v1.x update that are supposed to be more minor in nature.

Never realized that we were arguing about a V1.x update.