2.00 Right. Let's decide for once and for all on graphic set formats.

[namida]

Since some people simply won't drop the insistance of using their preferred format - let's try and get an accurate picture of how everyone in general feels.

The poll asks two questions - please choose the option that's most applicable to you. This topic is not for rants or debates about why it should be one way or the other - it's to find out which options people prefer, and how likely the options are to actually affect them. (Eg. If someone is never going to use a custom graphic set - even just using an already-made one for their own custom level - then it really doesn't affect them in any way what format the graphic sets are in.)

Remember that in the case of "multiple files" - we are talking at least two files per piece for objects (three if arbitrary triggers end up being allowed), and at least three per piece for terrain pieces - and that's in the case where only one resolution's image is supplied. This being an actual graphic, (for terrains) a physics mask, and a metainfo file (presumably as text).

[Simon]

If you discourage discussion, please don't bring claims like "this won't affect players who don't design", which I've attacked here; so far with no counter-argument to what I wrote.

Explanation of my vote for "collection, will design myself": I have 9-year-old tiles that can't be culled from Lix anymore, because levels depend on it. I have begun texturing and shading these, to bring them up to par. This isn't finished, but nonetheless on the to-do list. From what I've gathered about the planned NL2 design, the finished set is immediately usable as a 2x-scaled NL set, and can be reasonably downscaled to 1x pieces.

-- Simon

[namida]

No - that argument does not hold water. If the people designing graphic sets would prefer a directory / single files based format, then yes, not having one would be bad even for those who aren't making their own content. However, if the people designing the sets don't care, or prefer a single-file format, then not having a directory-based format has little if any negative impact (and perhaps even a positive impact, in the form of guaranteeing they have whole sets rather than fragmented parts of it, or a mix-and-match of up-to-date and outdated content within a set) on them.

That is why ultimately, what matters is the preferences of those who will actually design sets. And it must be taken into account even here - that this is at this point basically a question of "what should be the primary format", since I have already stated that a directory structure format will be supported, with support in it for all the same features that a native binary format would support, but just do not currently intend to make it the main or default format.

[Simon]

In this light, you're polling acceptance with the currently active userbase. It remains up for discussion which format will attract more future designers and contributions.

-- Simon

[Nepster]

Sorry, I miss the option "I prefer a collection of files. I am not likely to design graphic sets, but I am likely to add single terrain pieces to existing styles"?

[IchoTolot]

Darn!    I overread the "not" in the last option. Just count the single vote in the "I prefer a collection of files" to the other bunch

[geoo]

The poll question is quite misleading until you actually read the main post. There was discussion lately about whole graphics sets as binary blobs (and on first glance the poll sounds like it's referring to that), while actually it's referring to how objects/terrain are stored within a graphics set.

and at least three per piece for terrain pieces - and that's in the case where only one resolution's image is supplied.

Can you elaborate on this? I can only see the need for a single png for a terrain piece (which is, btw, exactly how lix terrain is done). Solidity can be inferred from the 1x resolution image (and if that it not provided, from a down scaled version of the 2x or whatever image), unless you deliberate want to allow graphic set designers to fool the player by providing invisible terrain/non-solid terrain. And there's no meta-info associated with a terrain piece (except for steel, which in lix is encoded as a pre-extension, e.g. steel.S.png).

Simon makes a valid point here, I'm happy to convert my Lix tile sets for NeoLemmix if people would want to use them, and if it doesn't take much effort. (Copying over my folders and changing the meta-data for objects is acceptable for me. Sending each of the 428 images through a converter tool is not. I'm also happy to turn the Pushover background graphics into NeoLemmix tilesets; those aren't in Lix because they are copyrighted.)

[namida]

The need for a solidity mask is not to allow fooling as such, but rather to clear up any questions of alpha regions, as well as allow a single piece to be a mix of steel and non-steel, or allow some regions that are one-way capable and others that are not. (The primary reasoning to do this being VGASPEC-style terrain pieces, but I'm sure given enough time some other uses for this will come up too.)

Indeed, you're right that no meta-info besides this mask (or at least some method of specifying steel / non-steel, which could be on a per-pixel basis or just for the whole piece) is needed; I was getting a bit confused between piece types when I wrote that. With that being said, using an alternative filename to designate it as steel is a horrible method IMO; the filename is to identify the piece, not to give info about its metadata. The fact that it's only one bit of information, which can only be "true" or "false", doesn't make this much better.

Sorry, I miss the option "I prefer a collection of files. I am not likely to design graphic sets, but I am likely to add single terrain pieces to existing styles"?

Firstly would be that I obviously can't account for every nuanced possibility in poll options. However, that aside, this kind of expectation - especially when mixing of multiple graphic sets in a single level is a planned feature - is actually a very big motivation to scrap the idea of having a folder tree at all. 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; 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. 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. 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.

[Simon]

The need for a solidity mask is not to allow fooling as such, but rather to clear up any questions of alpha regions, as well as allow a single piece to be a mix of steel and non-steel

I expect most tiles to be only diggable terrain and air. Make a good default rule on what becomes transparent, to make the region-setting file optional. (If the region file exists nonetheless, it overrides any default rule.)

using an alternative filename to designate it as steel is a horrible method IMO

It's a relic from when gadgets were not configurable by extra control files.

It omits the need for extra files when one char is enough metadata, and the gadget designer wants to apply the game's default rules for trigger area positioning.

one potential problem is people ending up with mixed versions of a graphic set (ie: some pieces not up to date, some that are),

Well yeah, a potential problem. Let's look at the obvious case study.

Mixed versions haven't been an issue in 9 years of Lix. Sometimes, when people don't update for a long time, the tree appears out of date when new levels expect extra tiles. This comes from human laziness to update, and is perfectly normal. In particular, this would occur both with all tiles in one blob, or with loose files. The solution is to download the current game version from the homepage.

We have observed a trend to refrain from functionally altering existing tiles. The recoloring I was talking about in my first reply here is a good example, it leaves all shapes 100 % intact. If you suddenly altered the physical shape of tiles that were released years ago, you'd break existing levels left and right, and people would hate you.

Adding pieces is perfectly fine. People with the old version would then encounter missing pieces upon playing new levels. The level browser mentions it, and prints the exact missing filenames to the logfile.

In this culture, if you can play a level at all, convention guarantees that you have the correct tiles.

If you don't consider this enough, because you'd like to guarantee it by design, then hashing the tiles is your friend -- in particular, hashing the physical properties per tile, not the visual design. That extra work is again comparable between one large blob, and many loose files. (Provided they're loaded from disk only once per program run, and then kept in memory. The blob would be more performant if you were to load from disk all the time afresh, which is in itself not performant.) So far, we haven't bothered hashing tiles.

-- Simon

[Nepster]

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 .

[namida]

The need for a solidity mask is not to allow fooling as such, but rather to clear up any questions of alpha regions, as well as allow a single piece to be a mix of steel and non-steel

I expect most tiles to be only diggable terrain and air. Make a good default rule on what becomes transparent, to make the region-setting file optional. (If the region file exists nonetheless, it overrides any default rule.)

This is a very reasonable way to handle things, especially for pieces that have a 1x resolution image. Questions could still arise of how to handle solidity in regards to semi-transparent pixels if no mask is provided, but then the same question could apply to auto-generating one when creating a graphic set if the user doesn't provide one explicitly.

Mixed versions haven't been an issue in 9 years of Lix. Sometimes, when people don't update for a long time, the tree appears out of date when new levels expect extra tiles. This comes from human laziness to update, and is perfectly normal. In particular, this would occur both with all tiles in one blob, or with loose files. The solution is to download the current game version from the homepage.

The difference is that NeoLemmix is not likely to include all available tiles by default, whereas (at least from these comments) I get the idea that Lix does. How much of an issue this might cause would remain to be seen.

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

[geoo]

The need for a solidity mask is not to allow fooling as such, but rather to clear up any questions of alpha regions, as well as allow a single piece to be a mix of steel and non-steel, or allow some regions that are one-way capable and others that are not. (The primary reasoning to do this being VGASPEC-style terrain pieces, but I'm sure given enough time some other uses for this will come up too.)

Ok, but if you support this but have a single file for each tile in your custom format, any tile set creators will have to create such a mask anyway before sending it through your converter, right? So I believe independent on whether you implement a tile as 2-3 files or a single file in your custom format, this approach will cause a lot of extra work to graphic set designers unless it's optional.
I don't see much of a point in having mixed steel/OWW/normal tiles, you could just split them up into two tiles. I can't think of any use case where splitting them up is inconvenient.
This whole approach just makes your life and everyone else's life harder.

Either way, please let me check if I'm correct here: One single file means the user creates a tile and a mask and then converts these and enters any meta-information via a GUI? While otherwise the user creates the same two image files and saves any meta-info (e.g. tile being steel, I'd be perfectly fine having that in a meta-info file rather than as part of the file name) in a meta-info file. If the mask is optional, in both cases you'd have to come up with code that determines a sensible default mask, which would be in the converter or in main NeoLemmix respectively. The converter saves no work for you, and it saves no work for the graphics set designer. On the contrary: The intrinsic need for entering values into the converter just makes batch conversion impossible, and each time you want to change the location of a trigger area while testing your tile set you have to run the converter again and enter everything instead of just changing the mask or the meta-info file. The only reason for the converter I can think of is your dogmatic love for having a single file for a tile.

Firstly would be that I obviously can't account for every nuanced possibility in poll options. However, that aside, this kind of expectation - especially when mixing of multiple graphic sets in a single level is a planned feature - is actually a very big motivation to scrap the idea of having a folder tree at all. 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; 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. 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. 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.

Aside from the fact that this is not the issue of this particular topic (which is about the format of a single tile), you basically want to limit the possibilities for collaboration because you think the users might be too dumb to coordinate, is that correct? In the process, you also make it hard/impossible to provide graphics of a different resolution to an existing tile set, or changing the graphics of a tile to make it look better without affecting the mask/functionality (the latter, btw, has happened a few times in Lix). With your approach you're discouraging people like Nepster from making minor tweaks or additions to tile sets, as I believe people will be less confident to distribute a new tile set that contains exactly two tiles rather than a patch that adds 2 tiles to an existing tile set.
At the same time, you intend to provide the graphic set designer with features (see e.g. above) that allow him to abuse and fool the player, but you're not concerned about that at all. I find this a bit inconsistent. With power comes responsibility, in either case.

In the end, to some extent how likely people messing up tile sets is, comes down to how you intend to do distribution. I'd assume you have a central place (probably the main NeoLemmix download) that comes with officially sanctioned tile sets. Anything that's up there cannot be changed anymore, only added to. Here, in itself, there's no difference between a file tree and a binary blob for graphics sets. A user will have to update either way to get new additions. So assuming there's a central source for tile sets, the only instance where your scenario can happen is with in-development tile sets. For those a file-tree eases the development process, and such tile sets only reach a few testers and not the whole community until they are finished, so even if they get their versions messed up (which in such a scenario could also happen, though to a lesser extent, with binary blobs) it's not such a big concern. And even in lieu of git, messing up can be avoided pretty consistently by just deleting the existing tile set folder and replacing it with the new version, rather than copying individual tiles all over the place.

Note: I wrote this post before the previous two posts appeared, I will read them and possibly adjust my post accordingly if some of my questions have already been answered there.

[Nepster]

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

<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?

[geoo]

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

Ok, as I said the poll is quite unclear, and now I'm not sure I actually understood it correctly.

The title of the poll seems to indicate that the question is whether a single graphics set is a single binary blob, or a folder containing many files. But then when reading the first post

Remember that in the case of "multiple files" - we are talking at least two files per piece for objects (three if arbitrary triggers end up being allowed), and at least three per piece for terrain pieces - and that's in the case where only one resolution's image is supplied. This being an actual graphic, (for terrains) a physics mask, and a metainfo file (presumably as text).

it seems to indicate that we're only discussing the format of individual tiles here, i.e. is a single tile 1 file, or up to 3 files? With the question whether tile sets should then be left as folders or whether these tiles should be compiled into a single blob (zipped or through yet another converter) left open. This is how I understood the poll. Either way, it doesn't affect my vote, but this is the context in which my posts in here are to be understood. In particular, now I don't know precisely how the proposed conversion process in case of a binary blob is supposed to work.