[SUG] Graphic set Tool and Graphic system

[mobius]

It'd be really nice to have a faster way to use the Graphic set tool. The main thing is once you have 20+ tiles or whatever ready to go in a folder you have to press ADD then IMPORT over and over which is super tedious. I'd like a way to select all the files you want and import them quickly.

Also; why is the CANCEL key selected by default on the import window? This makes it even slower.

oh yeah also: the Just like the NL player, and the Flexitool kit, it does not show up on your TAB MENU and you can not tab to it on Windows 7!!

----------

I don't remember how the voting went on the current graphic system, or if there was one. But I'd really like to know what benefit there is to the compiled system we're using? other than saving space; (which isn't a problem for most people now-a-days, I highly suspect) it's FAR easier to have loose files [e.g. Lix's and Lemmini's system]. You can edit files so much easier and takes far less time. Also; would mean not having to have a "graphic set tool" or any tool at all!

I understand converting to a different system is not an easy thing, but I would vote to do so in the future if such a decision is ever made.

[namida]

A different system (similar to Lix's system) is planned for the future. Indeed, some non-public experimental versions already use it, but I don't feel it's ready to become public for a while yet.

[Nepster]

oh yeah also: the Just like the NL player, and the Flexitool kit, it does not show up on your TAB MENU and you can not tab to it on Windows 7!!

I am on Windows 7, too. And all of them appear correctly in my tab menu and can be selected via alt+tab. So I assume that some of configurations are problematic, which makes it nearly impossible to solve your problem (at least without further info).

Indeed, some non-public experimental versions already use it, but I don't feel it's ready to become public for a while yet.

What exactly are the problems that make the experimental version "not ready to become public"?

[namida]

What exactly are the problems that make the experimental version "not ready to become public"?

The biggest thing would be that it currently has an ugly mixture of relying partly on NXPs, and partly on external files. I don't want to be releasing versions that are in an inbetween state between old and new formats for content. Formats that can stand alone and don't really affect how content is distributed can be integrated now (as was the case with moving from LRB to NXRP files already). In particular, the NXLV format still needs work; and the new graphic set format will be a huge hassle to use in conjunction with LVL format levels.

Then, given the intention to move away from NXPs in favor of folder structures, this also means there's a need for overhauling so that the game doesn't rely on the "load one pack; restart if you want to play a different pack" model. Which in turn needs new (or at least significantly changed) menus etc to support this.

In the time between 1.43n-F and 1.47n, we saw that some users increasingly developed content exclusively for the experimentals. In this case, it wasn't a huge problem, as very few details of the formats changed between experimentals and stable - generally, anything made for the exp version, when the stable release came at most it would need re-testing and some replay fixes. This may very well not be the case when entire new formats are being developed, and the result is going to be one huge mess if that scenario repeats itself in regards to the new formats, which is why I don't want to be releasing them even as experimentals.

[IchoTolot]

I would also be for namida's way here.

Take all the time needed to get everything right. When the format changes we cannot risk splitting up content + relying on not 100% finished code. Let's rather stay longer at the old working format until the new one is 100% ready to go with everything that comes with it.

[mobius]

I would also be for namida's way here.

Take all the time needed to get everything right. When the format changes we cannot risk splitting up content + relying on not 100% finished code. Let's rather stay longer at the old working format until the new one is 100% ready to go with everything that comes with it.

Yes, I agree as well. The reason I initially made this complain (which I crossed out) was I think I remembered wrong that he put up a poll earlier to see what people wanted and they voted to go with the compiled system.

@namida; does this mean you're not planning on working on the Graphic set tool anymore? I guess it would be obsolete if the loose file system is used but there are some purposes it serves that, how would they be handled in the loose file system?
Choosing the color of builder bricks and pseudo random animation options for example?

[Nepster]

In particular, the NXLV format still needs work;

What is missing there? As far as I can tell from the file parser, all properties of objects, terrain pieces and the level itself can be set in the current NXLV format.

...and the new graphic set format will be a huge hassle to use in conjunction with LVL format levels.

Are there further problems apart from having to translate the old piece names into the new ones? And I thought this problem is solved via the translation files .nxtt in the folder styles/translation?

Then, given the intention to move away from NXPs in favor of folder structures, this also means there's a need for overhauling so that the game doesn't rely on the "load one pack; restart if you want to play a different pack" model. Which in turn needs new (or at least significantly changed) menus etc to support this.

Isn't this a completely independant issue from any file format change? While I agree that all file format changes should be made in one go, such new ways in accessing levels and level packs shouldn't create any compatibility problems.
With the new file format, NeoLemmix could still read one pack file and load the pack levels from different files. This doesn't require implementing a way to change packs.
On the other hand it should even be possible to implement new menus and moving between level packs with the current file format.

In the time between 1.43n-F and 1.47n, we saw that some users increasingly developed content exclusively for the experimentals. In this case, it wasn't a huge problem, as very few details of the formats changed between experimentals and stable - generally, anything made for the exp version, when the stable release came at most it would need re-testing and some replay fixes. This may very well not be the case when entire new formats are being developed, and the result is going to be one huge mess if that scenario repeats itself in regards to the new formats, which is why I don't want to be releasing them even as experimentals.

I agree, but I got the impression that the current experimental new-file-formats version already works pretty well. Granted, it hasn't yet the new level pack format, but apart from that...