[OLD] Editor Bugs / Suggestions

[namida]

Alright, let's keep everything in one place. If you know of any bugs, or have any suggestions, for the NeoLemmix Editor make them in this topic. In the case of bugs, be sure to mention which version it happened in; even better if you can provide screenshots, sample levels that trigger it, or anything like this.

Note that new -A versions generally correspond to a new player version, and usually contain the bare minimum of updates to ensure compatibility with the new version of the player. Bugfixes and new features are generally added in the -B, -C etc releases.


Anything struck-out on the following lists has been implemented/fixed for the next update.

Currently uneditable features
> SuperLemmini: Background layers

Currently noted suggestions
> Quicker changing of terrain piece / object types
> More user-friendly setting of S-value / L-value based object properties
> Remember sub-window positions
> Assign "No Overwrite" option by default on new objects

Currently known high-priority bugs
none

Currently known low-priority or unfixable bugs
> One-Way Arrows still render on top of interactive objects and steel
      Not an urgent issue, as it still shows the general idea of how they work, but I will look into this when I get a chance.
> Zombie pre-placed lemmings are still rendered as normal lemmings (this could also be said for blockers)
      Not an urgent issue; technically the editor is rendering the object, not a lemming.
> Several values that are fixed for certain level types but editable in others display default values instead of accurate values for the types where it isn't edited
      Not an urgent issue; this is purely cosmetic and has no bearing on the actual output levels.
> Drag and drop doesn't work properly when Windows increase size is in effect.
      Appears to be unfixable without pretty much completely rewriting the editor.

[Nepster]

One suggestion (even though I am still working with V1.26n-B):
At the moment deleting terrain pieces does not affect the index of all other terrain pieces, i.e. after deleting a piece there is simply one index missing. When you now add a terrain piece, it gets the index of the previously deleted piece, hence is somewhere in the middle of the index list. This is somewhat annoying if you have a level with many layers of visible and erasing terrain pieces.
So I would prefer that after deleting a terrain piece, the editor checks the index of all other terrain pieces and shifts their indexes accordingly (like it was handled in the original Lemmix editor).

Right now, I am constantly saving and reloading my level, just to get the indexes right.

[namida]

This has been mentioned before; I forgot to pop anything about it in the first post sorry. >_<
It's a side effect of the code that allows gaps in index numbers in (Neo)Lemmix levels; this isn't really important anymore in the more recent versions of NeoLemmix (earlier it was important for negative steel purposes) but still matters for DOS/Lemmix where index determines whether or not an object is fake.

[Wafflem]

Since the NeoLemmix games now have a configuration menu, should the gimmick/skillset codes on the bottom left of the the level skillset menu/custom skillset menu be removed?

[namida]

Since the NeoLemmix games now have a configuration menu, should the gimmick/skillset codes on the bottom left of the the level skillset menu/custom skillset menu be removed?

Yes, very valid point.

[mobius]

I was putting off a Java update for a long time in fear that this would happen; [and it did happen  ]

the playtest for SuperLemmini no longer works. It says "shell execute fout 2"
I'll look into looking at the style file and trying to fix it myself but I wanted to say something for anyone else who might experience the problem.

[namida]

I was putting off a Java update for a long time in fear that this would happen; [and it did happen  ]

the playtest for SuperLemmini no longer works. It says "shell execute fout 2"
I'll look into looking at the style file and trying to fix it myself but I wanted to say something for anyone else who might experience the problem.

This is probably not an editor bug (though I will test it to make sure), but rather a result of the Java update changing where the file is stored. You want to look at the main NeoLemmixEditor.ini file and update the "JavaPath" entry.

You can generally find the correct thing to put here by using one of the following:

C:\Program Files (x86)\Java\jre*****\bin\java.exe
C:\Program Files\Java\jre*****\bin\java.exe

I really do need to find out how to write a bit of code to autodetect it, though...

[Tsyu]

Is it possible for you to upgrade to a newer version of Delphi? Support for symbolic links is necessary for launching Java via the command line properly, and it's possible that such support wasn't added until after Delphi 7. (And yes, I realize that Delphi is unfortunately damn expensive, so I understand if you can't afford to upgrade.)

[namida]

There are... ahem... ways around the cost. However, neither the player nor the editor will compile properly on the newer versions. It's possible I may be able to modify it to do so, but I haven't tried yet.

With that being said, making use of symbolic links should be more dependant on the underlying OS than anything else, shouldn't it?

[ccexplore]

Wait, Delphi is dependent on Java now? Yuck!  (well j/k, sort of.)

[namida]

Wait, Delphi is dependent on Java now? Yuck!  (well j/k, sort of.)

No. SuperLemmini is a Java app, and NeoLemmix Editor can launch levels in it as a "playtest" mode, just like it can with CustLemmix and NeoCustLemmix. But for that, the Java path needs to be configured properly. We're discussing the issue of either auto-configuring it or bypassing the need to configure it altogether.

[ccexplore]

On one of my Windows computers that sadly have Java installed, it looks like the symbolic link is stored at c:\programdata\oracle\java\javapath.  So c:\programdata\oracle\java\javapath\java.exe might work depending on how Delphi actually does the program launching.  In fact I wonder if you can simply do "java.exe" and be done with it, as it seems like the PATH environment variable includes the path to java.  There might be no need for a full path to the EXE.

Granted, with so many versions of Java out there, it's hard to know whether what would work on my computer still works on other ones.

(reminder to self: despite serendipity, uninstall Java soon given that I have long since had no use for the crappy emulator that came with Android SDK install that required the Java install in first place)

[namida]

Simply doing "java.exe" worked fine on mine (and is in fact the default setup in NeoLemmixEditor.ini), but doesn't work for everyone.

[Tsyu]

When it worked fine for you, you said that you had Java 7. It's possible that that version of Java uses (or used) its real location in the PATH variable rather than the location of the symbolic link. I need to verify this myself, though.

[Tsyu]

I temporarily removed Java 8 from my system and installed Java 7 update 75 64-bit. Indeed, no symbolic links were present in the location that Java 8 installs them to. Also, the real Java location was not added to the Path variable. Instead, real EXE files were installed to Windows\System32. However, I still had to set JavaPath to the real Java location to playtest SuperLemmini levels. If I set it to java.exe or C:\Windows\System32\java.exe, I got the error "ShellExcecute fout 2" (as opposed to 5, which I get with Java 8) unless I had copied java.exe from System32 to SysWOW64.

So, with both Java 7 and 8, there's something that can prevent NeoLemmix from running if JavaPath is not set to the real location of Java:

• Java 7: The 64-bit version installs the EXEs for the command line to System32, and NeoLemmix apparently can't run Java from there at all under 64-bit Windows. It's possible that the 32-bit version of Java 7 installs those EXEs to SysWOW64 under 64-bit Windows, though I haven't verified this.
• Java 8: This version of Java installs symbolic links to the folder that ccexplore mentioned, adds that folder to the Path variable, and expects programs to use those those to run Java programs. However, this fails in NeoLemmix since it apparently doesn't support symbolic links.

(Fun fact: "fout" means "error" in Dutch. At least that's what I gather from Google searching "fout 5" and putting "fout" into Google Translate. It should probably be corrected in the next NeoLemmix release.)