NeoLemmix (Player: V1.26n-C | Editor: V1.26n-B)

[namida]

Ah, fair enough. Actually, your replay never gets around to assigning a second builder on V1.03n, so I couldn't've seen it even if I had realised what you meant. Still, I don't think that's anything unique to NeoLemmix, apart from the steel mechanics making it a bit easier to pull off in some cases.

Anyway, here's something I'm not sure about. Make sure you use V1.03n to check this, otherwise it won't work. The attached replay shows off non-rectangular steel working just fine (in this case I just used a square rotated 45 degrees, but you could make any arbitrary shape; you could have a spiral-shaped steel piece if you wanted). But, the way the basher handles when he meets it... I'm not sure if I want to do something about this maybe... (Just for reference, all it takes is *one* pixel off the edge erased, and he'll hit steel and turn around like normal.) Also, this is a pretty neat level in itself too. It is actually possible (but quite hard) to solve without grabbing the extra builders.

[namida]

Two more fixes to expect in V1.04n (haven't released it yet; don't freak out if you can't find it ).

> We all know the classic "nuke glitch", but Lemmix also had another, far more minor nuke glitch which I believe (but could be wrong) wasn't present in the originals - if the timer runs out after the lemmings start exploding from the nuke but before they finish, the level won't cut off and the timer wraps around into negatives. This is fixed for V1.04n.

> Objects with Y coordinates less than zero now work properly.

Thanks to DynaLem for these; I was actually aware of both (the former actually happens in a few of the official LPII (non-NeoLemmix version) replays; while I ran into the latter while trying to improve the appearance of Medi 26 "Overheat" for the NeoLemmix version) but had completely forgotten about fixing them, he reminded me.



And another new feature, this is one I discussed earlier as a low-priority idea but didn't implement until now:

> You can now specifically set the music for your level. This uses the high byte of the graphic set number.

• 00 - Uses the default system. (IE: Random music on CustLemmix, sequential on anything else, and special music for gimmick and frenzy levels)
• 01 to FC - Uses the respective track number. (Warning: At the moment, this causes crashes if the respective track doesn't exist in the player.)
• FD - Uses the default system, but doesn't play special music on gimmick and frenzy levels.
• FE - Frenzy music, even if it's not a frenzy level.
• FF - Gimmick music, even if it's not a gimmick level.

I'll probably add support to CustLemmix for external music files at some point, too.




EDIT: One more, again this is something I've discussed before.

> When using CustLemmix, replay files will be saved with a filename based on the level's title, not its rank and position. (This feature will also at some point be backported to non-neo CustLemmix.)

[namida]

Version 1.04n is here.

Code: [Select]

*  Bashers now perform steel / oneway checks on two pixels (the
   new one is one pixel below the old one).
*  The minor nuke glitch (where, if the nuke has been used but
   some lemmings are still exploding, the timer wraps around into
   negatives instead of running out and ending the level) has been
   fixed.
*  Objects with Y coordinates less than zero now function properly.
*  Music can be fixed. This is done using the high byte of the
   graphic set (similar to how steel settings are on the extended
   graphic set). The corresponding track number will be played.
   The following have special effects:
     00 - Player's default, unless the level has a gimmick
     FD - Player's default, even on gimmick levels
     FE - Frenzy music
     FF - Gimmick music
*  In CustLemmix, replay filenames are based on the level's name,
   not its position. (This does not affect non-CustLemmix players.)
All players can be downloaded here. This time, as well as individual files, I also put a ZIP containing the whole lot of them (including the Lemmings Plus ones).
https://www.mediafire.com/folder/xlxaab8awc3bp/V1.04n



You may have run into a bug on custom styles (or the test style I've posted several times in different versions) where NeoLemmix appears to be regarding pieces of terrain as steel when it shouldn't. You may also notice it wasn't listed as fixed in the above changelog. That's because this was actually a LemSet bug, not a NeoLemmix one; LemSet was marking pieces as steel when it shouldn't (specifically, after the first piece that *should* be marked steel, all remaining pieces it would mark as steel). A fixed version of LemSet has also been uploaded.

[namida]

I have another project connected to NeoLemmix that I might reveal now... I have no idea if I'll actually finish it, or if at some point I'm just going to decide it's not worth the effort, though. I'm working on my own (proper, not text-based) level editor; more a modern remake of LemEdit than a truly new design. For now, just a level editor (but with full support for NeoLemmix features), at a later point I might integrate LemSet-type features into it too.

I'm writing it in DBPro rather than QB64, as I've found QB64's graphics support to be quite unreliable and buggy. I have to say though, trying to use any BASIC variant after getting used to Delphi from all the work I've been doing on NeoLemmix lately... it feels really weird and a lot of things are annoying me now that, initially, I got annoyed that Delphi *wasn't* that way (for example; at first I found it annoying that you have to pre-define variables in Delphi, but now I'm actually finding that to be a really useful feature for, say, hunting down typos that are causing bugs). This does mean I have to redo the routines from scratch, sadly. I've already implemented reading the Ground file and decompressing (but not yet reading the decompressed contents of) DAT files, working on loading the graphics from it at the moment.

The main reason for doing this is that, although LemEdit is useable with 32 color graphic sets, it's not exactly the cleanest, and it in effect puts extra limitations on since at least some of the fixed colors need to be duplicated into the custom ones or else it becomes not so useable due to graphic glitches. As you already know, other level editors, I'm either not too fond of (Lemmix editor), or they're primarily aimed at Lemmini and a bit awkward to use with DOS (jLevelBuilder), or they just plain don't work on my system (Lix). Not to mention even jLevelBuilder, probably the best alternative, doesn't support NeoLemmix features - the only editor that does is QuikEdit, and while it's better than a hex editor, it's not better by much, it pretty much only exists because no other editor can edit those specific things. So I'm writing a new editor, appropriately titled "NeoLemEdit" (obvious combination of "NeoLemmix" and "LemEdit"), to provide a full-featured (at least in terms of levels) editor with full support for NeoLemmix additions. (Adding Lemmini support at some point is not a priority, but is something I am willing to consider once the basic features for NeoLemmix and traditional DOS/Lemmix are in place.)

Some of the coders here would honestly facepalm at some of the mistakes I managed to make (and of course, subsequently fix) so far... the most amusing one, and this actually had me confused for AGES as to why it was loading incorrect colors in some cases but not others - I had been loading palettes as "red, blue, green" rather than "red, green, blue". *facepalm*

EDIT: It now can completely load a graphic set into memory. Next up is to write a function to quickly take care of loading both the GROUND and VGAGR files for a specific set number (currently, I have to first call the function to load the Ground file - that's all done in one function - then one to load the VGAGR to memory, two to decompress it (one per section), and one to build the images out of it - the one function here takes care of both terrain and objects, obviously via  other more-specialised functions rather than windy code.) Then it's saving and loading level data, and from there, the next step is actually building the editor. For now, I'm only going to worry about saving to LVLs, not to DATs (although I will add DAT saving at some point in the future), though I may as well add the functionality for loading from DATs since if it already has both decompressing DAT files (nessecary for loading graphic sets) and loading LVL files, it's a VERY short jump to add loading levels from DAT files.

I've got another, much bigger announcement coming up soon too, so stay tuned. Some of you might already know / be able to guess what it is.

[namida]

Notice anything new? =D

[Minim]

Oh yes, It took me about 2 minutes to work out what it is. The time limit now has seconds added.

I voted for the Suicide button option. Maybe that's the best idea to stop players backrouting people's levels? I don't know, but I think the idea of a suicide button is rather cool. You can be creative with it by making the button as long or as tall as you like, and rotate the position to direct the lemmings towards or away from it.

[namida]

^ That's actually one of the reasons I haven't done that one yet; because I don't really want to if it's only ever going to be used as a cheap and tacky way to fix backroutes. To some degree, the one-way fields ended up being that way in LPII, although at least some levels made interesting use of them.

Anyway, a suggestion I received via PM was to drop the % saved in favor of a plain number of lemmings. I don't actually like the idea of getting rid of percentages altogether, but I'm thinking about maybe adding an option to let the player choose which one they prefer; that would be fine with me. Obviously, this would nessecitate some fixes to goal calculation - currently it actually runs on the exact % value, not "works on number of lemmings but displays it as a %". Which has no impact on levels with <= 100 lemmings, but it does if there's more. For example, if the level has 200 lemmings, both 50 and 51 lemmings saved would report at 25%; in fact, even if the level sets the goal at 51 lemmings, saving 50 lemmings would be counted as a pass because it's still 25%. So I'd have to fix this. Which to be fair, I probably should anyway.

(EDIT: Option added, glitch fixed.)

[Tsyu]

I noticed a few bugs that you should try fixing:

• Explosion particles don't disappear until the screen is scrolled. (This bug exists in the original Lemmix.)
• In special-graphics levels like Fun 22, new builder steps are black for about a half second before changing to their proper color. (This bug also exists in the original Lemmix.)
• The "file not found" error message is not in English. (This bug also exists in the original Lemmix.)
• In your L1, ONML, Holiday '94, and Xmas '91/'92 players, the first level of each rating plays the first music track. For the first three of these players, this is incorrect. The track that plays in the first level of a rating should be what would play if the level were part of the previous rating. For example, Fun 30 plays track 13, so Tricky 1 should play track 14 (not 1), Tricky 2 should play track 15 (not 2), Tricky 3 should play track 16 (not 3), and so on.

[namida]

1) Going to try and fix that for the next version. (EDIT: Done.)
2) I have one idea for how I might be able to fix this, not 100% sure how well it'll work though. Probably won't be in the next version.
3) Ideally, that should never show up. But yeah you're right, I'll translate these at some point. Not guaranteeing next version or anything though.
4) This is something that varies between versions. DOS simply advances to the next music every time you complete a level; if you quit the game and start again, it restarts from the first one. Windows is the same, but preserves it between restarts. Sega Master System is the closest to how I've implemented it. Though; I believe that shouldn't happen in the X91/92 player?

[namida]

Two things you might be able to notice here... one of them, as mentioned, is *optional* and can be configured from the INI.

[Tsyu]

4) This is something that varies between versions. DOS simply advances to the next music every time you complete a level; if you quit the game and start again, it restarts from the first one. Windows is the same, but preserves it between restarts. Sega Master System is the closest to how I've implemented it. Though; I believe that shouldn't happen in the X91/92 player?

Most major versions of Lemmings (such as the Amiga and Macintosh versions) use the system that I suggested, although not all of them use the same music order. If you would rather keep it the way it is, though, that's fine with me.

Still, you might want to consider changing it in Holiday '94. The first and last levels of a ranking in that player have the same music, resulting in the same music playing in two consecutive levels.

[namida]

Out of the poll options, the low-gravity zones have been implemented for the next version. Lemmings, whether fallers or floaters, fall slower than normal in these zones. While in them, their "distance fallen" decreases rather than increases (though not as quickly as it would increase by falling the same distance) - can't decrease below zero, by the way - and if they're within the zone when they land (as opposed to simply passing through it during the fall), they won't splat no matter what. There's still a few things to do with them that I need to fix up though - currently, if a lemming ends up in one early enough in their fall, they won't pull out their parachute; and I'm pretty sure it's going to have some weird results if mixed with the exhaustion gimmick too.

[Wafflem]

What happens if the no-gravity gimmick is in play and a lemming touches the low-gravity zone?

Also, how big are the low-gravity zones?

[namida]

It has no effect when the No Gravity gimmick is in play, because it only affects Fallers and Floaters; which are two types of lemmings that never occur under No Gravity.

And, like any object, the size is whatever the style says it is. They're no different to any other objects in this regard - most aren't, the only custom ones that have any special effects relating to the size of the trigger area are the receivers and the instant lemmings, both of which ignore the size of their triggers (they use the trigger area coordinates, but not the sizes). Everything else uses them (even the pickup skills - they might appear to use something else since they trigger when the lemming walks underneath them, but that's actually just a result of exactly what position/dimensions I set for their object in that style).



NeoLemEdit is also coming along fairly well. It's now down to making the interface and actually *editing* the levels; pretty much all the nessecary behind-the-scenes functionality is in place (the only things missing, as far as I can think of, are VGASPECs and saving to DAT files (but it can load from them)).

[namida]

Well. My attempt at rendering a level was... not exactly a success, but not a 100% failure either. Even if it's messed up in ways that are better explained by looking at the picture, the small segments DO have a pretty good resemblance to the actual level. (Yes, I know objects are missing - I haven't implemented drawing them when rendering the level yet. Terrain first, then I'll worry about them.)

EDIT: Second attempt. Looking better!

EDIT: Third attempt. Almost there!

EDIT: Sort of found the problem. I had the "No Overwrite" and "Upside Down" flags the wrong way around. Because I had them the wrong way when both saving *and* loading (and they were consistent with each other), the result of loading a LVL file then saving it again was identical to the input, thus, I didn't pick this up earlier. So that's corrected now and it's interpreting them correctly but... it's also interpreting "no overwrite" as "don't draw it at all". >_>