2.00 Core Player with level pack files, or keep the "one EXE = whole pack" model?

[namida]

They'll still be tied to individual games / packs. That won't change.

The specifics of how things will be implemented (eg. menus) is still to be decided on. The main points come first, then the final details can be decided on later. At the moment, the only coding I've done towards this is some of the very core stuff - reading of files, etc. Not a single part of the menus / interface has been coded yet.

[bsmith]

I can support option 2 or 3 for the new editor.  Right now I am leaning toward option 2.  I have absolutely no problem for the 2.0 editor being just for NeoLemmix levels.

My biggest concern about option 3 is how all the metadata would be managed in a fullscreen mode.  (I assume that NeoLemmix 2.0 will be fullscreen like its predecessors.)  Right now I let the Inspector, Skillset, and Level Properties windows float off to the right of the main editor window so I can have a full height view of the level I am working on and still be able to see critical metadata simultaneously.

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.  '.dat' and '.lvl' are used by so many different programs now - enough that I don't want to make a file association for those (unless it is something like a generic text editor).

[namida]

(I assume that NeoLemmix 2.0 will be fullscreen like its predecessors.)

While the option for full-screen will be there, supporting a Windowed mode is definitely intended.

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.

Yes, I'm strongly considering using more NeoLemmix-specific extensions. I haven't made any decisions about what these might be yet, though - it depends on the overall architecture of files. I would also avoid anything that conveys a general Lemmings implication, in favor of one that specifically relates to NeoLemmix (for example, all of the extensions might start with ".nx"; eg "nxlv" for levels, "nxgs" for graphic set - these are just examples, not confirmed as to-be-used).

DAT compression algorithm is almost certianly going to become a thing of the past; most likely I'll either abandon compression altogether or use ZLib. It'll remain able to import old DAT-compressed files, though, for obvious reasons. While in existing versions, the code to support DAT is already there (and easier to work with), if rewriting the majority of the code, there's little advantage to be gained from using it, especially with it becoming increasingly ineffective with higher-bit-depth graphics; I can only assume the effect would be even more pronounced when higher-resolution graphics are also supported. At this point, there's little reason to continue using it for other formats where it does remain fairly effective (eg. levels) if an alternative such as ZLib, which functions better for the graphics, still functions very well for these other formats too.

[ccexplore]

If you do decide to support file association, I suggest using a more distinct suffix for level packs, like '.leml' (lemmings level) or '.lemp' (lemmings pack), rather than the current '.dat' and '.lvl' suffix.  '.dat' and '.lvl' are used by so many different programs now - enough that I don't want to make a file association for those (unless it is something like a generic text editor).

We can potentially make it user configurable which extensions to do associations for.  And we most certainly should warn the user first if it detects there are existing associations to other programs since we don't want to silently do anything that may be overwriting pre-existing user choices.  I get your point, but at the same time, I actually think most users probably won't have pre-existing associations for those extensions precisely since they are too generic.  When those extensions are associated to NeoLemmix, it may be slightly misleading that it would look like all DAT and LVL files can be opened by NeoLemmix when it isn't actually the case, but I think most users won't be intentionally trying to open random DAT/LVL files other than ones that are explicitly levelsets they downloaded, so I don't see too much of a problem for the user.

All that being said, if we are considering totally new file formats, then yeah, they should get their own NeoLemmix-specific extensions and not reuse the rather generic DAT and LVL.

[namida]

Most likely, the formats are going to be revised - but files in old formats will be importable (at least as far back as what works well with current NeoLemmix versions - ie: variable-size level files (or 10KB level files that include a graphic set name rather than just a number), single-file graphic sets, all variations of VGASPECs, etc). Rather than have somewhat different setups for various types of files, the formats are going to be more similar to each other - of course a graphic set and a level are going to have differences in the exact data, but the underlying structure of the file will be similar; enough so that (for those who understand what this means) rather than implement seperate classes / functions for loading seperate types of files, they can all be derived from a common base class which would do virtually all of the work that isn't data-type-specific (eg: the specific graphic set class would be responsible for interpreting the graphic and metadata of an object, but the base class would be able to pull out the data of individual objects, using exactly the same code it'd use to pull out the data of, say, the data of an individual talisman in the talisman file).

[namida]

Seems opinions on the editor / player division (or lack thereof) is also close to unanimous. So, it looks like there'll be a player, and a seperate editor suite (which will include level editor, graphic set editor, pack editor, etc all in one app). I would imagine for the most part this would come down to four sections - a level editor, a graphic set editor, a system graphics editor, and a pack editor; with most other things being integrated into one of those (eg. talismans would just be part of the pack editor).

We're still a long way away from that existing, and thus from knowing exactly how it'll be set up, though.

[NaOH]

Okay well. I think it's pretty well agreed that switching to a core player which loads data files (rather than an EXE per game) is the preferred option.

I'm a little late seeing this thread, but I just wanted to say that I approve of bundling the pack into a standalone executable. It was very convenient that I could be sent a level pack in an engine I don't have installed and I wouldn't need to download anything else to play the pack.

[namida]

That too was one of my thoughts behind keeping it that way for a long time (originally, this was just how Lemmix was set up). However, it came up from time to time that a core player should exist; and when I put the poll out there, results were almost completely unanimous (might've even been 100%).

With wanting more control over the configuration (eg. custom hotkeys, customizable skillpanel, etc), having to reconfigure them for each seperate game would be a hassle - it's not so bad when there's only 4 or 5 options, but when there's heaps of them...

Setup should still be (aside from customizing your configuration, if one wishes not to use the default options) very simple; in particular, it won't have the messiness that the setup of (Super)Lemmini or the traditional Lemmix editor require. It'll be more akin to Lix in this regard; just unzip, optionally configure hotkeys / etc how you like them, and play.