As another example, here's the INI file for the Psychedelic style (I also attached the pallete.bmp and two objects' graphics including the window - however you don't have to use a pallete.bmp, you can manually write the color values into the INI instead, see LemSet's readme (or source if that makes more sense to you) for more info). You may notice that the last object's trigger type is 16, which is not listed in LemSet's help file; this is because trigger type 16 is LPII-specific (it's the secret level trigger area).

pallete_info = BMP
style_number = 2
object_0_frames = 6
object_0_trigger_left = 12
object_0_trigger_top = 24
object_0_trigger_width = 16
object_0_trigger_height = 8
object_0_trigger_type = 1
object_1_frames = 10
object_2_frames = 4
object_2_trigger_left = 0
object_2_trigger_top = 0
object_2_trigger_width = 32
object_2_trigger_height = 32
object_2_trigger_type = 7
object_3_frames = 4
object_3_trigger_left = 0
object_3_trigger_top = 0
object_3_trigger_width = 32
object_3_trigger_height = 32
object_3_trigger_type = 8
object_4_frames = 6
object_4_trigger_left = 0
object_4_trigger_top = 4
object_4_trigger_width = 48
object_4_trigger_height = 12
object_4_trigger_type = 5
object_5_frames = 4
object_5_trigger_left = 4
object_5_trigger_top = 4
object_5_trigger_width = 4
object_5_trigger_height = 64
object_5_trigger_type = 2
object_6_frames = 4
object_6_trigger_left = 4
object_6_trigger_top = 4
object_6_trigger_width = 4
object_6_trigger_height = 64
object_6_trigger_type = 3
object_7_frames = 17
object_7_trigger_left = 4
object_7_trigger_top = 12
object_7_trigger_width = 4
object_7_trigger_height = 4
object_7_trigger_type = 4
object_7_trigger_anim = 1
object_7_trigger_sound = 6
object_8_frames = 1
object_8_trigger_left = 0
object_8_trigger_top = 0
object_8_trigger_width = 8
object_8_trigger_height = 8
object_8_trigger_type = 16

The graphics for animations DO resemble the Lemmini ones. The only differences are:

1) For a window, the frame that appears *last* in Lemmini, LemSet expects it to be *first*. (After that, they're the same - so 2nd frame for LemSet is the same as 1st frame for Lemmini, etc)
2) BMPs, not PNGs. Since BMP doesn't support transparency, it simply works with ANY color that isn't in your pallete being treated as transparent.
3) Width must be divisible by 8 for LemSet; Lemmini has no such restriction. (LemSet does not have any restriction on *height*.)

The INI file on the other hand, does not even remotely resemble the Lemmini one.


How you're naming them as cake_t00.bmp / cake_o00.bmp etc is fine.


LemSet, apart from the graphic files, also needs an INI file to tell it how to configure the pallete and interactive objects. There's a readme included on how to make it, as well as a sample, included with LemSet (the sample is basically just an incomplete version of the tree style from LPII). If you still can't work it out, I can send you a couple of the source files for the LPII sets to look at.


Now, what I'm saying about pallete.bmp is that LemSet has three different ways it can read the pallete data, and I find using pallete.bmp to be the easiest. If you look in the readme file, you can define the pallete source as either "18", "24" or "BMP". The first two mean that you need to directly write the pallete RGB values into the INI file (use "18" if you want to use Lemmings' native values (6-bit values) for the colors, "24" if you want to use standard RGB values like Paint etc use). If you set it to "BMP", LemSet instead looks for a file named pallete.bmp (or [style name]_pallete.bmp *I think*, if you set a style name), and uses the first 16 pixels to determine the pallete. (You can also copy/paste the pallete.bmp into whatever file you're working on, so that you have your exact pallete handy and can just use the color pick tool - that's what I did.)

A: The chopper.

Q: What's a truck doing in the middle of nowhere?!

Nuclear weapons can remove all traces of lemmings, humans, hamsters and capybaras.
+1 Nukes

...Okay, this is getting a bit ridiculous now. =P xD

If anyone wants to test this so far, here's a download link.

As this is LPII-based, as you might expect, this just has the same levels, music, resources etc as LPII. However - it certianly is NOT to be considered an updated version of LPII; V4/1/3 is still the official, current version. It's just for you to test out the mechanics changes in.

As I've said, I find Cheeky 1 to be a very good level for testing things on, unless you're wanting to test things relating to steel, one-ways or traps.

Note that I haven't adjusted steel areas. The support for pixel-perfect placement of them is there (try it yourself with a hex editor if you like), but as I'm working on mechanics at this point, I haven't adjusted the levels to take advantage of this. Therefore, some of the steel areas might overlap non-steel terrain or not entirely cover the steel blocks (For example, Mild 9, all steel areas extend two pixels further inwards from the steel blocks). However, you most certianly *can* observe the indestructible steel. =)

http://www.mediafire.com/download/o96tzbt392x31ld/NeoLemmixTest1.zip" class="bbc_link" target="_blank">http://www.mediafire.com/download/o96tzbt392x31ld/NeoLemmixTest1.zip

Left-facing hatches: These bug me in Lix, to the point that I avoid them where possible. I'd really like to see an arrow built into the hatch design to indicate the direction the lemmings face at the start. (One of Simon's designs even has arrows, but they point both ways.)

I could look into that at some point. Perhaps one option is to have an option, that can be toggled on and off by the player, to show a little arrow next to entrances indicating their direction. I would also assume that the majority of levels would still end up with right-facing entrances - Cheapo supported left-facing and yet I don't remember seeing many levels that used them.

One-way walls: Different directions of one-way walls don't provide much interest, unless (and I'm sure this isn't in the plan http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />) you have 4-way gravity. Then you could have arrows in 4 or even 12 directions, with tunnels allowed at (say) up to 90 degrees from the direction of the arrows.

4-way gravity? Hm. An interesting concept, though to be fair, we hardly even saw many levels that made use of two-way gravity back in the Cheapo days, and those that did usually ended up being far too complicated. If there's enough demand, I might look at implementing at least two-way at some point later - in which case, one-way ups would be as valid as one-way downs. (And would be implemented in the form of "a one-way down with Upside Down set becomes a one-way up", saves an object slot and somewhat reduces the chance of that person coming along who's like "ooh, I'mma put these arrows upside down so they confuse the player".)

Direct drop: I think the common view here is that you have to walk into the exit, but there's an interesting alternative: Lemmings touching the exit goal are saved, regardless of anything else. Either works IMHO, as long as it's consistent through the whole game.

I had actually always thought touching it means saved, due to a combination of the direct drop mechanic and Cheapo *actually* working on the "touch it and you're saved" rule. :/

Also http://www.lemmingsforums.com/Smileys/lemmings/thumbsup.gif" alt=":thumbsup:" title="Thumbs Up" class="smiley" /> to the climber-blocker idea, it makes perfect sense!

Twas ccexplore's idea, not mine. =)

Capybaras pwn both.
+1 Capybaras

=P

No, the beta player released here was, like the LPII one, based off OhNo mechanics.

Ah. You can't with the text replays. You can hex edit the LRB files to some degree, but it tends to cut off at your modified action (ie: it'll perform up to and including the one you modified, but nothing else afterwards).

There isn't a zoom as such, though it's already zoomed to 3x. Keep in mind that Lemmix moves a pixel per frame, there's no intermediate unrendered frames or anything, so you can acheive a good enough result with frameskip anyway. Likewise, the cursor mechanics are like in the original - it chooses the highest priority lemming (and in some cases, a backup one) within the cursor's range. I don't know that I want to override that, except maybe the direction-specific selection like in WinLemm or Cheapo if enough people think it should be added.

http://www.lemmingsforums.com/Smileys/lemmings/agree.gif" alt=":agree:" title="I Agree!" class="smiley" />, I love the unique gimmick in this level and it left a good impression for me. I like Lost Something and Surprise Package for the same reason (but not Superlemming, as I mentioned at the start - some gimmicks are better than others http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" />)

The downside of course is that the gimmick is only good once, so replayability is limited unless the level provides good challenges (Lost Something delivers there too http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />).

Yeah, that is the problem. They're great the first time but not after that. That can even be said of some of the more normal solutions - arguably, although not to such a huge extent, even one of the consensus favorites, Mayhem 20, exhibits this problem to a small degree.

Of course, these levels can be, as I suggested, clever experience for a first time player. That's why I like the idea of using them, but not excessively. (If you take a look at LPII's gimmick levels - one of them (that being the Sneaky) one, once you work out it's trick, it's basically a Tame type level. Yet at least two people have commented that they thought that was really clever when they cracked it - then you get people like geoo who just use glitches to avoid the gimmick altogether. =P)

to be clear; will this effect the player *inside* the editor? So when I want to test my level quickly it'll have these changes?

If I can get a copy of the editor source code I will most certianly try to apply the updates to its playtest mode as well, but at the moment, it looks like it's limited to Lemmix Players. Still, you can test pretty quickly by simply saving your level as 0101.lvl, turning on LookForLvlFiles, and starting Fun 1 (or Nice 1 if you're using an LPII style).

I vote to let bombers and diggers remain the same as regarding 1-way-walls. I think it'll get too complicated the other way+it works well as is. In the future, with newer features there could be things like non-bomb-able but otherwise destructible terrain and etc...

Yeah, I'm gonna leave these as is.

Wonderful!  http://www.lemmingsforums.com/Smileys/lemmings/thumbsup.gif" alt=":thumbsup:" title="Thumbs Up" class="smiley" />  This is just what Lemmix needs, in my opinion, to make it worthwhile again as a platform for level creation -- with Lix being almost entirely glitch-free and much easier to use (as well as having a kickass multiplayer mode), Lemmix had just fallen too far behind. Now, both have advantages and disadvantages -- the advantages of Lemmix being music, the traditional intro and wrap-up screens, use of the original styles (which are available in Lix but not allowed for any levels that are to be distributed) and the absence of some fine-control features, as this encourages level design based on strategy rather than precision, while keeping the "fake difficulty" of precision available for the occasional level to add variety. (Not that I would advocate removing these features from Lix; when playing geoo's or Clam's harder levels they tend to be necessary!)

Lemmix, no fine control features? Don't know what planet you've been living on, it seems to have the most powerful fine control of any Lemmings version I've played... or were you referring to Lix there?

I should also mention that I'm only working on the *player* side of things, although I am happy to cooperate with any level editor authors who want help with adding support for the extended LVL format. If no one does, I'll probably make a little tool to tweak the newer points, though I don't know that I have the patience to make a full-blown editor. (As far as I'm aware, I don't have the source to the Lemmix editor, only the players - otherwise I'd quickly hack up a version of that to handle edit, even though Lemmix isn't my preferred editor (but let's face it, we're not going to be able to add much features to LemEdit...))

* How about making direct drop and instant bombers available as options that can be set on a per-level basis? I wouldn't insist on removing direct drop from the game entirely when you've used it in your levels, but it being possible can be very annoying from the de-backrouting point of view.

That's a good point. Though I don't know that I'd feel comfortable enabling the sort of thing where direct drop works in one level then makes your lemmings splat in the next. I might feel more okay with allowing it to be somehow globally set for a level pack (so for a single level pack, it's a matter of all levels allow it or none do).

* "Perhaps I should make blockers only affect walkers, fallers, floaters, builders and miners?" Not sure if you're aware of the history of this -- on the old forums, when ccexplore discovered that blockers turn diggers, this was considered a glitch and was one of the glitches that he referred to by level (this one was "Wild 15") to avoid revealing its nature. When the secret came out, other people (LemSteven, maybe?) said "I don't consider that a glitch", and this seemed to become the consensus. Lemmini, however, disallows it. Lix keeps it, and I've used it in one level, the Lix version of Rhapsody in Blue (it's not needed in the RotL version). It's very useful for challenges, but it is unobvious and a little counterintuitive, so I don't have strong feelings either way -- I'd marginally prefer it to be left in, but perhaps I'm biased because I'm used to it by now.

I've already dealt with that glitch as per ccexplore's suggestion - if a climber encounters a blocker, it acts as though it hit its head and starts falling. The only other one that's really glitchy is the bashers - in this case, it really might be easiest to just prevent bashers reacting to blockers (the only other idea I can think of is making them just stop bashing if they encounter a blocker).

* I strongly feel bombers and diggers should affect one-way wall regardless of direction faced. That's what we're used to from original Lemmings, and it makes sense, as ccexplore said. Bombers aren't really facing any direction as they explode, and diggers "face" downwards.

This does seem to be the general consensus. Your idea about the diggers facing downwards just put an idea in my head though - one-way down walls, anyone? My thinking on this is destroyable by diggers or miners in either direction, but not bashers. (One-way up is obviously pointless unless we add new skills, which I'm not planning on doing, it'd essentially just be "destroyable only by bombers".)

* You mentioned music in connection with gimmick levels, but I'm still not entirely sure how music works in general in this version. I know that your Lemmix players for LPDOS, LPII and RotL fixed the DOS version bug where failing a level resets it to the first level's music (thank you very much for this!) but it would be good to have more control over the music.

Well, if I'm compiling a dedicated Lemmix player for a specific project, then music can be handled however is desired for that player. However, to simplify playing fan levels in general I'm hoping to be able to also create something along the lines of a Lemmix-based Custlemm (that loads external files). I'm aware the LemmixPlayerRemake in the source at least has elements of this, but some parts of my extra code I've only specifically written the parts for OhNo, so any player I make basically has to be based off that one rather than Remake as such. (EDIT: Or not. I tried compiling Orig in the NeoLemmix folder, and it compiled just fine, all fixes included, etc. So it would appear my fixes aren't dependant on the OhNo variant at all.)

Also, the reset music bug doesn't occur in any version of Lemmix, it was never reproduced by it.

* Could you add steel to the bubble terrain set? And perhaps some of my traps / deadly objects from Cheapo?

Modifying the existing graphic sets is outside the scope of this project at this stage, I might consider it later (to add the new object types in, and then it'll be easy enough to add other things at the same time - in the case of adding steel to the bubble set, it will mean I'll have to extend the graphic set format to support more than 64 terrain pieces, at the moment (keyword, at the moment) my priority is on functional, level-related stuff. If/when I do upgrade the graphic sets though, I'll gladly add your steel pieces to it (this is a one-off thing, apart from that I won't be modifying terrain), but I don't plan to add any objects unless they're of the new types (might fine-tune trigger areas on existing ones, though at the moment graphic sets are still limited to 4x4 resolution for defining trigger areas, it's only their position in the level that can be pixel-perfect).

Now that being said, if you're wanting make extensions yourself to any graphics set, LemSet might be of interest to you. Not the most user-friendly tool in the world, but when it's the only tool that exists for this purpose (and it's not *too* bad...)

4- No Problemming!
-stupid, a waste of design work and time imo

I know we all say this level is quite stupid but I have to ask - how did we feel about it the first time we saw it, and quite possibly weren't aware of the other entrance? In that context, I think it's as much of a unique trick as several other of the more unique ONML levels...

That is actually a brilliant idea of how to handle climbers meeting blockers. I hadn't thought of that.

Yes, I realised that the difference was Custlemm-only and edited my post to reflect that (I've edited it a few times, including while you were apparently writing your message). I'm not too worried about the exact details of what's happening behind the scenes, I just want it basically so that, if a walker can walk off the top step of a bridge and land safely, a miner can mine off the edge of it and land safely too, etc. Any method of implementation that acheives this end is fine by me. Hence why I'm most interested in knowing the exact details of why it happens - then I can decide for myself what I think is the best way to tackle it.

I will probably make the fall tracking pixel-precise, doesn't make sense for them to not be when the trigger areas are.


In the case of the turning around, I have coded it so (and this is part of the HandleWalking code, not the TurnAround code, so it *only* happens in the case of a walker meeting a wall or the sides of the level) that after turning around, the lemming is shifted one pixel forwards. This eliminates the backstroke basher (and somewhat the miner too; the other half, I consider to be a problem with the miner mask, not the game mechanics, and thus that'll be something to worry about when I get up to the data files - obviously, there'll be plenty of work to do there, such as fine-tuning steel areas etc).

Random fact - almost all the testing I've done so far has used Cheeky 1 as a sort of sandbox to test things in. Only things relating to elements that that level doesn't have (steel, one way, traps, etc), I generally test in other levels - Nice 2, Nice 3, Nice 7 and Nice 10 are my usual go-to's, depending on what I need. (When I was testing LPDOS's fall distance and concluded it was the same as LPII (and thus OhNo), I instinctively went to Psycho 28 because I know one of the falls is exactly one pixel too high - then realised "builders will be really useful for this" and jumped over to its easier version instead. Then for more precise testing... it was back to the actual modified version, and back to Cheeky 1. xD)



EDIT: I implemented your idea with the climbers. It actually works quite nicely.

I'm getting through this extremely rapidly - apart from the trigger areas, indestructible steel, left-facing windows, and anything already fixed in LPII, everything you see on that list that's been crossed off was done in the last few hours. Still, thanks for the offer, I might need at least a bit of pointers in the right direction for the more complex ones. Suggestions on what *should* happen are also always appreciated.

(For example - the blockers pushing climbers/bashers through walls - perhaps I should make blockers only affect walkers, fallers, floaters, builders and miners?)

The fall distance, I believe it's a matter of that walkers have already moved downwards 3 pixels before they become fallers, whereas other lemmings generally transition directly to it. Hence why the original game added 3 to their fallen distance - which would in fact imply that OhNo, not Orig, was the one with a glitchy fall distance. In this case, adding 3 to the maximum fall distance and restoring Orig's mechanic should fix the issue. (For the player for Orig, the max fall distance remains unmodified so walkers still splat at the same height they normally would in Orig - I thought this was the case for LPDOS too, but it seems that LPDOS, despite for the most part using Orig mechanics, uses the OhNo falling mechanics. I don't remember making that change, though, unless it's part of ccexplore's Lemmix modifications? EDIT: I see. OhNo and Orig are identical in this regard; only CustLemm has the higher distance.)
EDIT: Some testing would suggest that I'm right with my guess about the underlying cause... Or not, since Orig and OhNo behave the same in this regard... and this glitch is present in Orig, now that I think about it. >_> Still, all I have to do is find the exact distance between what walkers will tolerate and what others will tolerate, and change the 3 pixels to a larger amount...

Okay, the discrepancy is two pixels for a miner - this might be related to other miner positioning glitches though. I'll see what it is for a basher now... if I'm not mistaken, diggers and blockers quickly transition to walkers for one frame before becoming fallers, right (and same for shruggers if you remove whatever they're standing on)? So they shouldn't exhibit the glitch...

EDIT again: As I suspected, there's extra things at play for the miner - the discrepancy is only *one* pixel for a basher. Do you know any other cases where the glitch occurs? (Ohnoers? Though I don't think they can splat?) If it's just these two, then it shouldn't be too hard to simply chuck start their fall counters at -2 and -1 respectively... although then, that won't work because of how it works in 3-pixel units... :/ perhaps moving them down by that many pixels before transitioning them to a faller is the better option, if it doesn't look too jumpy... Actually, I can think of one more case; climbers when they hit their head. I'll have to look into that one too...