[OLD] Editor Bugs / Suggestions

[Tsyu]

After reinstalling Java 8, I tried using the absolute path of the symbolic link, and it worked! This means that NeoLemmix handles symbolic links just fine, at least if it's given the absolute path. Thus, it looks like we're back to square one regarding why just using "java.exe" doesn't work with Java 8, although it's definitely not caused by its path being absent from the Path variable.

On another note, NeoLemmix should open javaw.exe rather than java.exe to prevent an empty command prompt from opening.

[Wafflem]

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.

I'm having a similar problem with test mode for NeoCustLemmix - I'm getting the error ShellExecute fout 5. The NeoCustLemmix player is in the right folder and the Test.EXE path is also correct.

On another note, for the "seconds" part of the timer, I can't seem to put a 0 in the tens place (for example, if I attempt to put 9 in the first box and 09 in the second box, the second box removes the 0 and becomes 9 (like 90 seconds)).

[namida]

Could you PM me a screenshot of your editor folder, and a copy of your NeoLemmixStyles.ini?

[namida]

As has been mentioned in several places around the forum, some people are getting errors when trying to launch playtest mode on recent versions of the editor / player.

If you're having problems, check the following:
> Do you have a copy of the NeoCustLemmix (or if it's a traditional Lemmix level, then regular CustLemmix) in the folder with the editor?
> In NeoLemmixStyles.ini, is TestEXE for the style you're using set to "CustLemmixNeo.exe" (or "CustLemmix.exe") - without quotes!
> Does that copy of (Neo)CustLemmix work properly when launched directly?

Some things that could possibly be causes:
> Very long paths to the EXE. This is what I suspect highest to be the cause, though I don't know what paths people are using.
> Outdated versions of the editor with new versions of the player or vice versa. I very much doubt this would cause it, but at least one person has mentioned the problem went away by updating.
> Access restrictions on the folder the editor is in. Try running it as an Administrator, or alternatively, putting it in a folder that requires no special priveleges or specific users to access.
> Your computer doesn't like you.


If you can't resolve this problem, let me know as much as you can about how you have the editor and (Neo)CustLemmix set up - screenshots or even ZIPs of your editor folder may especially be helpful; you may want to PM these things rather than post them publicly.


I've added a note about this to the first post here, but I can't do much about it until I can either reproduce the error or get more info on when it does and doesn't occur.

[Wafflem]

I think I may have an idea on why this error occurs.

The first time I download the player, if I open the player directly (i.e. play it not from test mode), the error (in attachment) pops up. This error is the main reason that if I attempt to use Test Mode from the editor, the ShellExecute error pops up. However, when I uncheck "Always ask", then attempt to open the player from Test Mode, it works again. I'm not sure if I explained this correctly, so feel free to ask for clarification.

[namida]

This could very well explain why it's only shown up recently and why it doesn't happen for me. Previously, the copies from DropBox were always in a ZIP, but recently I've been putting them up as standalone EXE downloads. In my case, since it's compiled on my own PC rather than being downloaded, it wouldn't happen for me either.

Does what DynaLem said help for anyone else?

[mobius]

I was trying to re-complie my superLemmini styles [because I changed them around] and it didn't work with this unusal message;

could not find dirt.ini [in /Lemmix/xxxx/xxxx/xxxx] where x= the folders in my revenge of the lemmings work in progress, that is; the wrong place. Why would it be looking in the wrong place for the style files? I don't know how to change this.

On my third try, for no apparent reason it worked.
But here is another question I've been wanting to ask for a really long time and kept forgetting-----

How do you compile custom SuperLemmini styles? Nothing new that I put in the folder shows up on the compile menu.

I haven't yet tried fixing the play test issue. I think I'll reinstall everything anyway because, that seems like a good idea.
V1.28n-A is the latest right?

[namida]

You need to add them to the list of styles; currently it can't auto-detect new styles (this is something I need to add at some point).

Open NeoLemmixStyles.ini (note: you MUST exit the editor before doing this, otherwise it'll overwrite it when you close the editor), then look for where the SuperLemmini entries start - they'll have a heading [SuperLemmini_#]. Add an extra entry to the end, following the same format as all the others. The "internal name" should match the name of the style's folder (note that as SuperLemmini is a multi-platform application, this should be considered case-sensitive; it won't matter on Windows but it will on, for example, Linux), whereas the regular name can be whatever you like (it's just used to identify it in the editor).

[Wafflem]

Just to make sure:

In the gimmicks window of the editor, once (Gim28) and (Gim29) are filled with actual gimmicks, does that mean there will be no more space to add anymore?

Also, is it possible to add a feature "lock" terrain/object pieces (i.e. prevent myself from moving a terrain/piece by accident)? This happens to me a lot when I design my levels, and this could be a problem for the Tag-Team contest if a person from Phase 2 who adds the objects ends up moving a terrain piece by accident.

[namida]

Short of another new (or at least slightly modified) format, yes, that would be the result of once those two spaces are filled. However, with the change to graphic sets being purely by name rather than by number, that would free up two more bytes that could potentially be used to hold up to 16 more gimmicks.

With that being said, aside from a couple of possible additions from contest prizes, I don't plan to add any more gimmicks anyway.

[namida]

Okay, I just got a new computer, and I've noticed a glitch that doesn't happen on my old one - when dragging and dropping, the position shown is somewhat off.

The first difference between the two to come to mind that may be relevant is that the new PC has a 1080p display, whereas the old PC had 1360x768. The second thing is that the new one has AMD graphics, whereas the old one had switchable graphics between Intel HD and an NVidia chip (with me generally running the editor on the Intel chip).

Clearing the config file does not fix the issue.

EDIT: Changing display resolution to 1360x768 does fix it, so it's related to resolution somehow. Can anyone using resolutions other than 1360x768 or 1920x1080 let me know if they have (or don't have) similar issues, particularly if you're using a resolution above 1360x768?

Has anyone else noticed anything like this? I can't think of any obvious reason why it would occur, so any information from other people may help track it down.


EDIT: Added a screenshot to show what I mean. I've only actually moved the mouse about 3~4 pixels from the terrain piece's position, not as far as the drag/drop image would suggest (and if I were to release the mouse button, it would be positioned accurately for how much I've moved the mouse; not at the position the drag/drop image is shown). If you look closely, you'll also notice the drag/drop image is of a slightly smaller size than the actual piece.

I've now got Delphi 7 set up on my new PC, so I'll be able to take a look at this.

EDIT: Might be a general Delphi 7 issue, as it happens even with dragging/dropping the toolbox windows (stats editor, etc)...

EDIT: Okay, the issue isn't directly related to 1080p, but rather to the "Change the size of all items" option in the control panel, which is automatically set when using 1080p it seems...

[namida]

Had a rather nasty bug discovered, originally mentioned in the Player bugs topic as it wasn't clear to users which side the bug occurred on. It's been tracked to the editor, and occurs only in V1.29n-A, not earlier versions.

End result is that style names are often not being saved (or loaded) properly in levels for any engine that uses these (so, anything other than traditional Lemmix), in the case where the displayed names and internal names are different (so, this would affect the Genesis styles and the Christmas style).

I've tracked down the source of this bug. Because style numbers are being saved correctly, NeoLemmix levels should be completely safe - at worst, those using the Pillar or Crystal styles may switch whether or not they load in the regular versions or Genesis versions, and this can be manually changed back with the editor. (Super)Lemmini levels may be more affected; while they are not lost, you may have to manually edit the INI file to fix the graphic set name.

I'll have an update out within the next hour or so - I've already found and fixed the cause of this bug, but there's also one other bug I want to fix (not the magnification one; it doesn't look like that one's going to be fixable sadly as the causes of it lie within Delphi 7's units, not the editor code, and nothing short of a major rewrite - or just making a new editor - is likely to fix them).

EDIT: Or maybe not so long. It appears this bug was also the underlying cause of the other one, so fixing one of them fixed both.

[namida]

Update has been uploaded; you can get it here:

http://www.neolemmix.com/old/neolemmixeditor.zip

Please especially make a point of checking any levels using the Pillar or Crystal styles (if you made or edited them with V1.29n at any point), regardless of whether they use the regular or Genesis styles. Levels using any other Genesis styles, the Christmas style, or any VGASPECs (some won't be affected, but they're the minority, so it's safer to just check all of them), should also be loaded and re-saved; it's unlikely there'll be any visible problems but there could be some behind-the-scenes stuff that's wrong, and doing this will fix it up. Again; this only applies if the levels were created (or edited) with V1.29n-A; if they were only edited with older versions, there's nothing to worry about.

[namida]

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.

This has finally been addressed in the V1.30n-B update. The "classic" delete style is now the default, though there's an option to change it to how the NeoLemmix Editor previously handled it.

[Nepster]

    Huge Thanks!!