Alright, voting for the first round has finished. Sorry "The Sweltering Warehouse", but you're out of the contest! So, at this point IchoTolot is guaranteed a prize, but will the other prize go to DynaLem or mobius...? Let's find out!

Current version: 1.01

Download
Source Code (Delphi 7)

You can create a VGASPEC file with this too. Just create a graphic set with a single terrain piece (that being the level graphic) and no objects, and save it with a filename that starts with "x_". If you add a second terrain piece, any solid pixel in it will become steel (if the level its used in has autosteel enabled). Likewise, a third piece if present, any solid pixel will act the same as a regular terrain piece with the "One Way" option selected (it still pays attention to the One Way Invert flag as usual).

---

So, while I'd take it partly the lack of graphic set creation is simply due to lack of artistic talent (or at least, the perception of a lack of it) and/or willingness, I figure that making a better graphic set tool than LemSet is probably a worthwhile endeavour.

So my question is - how exactly should it look and function? Should it be integrated into NeoLemmix Editor, or a seperate program? (My preference is the latter, personally.)

I've been working on something, though it's still early days yet - at the moment this is practically just a mock-up (albeit designed in the Delphi IDE, so I can easily make it functional); the only thing that actually does anything so far is the "Black background" checkbox, which does more or less exactly what it says on the tin.

Any comments, suggestions, etc are welcome.

More likely than not, this tool will be made fully open-source as soon as it's complete, so if anyone wants to add support for other engines, they'll be able to do so.


For reference;
The File menu just contains your standard "New", "Load", "Save", "Exit" options.
The Tools menu will have, among other stuff, the "Import Cheapo style" option.

---

Up to date list of target import/outport formats - struck out ones have already been implemented (though a version with support implemented may not nessecerially have been released yet).

Target Import Formats
First version
> LemSet graphic set source "code"
> GSTool-specific INI / PNG source "code" (derivative of LemSet format)
> Cheapo Style Extractor output <removed in V0.99>
> DOS / Lemmix graphic sets
> NeoLemmix graphic sets
Eventual
> New NeoLemmix graphic set format
> VGASPEC files
> Lemmini graphic sets
> SuperLemmini graphic sets
> Cheapo graphic sets (directly from STY file)
May consider if enough interest
> WinLemm graphic sets
> LJLPM's Lemmings clone (subject to LJLPM being okay with this)

Target Export Formats
First Release
> Old-Format NeoLemmix Graphic Sets <removed in V1.01>
> LemSet graphic set source "code" <removed in V1.01>
> GSTool-specific INI / PNG source "code"
Eventual
> New NeoLemmix graphic set format
> SuperLemmini graphic sets
May consider if enough interest
> LJLPM's Lemmings clone (subject to LJLPM being okay with this)

Other Features
First Release
> Viewing all properties of pieces
> Editing all properties of pieces
> Adding and deleting pieces
> Viewing graphic set palette (still used for brick/minimap color and explosion particles even in RGB-based sets)
> Editing graphic set palette
> Viewing all frames of objects
> Adding and deleting frames from objects
> Importing individual frames from PNG files
> Exporting individual frames to PNG files
> Displaying trigger area on object image
> Reordering pieces
Eventual
> Importing individual frames from BMP / GIF files
> Exporting individual frames to BMP files
> Importing entire object graphics as a strip of frames in PNG format
> Importing entire object graphics as a strip of frames in BMP / GIF formats
> Exporting entire object graphics as a strip of frames in PNG format
> Exporting entire object graphics as a strip of frames in BMP format
> Support for storing trap/teleporter/etc sound effects in a graphic set
> Support for properly managing the sound effects stored in a graphic set
> More user-friendly and flexible managing of custom sound effects in a graphic set
May consider if enough interest
> feel free to leave suggestions!

Why no BMP in first release? Because I'd have to add a way to select transparent colors, as while BMP-with-transparency does exist, it's extremely obscure. PNG on the other hand supports it as standard. Also, because supporting two formats is trickier than supporting one, so my main goal is to just have it working first.

Why no export to GIF? Because GIF is limited to 256 colors, and it's very plausible some graphic sets may use more than this, especially with 24-bit color ranges. Why support importing it then? Because Lemmini graphic sets use it and I plan to support importing them, and it's very little extra work to add importing other images from it. Besides, even though it's never used (and as such probably won't be supported for it in the first release), technically LemSet does support GIF files too.

Uploaded LemSet V13.3. This will be the last version that intentionally maintains any kind of support for traditional Lemmix; beyond this version I make zero guarantees of LemSet output being compatible with traditional Lemmix or DOS. The only new feature in this update is that object animation frames can now be horizontal instead of vertical in the source BMP (or PNG) file.

For this reason, this version will be kept available even when new versions are released.

With that being said, one of the big reasons for this is that I'm going to make an entirely new graphic set tool, which will be more user-friendly than LemSet. Therefore, more so than "a new LemSet version", it'll be "an entirely new graphic set tool". I'll probably do something similar for MAIN.DAT as well, although LemMain isn't quite as difficult to use as LemSet.

Qualifying levels are:

Wicked 03 "This Corrosion"
Havoc 05 "There`s madness in the method"

(Aww. I was hoping to see Crazy 7 go a bit further than that... but in general this was a very hard round to pick for me!)

Next set is up.

Between that seeming more logical, and the poll results, I think it's clear what option to go with.

Please note that as of the next revision, due to these symmetry fixes, any levels involving bombers should probably be re-tested. Additionally, there was also a slight symmetry fix relating to blocker areas, so levels that rely on blockers very precisely should probably also be re-tested.

They've all been fixed, as far as I'm aware (ie: unless some have slipped under the radar).

I'd believe the DOS behaviour would be the same. The bomber mask itself is asymmetrical there, but the shape of the mask itself has been fixed in NeoLemmix for a long time. However, as it's of an even width, it can't perfectly center on the lemming's position, and that's what's causing this issue.

EDIT: Yes, DOS behaviour in terms of positioning is exactly the same as NeoLemmix is currently. Tested with a similar setup in the pillar graphic set; block bombed on either side of a vertical wood piece. On the right it bombed right through, on the left a one-pixel wall remained.

So, I've discovered a bug in NeoLemmix while playing through GigaLems. The easiest way to see this bug is to create a level in the martian style with a piece of the red railing sticking up, and try bombing from right next to it on both sides. On the right, they'll bomb right through, while on the left, one pixel will be left.

There are two possible approaches to dealing with this.

Option A) Moving the bomber mask by one pixel depending on the lemming's facing direction (in this case, it would be moved one pixel right if the lemming is facing right)
The advantage of this option is that it should break far less solutions than the other option, and will also be easier to implement. The disadvantage is that this is still somewhat asymmetrical, albeit with more consistent logic to it.

Option B) Adjust the bomber mask, making it one pixel thicker on the right (or one pixel thinner on the left).
The advantage of this option is that it gives symmetrical results in all cases. However, it's more likely to break levels, too, and implementing it will be trickier, particularly in the case of making the mask thicker (as this will likely require some modifications to MAIN.DAT's format, thus requiring all MAIN.DAT files to be rebuilt). Of the two sub-options, making it one pixel thicker on the right is less likely to break levels than making it thinner on the left.


I'm not entirely sure which option is best, so let's hear what people think. And please don't suggest "make it an option"; that isn't going to happen as I definitely don't want an optional mechanics switch over something that subtle.

Further testing on the bomber asymmetry shows that it only seems to happen when a *climber* is bombed. Or at any rate, it doesn't happen for a walker. I'll test other skills too, now...

Further testing again suggests it happens when climbing, as well as any state when an "Oh no" doesn't happen (but apart from climbing, it seems to never occur in states where oh no's do happen).

EDIT: Further testing *again* suggests the bomber mask, not the placement of the explosion, may be the issue, as it actually looks like I was wrong in comparing the lemming's states on a constant position; what I should've been testing is the results from opposite sides of an obstacle.

Do you mean while you're dragging them, or after you drop them? If it's the latter, most likely that's just an optical illusion due to the different brightness of surrounding terrain/objects/etc and viewing angle. If it's while you're dragging and dropping them, minor graphical oddities during that seem to be inevitable. (For the best example, try dragging a steel area that's placed behind some terrain...) Anyway, if they cover the correct area, I wouldn't consider it a critical matter.

We don't really have hard-and-fast rules here. Just use common sense and you'll be fine; we certianly aren't going to warn / ban you for something as minor as creating two topics.

Latest update to the NeoLemmix Editor should fix that issue you're having with non-solid pixels being treated as solid (and some solid pixels being treated as non-solid). Let me know if there's any issues.

In terms of gameplay, my favorite out of the ones I've completed is Scalding 23. Scorching 13 is showing a lot of promise, but I still haven't beaten it yet so can't say for sure.

EDIT: At this point, I'd say Scalding 23 is still my favorite, with Scorching 13 as a close second.
(Just to be clear, I'm referring to the fixed version here, so by Scalding 23 I mean "Bye Bye Baby Balloon")

Appearance-wise, it's a bit harder to pick. I might have to get back to you on that one.

Editor V1.30n-C
---------------
> Fixed the reintroduced bug of solid black being treated as transparent.
> Fixed transparency issues in some Lemmini graphic sets.

Usual links. There's no changes to any of the INI files, so if you've made custom changes to those, just overwrite the EXE (without replacing any other files) and your changes will be maintained.

It may look cool, but it's not an accurate representation of how they will appear in game. I'll try to get a fixed version out within 24 hours, as that's quite major IMO.

EDIT: Found and fixed the cause of it already. Before I release the update, I'm going to look at the Lemmini glitch which is basically the reverse of this (pixels being treated as solid when they shouldn't be in some custom styles).

While I'm at it - has anyone encountered problems with the "classic delete" feature? I haven't myself (and I have been using the editor a bit recently), but since I often miss things, let me know ASAP if you have found any and I'll try to fix them at the same time.

Damn. I remember specifically having that on my list of things to test (due to the new one-way-wall handling), and I must've forgotten. Thanks.