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

[namida]

And also, because I prefer to use the arrow keys to move pieces around rather than the mouse I prefer to move them quickly without having to hold Ctrl, and use that button instead to make 1-pixel moves, just like the original Lemmix Editor. Is it possible to add an option in the settings to change this back to normal? Thanks.

Just stumbled upon this by accident - there's actually a setting for this in the INI file. So, in the meantime you can edit that manually; in the future I'll look at adding something to the Settings menu to make it easier to change.

[namida]

Alright, here's the REAL update to the NeoLemmix Editor. http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" /> This one brings it up to date with the latest versions of both NeoLemmix and SuperLemmini, if I'm not mistaken (though it still doesn't support "vgaspec"s or background terrain in SuperLemmini).

NeoLemmix Editor V1.20n-B
--------------------------------------
> Level stats, gimmicks and skillset are now three seperate menus.
> Shortcut keys for some menus have been changed, as well as a couple assigned to options
  that previously didn't have any shortcut key.
> Supports infinite time limits in both SuperLemmini and NeoLemmix formats
> Supports infinite skill counts in SuperLemmini format, and implements it more tidily in
  NeoLemmix format than it previously did
> Supports Autosteel in SuperLemmini format
> Supports negative steel in SuperLemmini format
> Supports invisible objects in NeoLemmix format
> Added an option to manually specify the path of Java. It's the JavaPath option under
  the [Editor] section in NeoLemmixEditor.ini. You may not need to configure this, but
  if playtest mode for SuperLemmini gives an error, setting the full path here should
  hopefully fix it.

(NOTE: At the time of release, SuperLemmini has a major glitch with standard
       autosteel (or by SuperLemmini terminology, Autosteel Mode 2). Tsyu
       has stated this will be fixed in the next update.)

https://www.dropbox.com/s/5c2rmvu31oot5fn/NeoLemmixEditor_V1.20n-B.zip" class="bbc_link" target="_blank">https://www.dropbox.com/s/5c2rmvu31oot5fn/NeoLemmixEditor_V1.20n-B.zip

EDIT: Reuploaded to fix a couple of issues with infinite skills in SuperLemmini format.


Also, before anyone asks - no, there's no plans to apply infinite time limits to any of the existing levels (whether official or LP).

[Tsyu]

If I use an absolute path for the NeoCustLemmix player and try to playtest a level in that player using the NeoLemmix editor, I get a "test player EXE does not exist" error, even if the path is correct. If I use a relative path, though, everything works fine. Strangely, SuperLemmini playtesting works even with absolute paths.

Specifying the full path to java.exe fixed the SuperLemmini playtesting error.

With the above considered, do you think that, when playtesting mode is entered, you could have the NeoLemmix editor display the command line that it will use? That could be a big help in determining why the problems are happening.

One more bug I noticed with the editor: In the levels viewer (in the View menu), escape backslashes are not removed from Lemmini level titles.

[namida]

Although probably not the best design decision, it's meant to work that way for (Neo)CustLemmix. I can probably change this though so that it works with either. SuperLemmini uses an absolute path because keeping NeoLemmix Editor and a copy of SuperLemmini (which has heaps of subfolders etc) in the same folder is not quite as clean as keeping NeoLemmix Editor and a copy of NeoCustLemmix in the same one.

I can't say I'm too familiar with how the level viewer even works, but I can definitely look into fixing it.

By the way, making progress on the better VGASPEC handling. In fact, it's now almost fully implemented for (Neo)Lemmix; I just need to implement it for SuperLemmini too and fix up a few minor details. Basically, you're no longer tied to having to make a specific entry in the styles INI for every combination of graphic set and VGASPEC; each entry can simply be marked as either being a normal style or a VGASPEC, and you can pair up any VGASPEC with any graphic set you like (similar to how you could just pick both arbitrarily in NeoLemEdit).

EDIT: Okay, implemented for SuperLemmini now too! At least for the most part - I haven't (not due to trouble, just haven't done it yet) got it *loading* levels with special graphics yet (but it saves and displays them just fine, including the specified positioning).

[namida]

Done!

NeoLemmix Editor V1.20n-C
---------------------------------------
* Adds support for special graphics in SuperLemmini format.
* Improves handling of special graphics in Lemmix/NeoLemmix format.

https://www.dropbox.com/s/3ea17vmqqqpxhi4/NeoLemmixEditor_V1.20n-C.zip" class="bbc_link" target="_blank">https://www.dropbox.com/s/3ea17vmqqqpxhi4/NeoLemmixEditor_V1.20n-C.zip

Note: There's some pretty major changes to the NeoLemmixStyles.ini, though you can probably just copy/paste the additional parts over (entry 20 onwards in NeoLemmix style, entry 16 onwards in CustLemmix style, and entry 10 onwards in SuperLemmini style). You'll also need to recompile your SuperLemmini styles (traditional Lemmini has no changes, and updated and pre-compiled Lemmix and NeoLemmix styles are, as usual, included).

And if you're adding other special graphics, I'm sure most of you realise this but I'll make it clear just in case - it couldn't matter less what number you give them (just as long as you don't set the GraphicSetExt number to zero). You can even have the same number on two. (Super)Lemmini uses names, not numbers, to identify styles, and that is equally true for special graphics. (On the other hand, NeoLemmix does indeed use numbers.)

[Tsyu]

The NeoLemmix editor freezes on "Fetching metadata" whenever I compile a SuperLemmini special style.

EDIT: And if I load an LVL file, I get an error message saying "TBaseGraphicSetWrapper.Graph.IsSpecial: Property IsSpecial does not exist."

[Tsyu]

I don't think you ever said how you extended the DAT format to handle files larger than 64 kB. Are the previously unused bytes in the headers now used as the high bytes?

[namida]

The NeoLemmix editor freezes on "Fetching metadata" whenever I compile a SuperLemmini special style.

EDIT: And if I load an LVL file, I get an error message saying "TBaseGraphicSetWrapper.Graph.IsSpecial: Property IsSpecial does not exist."

Found the issue. Quite an embarassing one... while I had put all the updated styles, INI, etcs in the updated zip... it appears I somehow had left the old version of the editor itself. xD Redownload and it should work?


As for the extended DAT - that's how it's done for the DAT format in itself. In graphic sets, 8192 (whichever bit that corresponds to... it's too early to math xD) is added to the first object's animation flags as a marker (just like the markers for autosteel, extended palette, etc), and for objects Unknown1 is used as high bytes for animation_frames_base_loc, while for terrain, the unknown value is used for:

(Bit0 - Autosteel marker - this has been there for a long time now)
Bit1 to Bit7 - High byte (or, 7/8ths of a byte http://www.lemmingsforums.com/Smileys/lemmings/tongue.gif" alt=":P" title="Tongue" class="smiley" /> ) of image_loc
Bit8 to Bit15 - High byte of mask_loc

The DAT format one I had written up, but forgotten to put into the documents folder. I haven't done one on the graphic set format yet.

[namida]

Known bugs in NeoLemmix player:
When specifying what level should be sent to after completing a secret level, the level number worsk fine but the rank number is ignored.
Level codes (not cheat codes, but the standard level codes) do not work for ranks beyond the 5th rank.
Both will be fixed in next update.

There isn't too much stuff I can think of that needs to be done on the player at the moment, so I might look at implementing a few more of the gimmick suggestions.

[Tsyu]

Found the issue. Quite an embarassing one... while I had put all the updated styles, INI, etcs in the updated zip... it appears I somehow had left the old version of the editor itself. xD Redownload and it should work?

Yes, that fixes both of those problems. I did find another problem, though: When compiling SuperLemmini special styles, the editor loads both the main image (*.png) and the mask image (*m.png) and combines them into one image, with the main image in front (Actually, it's a bit more complicated than this; try using one set's mask with another set and you'll see what I mean). This should not be the case; the mask is for gameplay only and should have no visual effect. Also, the editor expects both files to be present; in SuperLemmini, the mask is optional.

As for the extended DAT - that's how it's done for the DAT format in itself.

So my guess is correct, right?

[namida]

Yes, sorry, that was a bit vague. The first unused bytes are for decompressed size, the second two for compressed size.

It loads it this way so it knows which areas to treat as transparent. This is important when, for example, using objects with No Overwrite. Also partly because, for some reason which I couldn't identify, it kept throwing errors when trying to use the standard Lemmini transparency algorithm (even though it works fine for objects and terrain).

Of course, I will try to improve this. I also didn't realise the mask was transparent, so I'll try to find a way around needing it altogether. Such as getting that damn normal algorithm to work. xD

[Tsyu]

I think I now have a good lead as to why I can't playtest levels in SuperLemmini without specifying the full path to java.exe. I checked my Path variable and did not find the real location of java.exe. Instead, I found C:\ProgramData\Oracle\Java\javapath, which does contain a java.exe, but it's really a http://en.wikipedia.org/wiki/NTFS_symbolic_link" class="bbc_link" target="_blank">symbolic link (which is different from a shortcut) to the real thing. This must be what the NeoLemmix editor must be trying to run, which should still work, but it doesn't for some reason.

This setup was probably introduced in http://www.oracle.com/technetwork/java/javase/downloads/index-jsp-138363.html" class="bbc_link" target="_blank">Java 8 (which isn't available at java.com for some reason), so if you want to try to fix this problem, you might want to get that.

[namida]

^ I'll look into that at some point soon. http://www.lemmingsforums.com/Smileys/lemmings/smiley.gif" alt=":)" title="Smiley" class="smiley" />

In the meantime, here's NeoLemmix V1.20n-B. This is a very minor update, just fixes two glitches - the main reason I'm releasing it now, rather than waiting for further stuff, is so that LPIII Bonus Pack isn't based on an "inbetween versions" release of NeoLemmix - so yes, LPIII Bonus (at least the first release) will also be based on NeoLemmix V1.20n-B. As usual, it's seperate from the NeoLemmix update stream until the first update after it's finalised.

NeoLemmix V1.20n-B
-----------------------------
*  Fixed the bug where blocker fields remained behind when the Disobedient Lemmings
   gimmick is in effect.
*  Fixed a bug where specified post-secret-level redirects always went to the first
   rank instead of the correct one.

https://www.dropbox.com/sh/pf3qz9s1jvxaxzh/AADJQnEVIMYKNKpyk4anjzQja" class="bbc_link" target="_blank">https://www.dropbox.com/sh/pf3qz9s1jvxaxzh/AADJQnEVIMYKNKpyk4anjzQja

[namida]

Alright, going back to the subject of adding objects to existing styles - I'm going to do the LPII ones very soon, but the official styles may be a bit further away.

As long as you weren't planning on needing to use the new objects, you can still go ahead and create levels of course - the new objects will be added at the end of the style, so they won't cause compatibility issues with existing levels.

I won't necesserially use all the available slots - it depends what objects make sense for the style too, and I'm only adding *new* object types, not more objects of existing types. For example, I'm not going to add teleporters to the Tree style, but probably will add them to the Psychedelic style.

Most additions will be re-using graphics from the LPIII sets (possibly recolored).

Additions.

Tree: Updraft (Sky)
Purple: Teleporter (Martian), Slow Freeze (edited version of Lab radiation object)
Psychedelic: Teleporter (Circuit), Radiation (Lab), new object (original)
Metal: Locked Exit (original), Button (Circuit), new object (original)
Desert: Updraft (Sky), Radiation (Sky)

[Wafflem]

I think the radiation will work very well for the Psychedelic style instead of the Purple style.

I also have an expanded idea on the updraft - left-facing and right-facing drafts. When a lemming enters those zones, the following happens:

• If a lemming walks into the draft in the correct direction, they will move faster.
• If a lemming walks into the draft in the opposite direction, their walking will be slowed down.
• If a glider enters the draft in the correct direction, they will be blown in that direction.
• If a glider attempts to enter the draft in the opposite direction, they will turn around.
• If a faller or floater enters the draft, they will be pushed by the draft's direction.

This will work very well in the Desert style (like it's a sandstorm), and could have worked in the Sky style (but there are no more object slots).