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.
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 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.
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?
Quote from: DynaLem on January 10, 2015, 08:23:47 PM
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.
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.
Quote from: möbius on January 24, 2015, 10:51:39 PM
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.exeI really do need to find out how to write a bit of code to autodetect it, though...
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 (https://store.embarcadero.com/542/purl-dbanner), so I understand if you can't afford to upgrade.)
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?
Wait, Delphi is dependent on Java now? ??? Yuck! (well j/k, sort of.)
Quote from: ccexplore on January 25, 2015, 09:24:39 AM
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.
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)
Simply doing "java.exe" worked fine on mine (and is in fact the default setup in NeoLemmixEditor.ini), but doesn't work for everyone.
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.
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.)
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.
Quote from: möbius on January 24, 2015, 10:51:39 PM
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)).
Could you PM me a screenshot of your editor folder, and a copy of your NeoLemmixStyles.ini?
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. :P
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.
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.
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?
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?
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).
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.
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.
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...
Had a rather nasty bug discovered, originally mentioned in the Player bugs topic (http://www.lemmingsforums.net/index.php?topic=1982.msg50085#msg50085) 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. :)
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.
Quote from: Nepster on January 06, 2015, 11:57:20 AM
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.
:thumbsup: Huge Thanks!! :thumbsup:
Quote from: DynaLem on January 28, 2015, 03:47:49 PM
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)).
Just saw this. Although it will reduce it to a single digit number, it functions fine (ie; in your example, it'd give 9 seconds, not 90).
not sure if this is a bug or I'm just doing something wrong: [I have latest version of editor]
Just realized there's a new version that fixed the index issue :thumbsup:
sometimes the Flip, face left and other features don't work and sometimes they do. I select create a new level>neocustlemmix. Those check boxes are greyed out and I can't select them. I'll check to see if this happens in the latest version.
I've noticed this occasionally as well, though never seem to be able to reproduce it when trying to. Do you notice any patterns as to when it happens?
The relevant boxes should be grayed out whenever you're editing a level in a style that doesn't support those features. There's no case where all boxes will be active, as some new properties are NeoLemmix exclusive (such as S and L values), while others are SuperLemmini exclusive (like fake / invisible terrain).
The Crystal style glitch is back. It happens in the editor but not in the game.
Damn. I remember specifically having that on my list of things to test (due to the new one-way-wall handling), and I must've forgotten. Thanks.
Quote from: DynaLem on April 03, 2015, 03:32:47 AM
The Crystal style glitch is back. It happens in the editor but not in the game.
I does look cool though
It may look cool, but it's not an accurate representation of how they will appear in game. I'll try to get a fixed version out within 24 hours, as that's quite major IMO.
EDIT: Found and fixed the cause of it already. Before I release the update, I'm going to look at the Lemmini glitch which is basically the reverse of this (pixels being treated as solid when they shouldn't be in some custom styles).
While I'm at it - has anyone encountered problems with the "classic delete" feature? I haven't myself (and I have been using the editor a bit recently), but since I often miss things, let me know ASAP if you have found any and I'll try to fix them at the same time.
Quote from: namida on April 03, 2015, 05:11:37 AM
It may look cool, but it's not an accurate representation of how they will appear in game. I'll try to get a fixed version out within 24 hours, as that's quite major IMO.
EDIT: Found and fixed the cause of it already. Before I release the update, I'm going to look at the Lemmini glitch which is basically the reverse of this (pixels being treated as solid when they shouldn't be in some custom styles).
While I'm at it - has anyone encountered problems with the "classic delete" feature? I haven't myself (and I have been using the editor a bit recently), but since I often miss things, let me know ASAP if you have found any and I'll try to fix them at the same time.
I have not noticed any problems with the delete;
but since you mentioned it; it seems that you can't select an item in the list anymore? [Or maybe you could never do this in NeoLemmix i don't remember]
Before; you click an item in the list and press spacebar this selects the thing in the editor. This is very handy when a piece of terrain is totally hidden [behind other pieces] and not easy to get to with the mouse.EDIT: it seems like this happened only once to me, because just now it works fine ???
-------
Another important thing: the list doesn't seem to change or remove items when you close this also only happened once.
-----
a side note: I finally understand how the one way walls work. Very nice feature :thumbsup: [yeah I know it isn't that difficult--it took me way too long to figure that out]
------
EDIT:
there's some kind of graphical glitch with trigger areas in the editor. I don't think it effects gameplay at all so not very important; just thought I'd mention it. The pink areas gets brighter and dimmer when you move things around.
Do you mean while you're dragging them, or after you drop them? If it's the latter, most likely that's just an optical illusion due to the different brightness of surrounding terrain/objects/etc and viewing angle. If it's while you're dragging and dropping them, minor graphical oddities during that seem to be inevitable. (For the best example, try dragging a steel area that's placed behind some terrain...) Anyway, if they cover the correct area, I wouldn't consider it a critical matter.
I know someone may want to recreate the lemmings touch levels so for that suggest
Mischievous Lemmings the do exactly what they do in lemmings touch
for example like disable teleporters as apposed disabling rockets like in lemmings touch
I don't have a PS Vita, so I don't really know how Lemmings Touch works (now if they'd release it on Android, or even on PS3 if it would be workable there...). Also; that'd be a Player suggestion, not an editor one. But to put it in short: Don't hold your breath for it.
Quote from: namida on April 04, 2015, 03:21:26 PM
I don't have a PS Vita, so I don't really know how Lemmings Touch works (now if they'd release it on Android, or even on PS3 if it would be workable there...). Also; that'd be a Player suggestion, not an editor one. But to put it in short: Don't hold your breath for it.
That are videos of it on youtube so you can take a look if you want
Okay, that still doesn't change that it's unlikely to get in. For one - who exactly is going to make the graphics for them? Even ignoring that ripping and converting the Vita graphics would still be a lot of work, the existing ones are not going to stylistically match the lemming graphics currently used in NeoLemmix. And then, I get the impression that they're fairly different from regular lemmings - even the zombies, which have very little difference from ordinary lemmings (and their graphic is just a slight recolor, which isn't even saved seperately in the file, but just recolored at runtime), was quite a major task to implement.
The one-way arrows still show, specifically against the water.
I'm not sure what exactly causes this, so here's a screenshot and the level that has the glitch.
I'll look into that one, though I wouldnt' consider it to be as major of an issue. (Technically they shouldn't show against the steel either, but that's likely to be VERY hard to do anything about...)
Quote from: namida on March 30, 2015, 11:19:58 AM
I've noticed this occasionally as well, though never seem to be able to reproduce it when trying to. Do you notice any patterns as to when it happens?
The relevant boxes should be grayed out whenever you're editing a level in a style that doesn't support those features. There's no case where all boxes will be active, as some new properties are NeoLemmix exclusive (such as S and L values), while others are SuperLemmini exclusive (like fake / invisible terrain).
It seems to happen most often when I open a Lemmini ini level then convert it to NeoLemmix style. I found what seems to fix it is closing the program and opening the newly converted level up in NeoLemmix.
I found and fixed the cause of that bug. :)
Other features I want to add for the next update:
- Improved "Validate Level" menu; I want to make it so that it presents a list of detected problems, and you can select individual ones and tell the editor to automatically fix them (as well as a "Fix All" button of course) for any that is possible to do so. For example, terrain pieces / objects that don't exist in the graphic set, save requirements higher than the number of lemmings in the level (taking into account Cloners, of course), etc.
- A mass conversion feature to quickly convert a bunch of levels between formats.
Anything else that anyone thinks should be in the next version?
If only there was a backroute detector
I think all usage of other level editors would disappear overnight if there was. :P Unfortunately, it's not realistically possible.
(Now, if you had've suggested that before April Fools... :P)
New "Validate Level" menu should be implemented for the next update. I probably won't have the "fix" function yet, but the menu itself has been reworked, including adding support for detecting issues specific to particular engines, and things such as mutually-incompatible gimmicks. :) EDIT: Nope, the fix function is in there now. :) It can't fix all errors automatically, but it can fix most of them.
Not 100% sure yet if the Mass Conversion will be there for the next update; hopefully it will. :)
Okay, so, I've added the new Level Validation window, along with the option to select and fix specific errors from the list (and a "Fix All" button). Many (but not all) of the fixes it implements, especially in relation to level stats, are the same as how NeoLemmix itself reacts to such situations.
Just to be clear, these autofixes are only applied when you use the Level Validator option, then select the error and click "Fix" (or just click "Fix All"); it doesn't constantly detect and fix these things, since there may be cases where they're intentional, or are temporary during work on a level. Nor does it auto-fix them when saving the level, unless it's as a side effect of something outright not being supported by the level format.
The errors it can currently detect are:
Level Stats / Skillset / etc
Very high lemming counts that may cause game to lag (no autofix)
Impossible save requirement (fix: reduces it to highest possible value)
Time limit of zero (fix: sets it to infinite or 9 minutes, as appropriate for the format)
Screen start position outside level boundaries (fix: sets it to 0, 0)
Incompatible gimmicks:
>> Hardworkers + Lazy (fix: turns off Lazy Lemmings)
>> Solid Floor + Vertical Wrap (fix: turns off Solid Floor)
>> Invincibility (fix: turns it off; this is because this gimmick is intended as a debug feature only)
>> Classic Zombies without Zombies (fix: turns on Zombies)
>> (Gim29) (fix: turns it off; this is because Gim29 is a currently unused gimmick slot)
More than 8 types of skills in the skillset (fix: removes skills beyond the first 8)
Interactive Objects
Maximum number of objects exceeded (no autofix)
Object that doesn't exist in graphic set (fix: deletes the object)
Object X position not divisible by 8 in traditional Lemmix levels (fix: rounds it down)
Object Y position not divisible by 4 in traditional Lemmix levels (fix: rounds it down)
>> Y divisible by 4 is not a requirement, but can cause unexpected issues with the trigger areas
Object outside of level boundaries (fix: deletes the object)
Object with properties that aren't supported in current format (fix: unsets those properties)
>> This can occur when converting levels from another format; it's harder to notice than stats / skillsets that aren't supported which is why the checker points them out
One-way wall objects that don't have the "only on terrain" property set, in non-NeoLemmix levels (fix: sets it)
Object with "upside down" set but not "trigger invert" in SuperLemmini levels (fix: sets it)
>> This is because generally, if an object is upside down, the intention is for the trigger area to be upside down too; but in SuperLemmini these are two seperate options, unlike with horizontal flip
Terrain Pieces
Maximum number of terrain pieces exceeded (no autofix)
Terrain piece that doesn't exist in graphic set (fix: deletes the piece)
Terrain piece outside of level boundaries (fix: deletes the piece)
Terrain piece with properties that aren't supported in current format (fix: unsets those properties)
Steel areas
Maximum number of steel areas exceeded (no autofix)
Coordinates or dimensions not divisible by 4 in traditional Lemmix levels (fix: rounds them down)
Dimensions exceeding 64 in traditional lemmix, or 256 in NeoLemmix (fix: reduces them to these values)
Steel area outside of level boundaries (fix: deletes the area)
Steel area with properties that aren't supported in current format (fix: deletes the area)
>> The reason it deletes it, unlike with other pieces where it unsets them, is that simply unsetting those properties is more likely to give unwanted and hard-to-spot results with steel areas than it is with objects or terrain
Let me know if you think there's anything that should be added to this. Reworking of code elsewhere will be needed for anything that requires detecting a window (in fact, it might be required for detecting the type of any object in Lemmini / SuperLemmini formats), so that's why, eg, it won't detect an absence of windows currently, or detect the lack of any zombies in Zombie gimmick levels.
Discovered a bug where regular Lemmix levels (or very old NeoLemmix levels; generally those that have not been edited with V1.24n onwards or dumped from player V1.24n onwards) will not open directly in NeoLemmix styles, and must instead be loaded as regular Lemmix levels then converted. This will be fixed in the next update.
Working on the mass convert feature now. :) Looking promising so far; it looks like this too will be in the next version.
Of course, anyone using it needs to be aware that *all* converted levels should always be checked before any kind of release, and also that due to different features in different engines, some loss of data may occur. Conversion is supported between any combination of Lemmix, NeoLemmix, Lemmini and SuperLemmini. Generally, converting the older engines to the newer ones should have little if any issues, though Lemmini to NeoLemmix may need closer attention than the other three old-to-new pairings. Attempting conversion back to older engines is very likely to be a disaster, though SuperLemmini to Lemmini may work out alright.
Finished implementing it. So far, I've only tested it with NeoLemmix -> SuperLemmini, but it worked first time with no major errors - one minor one in that it didn't update the display to say it was finished. I do still need to test other combinations.
EDIT: Okay, update containing the feature has been added. :)
How about an option in the editor to enable you to change the terrain piece quicker than pressing the button in that properties window and going through the list;
If able; have the middle mouse wheel automatically change the piece as if scrolling through the list when the terrain piece is selected (highlited).
To zoom in and out make it necessary to hold down control while scrolling. Or do the opposite; hold down control to scroll through terrain pieces.
This is one of the remaining annoyances of the editor for me personally. Having to go through the list every time (unless your copy pasting) can be a little annoying.
You can edit it by changing the number in the Terrain Piece box, though this is a bit inefficient, yes. I'll see what I can do about that in the next update. :)
The editor refers to the SuperLemmini Apple style as "Apple Computers"; it should be "Apple Computer" (singular).
And you still haven't changed the default Java path to javaw.exe. Java.exe opens a blank command-prompt window (which I'm sure is not what you intend), whereas javaw.exe does not.
I'll sort those things in the next update. In the meantime, they can be acheived with a few quick modifications to the INI files. (/styles/SuperLemmini/style.ini for the former, and NeoLemmixEditor.ini for the latter; if the editor is already running, the changes will not take effect until it is restarted)
I don't know if this is intentional so I'll bring it up. It was confusing at first and doesn't seem right.
When making a level with zombies; If you set the lemming count to 80 for example, and put three zombies in the level [via pre-placed]. In the menu screen it will say: 80 Lemmings in the level. But during the level only 77 lemmings will come out [or at least the count says that I didn't manually count the lemmings].
So it appears that it subtracts the three zombies from the count.
It doesn't count them when the level starts like normal pre-placed lemmings.
That's intentional, but probably shouldn't work that way. I removed the zombies from the "Out" counter to avoid misleading as to how many lemmings could possibly be saved. Part of the reason why it isn't deducted pre-level is because the level may have windows that release zombies, which would be a pain to calculate pre-hand laziness.
Percentages also don't account for the existance of zombies, hence why Doomsday Lemmings uses lemming counts by default instead, despite my very strong personal preference for percents (hence why it's the default in NeoLemmix in general and in all my other packs, though there's an option to change to lemming counts).
Quote from: namida on April 18, 2015, 06:39:23 PM
my very strong personal preference for percents
Other than 100 % as a synonym for X/X or lose-0? I'm sure such a condition can be cured with time. :-]
-- Simon
It's not a "condition", it's just my preferred way of displaying a saved number of lemmings. It's fine if you disagree, but it's starting to get a tad annoying that you keep insisting your preferred way of doing things is the objectively best one...
Just to be clear: This post is coming from me personally, not me "as an administrator".
Quote from: namida on April 18, 2015, 06:39:23 PM
That's intentional, but probably shouldn't work that way. I removed the zombies from the "Out" counter to avoid misleading as to how many lemmings could possibly be saved. Part of the reason why it isn't deducted pre-level is because the level may have windows that release zombies, which would be a pain to calculate pre-hand laziness.
Percentages also don't account for the existance of zombies, hence why Doomsday Lemmings uses lemming counts by default instead, despite my very strong personal preference for percents (hence why it's the default in NeoLemmix in general and in all my other packs, though there's an option to change to lemming counts).
ok--I wanted to make sure I wasn't getting confused or something. I highly suggest changing it if just to change the count on pre-placed (which so far is all I've been using. But doesn't mean I won't I guess...)
The main reason I point it out is not only is it a little confusing to the player but when making a level you have to add on the zombies you have in a level. When making the level I was thinking of them as objects instead of lemmings.
In good news I've finally got some good level ideas going on here with zombies. :thumbsup:
Would it be possible to have zombies be also climbers and floaters? :devil:
It most certianly is! Doomsday Lemmings in fact makes fairly extensive use of that feature!
When you place a pre-placed lemming or a window, you can give them any of the following attributes by setting the L value:
1 - Climber
2 - Swimmer
4 - Floater
8 - Glider
16 - Mechanic
32 - Blocker
64 - Zombie
If you want more than one of those, just add the numbers together. Eg: 1 (Climber) + 4 (Floater) + 64 (Zombie) = 69, which will give you a lemming that's a climber, a floater and a zombie.
Some things to note:
- Zombie will be ignored if the level doesn't also have the Zombie gimmick enabled
- Blocker will be ignored on trapdoors; it only works on pre-placed lemmings
- Glider will be ignored if Floater is also set, since a lemming cannot be both at the same time
- In the case that some setting is ignored for the above reasons, anything else you set will still work. For example - if you were to add *all* of these together (1 + 2 + 4 + 8 + 16 + 32 + 64, = 127) and set it on a trapdoor, on a level that isn't a zombie level; the result would be that it would spawn lemmings that are Climbers, Swimmers, Floaters and Mechanics (with Glider, Blocker and Zombie being ignored for the above reasons).
(This makes me realise... I don't think I've used zombie-blockers anywhere yet... muahahaha)
Question - should I start including a copy of NeoCustLemmix with the editor? This will mean the download will be larger, but that users won't have to download it seperately in order to use playtest mode.
Size aside, the main argument against it is that it's of no use to those who aren't using the editor for NeoLemmix levels, in which case they'd still have to (if they want to use direct playtest mode from the editor) get traditional CustLemmix (or SuperLemmini) seperately.
Can finally confirm that a VERY overdue feature will be in the next version - editing the window ordering! NeoLemmix has supported this for a very long time, and SuperLemmini for even longer; but currently, although the editor will preserve this data when loading, saving and even converting levels, it provided no way to actually edit it. The next version will finally provide a way.
I just noticed, that like in original Lemmix, object coordinates have to be non-negative in NeoLemmix (or else these objects are deleted when saving). The current .lvl-file format seems rather flexible to me, so I wonder where problems occur with arbitrary object coordinates?
There shouldn't be any issue with it. Give me a sec to check.
EDIT: Okay, found it. This was an issue purely on the editor's side, and purely with the Save routine, and occurred because the coordinates are now 4-byte values, but the Editor was truncating them to 2-byte ones and filling in the space with 00s. My guess would be this carried over from code to fix the bug with this occurring on DOS levels. Since the two have long since been completely seperate pieces of code, there's no need to keep DOS bugfixes in the NeoLemmix save routines, especially if they're causing bugs in the NeoLemmix saving.
Will upload a fix right away. Thanks for letting me know.
[I haven't tested this yet on the latest version of the editor yet but if I don't post about it now I'll forget about it]
I extracted and used the cheapo style Super Mario with NeoLemmix and they seemed to work just find in the editor and play test. Until I saved and closed the level and reopened it later; it says: style not found. ???
Two things to check:
1 - Did you place it in the "Cheapo Styles" folder or the "NeoLemmix" folder? Either is fine, but you must choose the same one from the list when loading the level.
2 - How long is the filename of the style (in DAT format)? It shouldn't be more than 16 characters (not including the .DAT extension). If it's longer, rename it so that it's exactly 16, and it should work. (If the current name, when cut down to 16 characters, would end with space(s), then leave the space(s) off.)
I double checked both of those things, didn't work. I tried making a new level in the Cheapo style "ISWorld" I made a simple level and it played fine. But when I closed and tried to reopen it the same thing comes up.
I attached this level and both styles.
the same thing happens with the latest version btw, I finally checked
I found the issue. For some reason, it's treating the graphic set names as case-sensitive even though it shouldn't.
If you rename the graphic sets to "isworld" and "smb" (rather than "ISWorld" and "SMB"; notice the new names are entirely lowercase), they will work. This isn't meant to happen though - it shoudln't be case sensitive at all - so I'll fix this in the next update; this is just a workaround for now.
I would also suggest, if you haven't made too many levels in them yet, use the new graphic set format (single DAT file) instead of the old one (G_xxx / V_xxx). The reason for this is that the old one adds extra width to pieces due to that all pieces must have a size divisible by 8; the new format doesn't have that limitation. If you must work with the old one for now, avoid using the horizontal flip feature on terrains/objects.
An update that fixes this bug has now been released. :)
So, I've been working on a much tidier gimmick selection menu for the next editor update. This will be especially important if the list of gimmicks continues to grow, but even as-is, it's a bit tidier.
The checkbox (hidden behind the dropdown) simply says "Activate This Gimmick". The panel below it is "Gimmick-Specific Settings" which would be used to set, for example, the target level for bait-and-switch (these will no longer hijack other settings as of the next update; V1.34n-B onwards already support loading such levels, but I wanted to wait a bit longer before adding it in the editor so there isn't as much of a need to urgently update both the editor and the game). At the moment, I haven't added anything to the Gimmick-Specific Settings panel yet.
I'll just make a note - any levels made with editor V1.35n-A onwards will not be fully compatible with versions earlier than V1.34n-B. I say "fully" because they will generally work - it's only a few specific things that won't (levels that use bait & switch or clock gimmick won't work properly, and secret levels probably won't redirect to the intended normal level; anything outside of that should work fine). It won't be anywhere near as major an issue as previous changes to the level format - that's one of the great things about the current format, it's designed to be expandable with little if any impact on loadability by older versions. (The current graphic set format is also similarly designed to be expandable, as is the planned new MAIN.DAT format.)
EDIT: Setting times for the clock gimmick is now working! :) And, more importantly, it is now completely isolated from VGASPEC settings! :D
EDIT: And so is bait-and-switch, completely independant from oddtabling settings. :) Uploaded an updated screenshot.
Since I'm probably not going to officially support music-by-name just yet, the only thing left to do is implement editing the goto rank/level for if the level's a secret level (since they don't generally send you to the level immediately after them, but to a different level; previously this level was specified via the oddtable settings (but without actually turning oddtable on), but that data is now completely seperate; I still need to implement support for editing it, as currently it's only preserved by the editor, not modifiable).
Re: currently noted suggestions
Quote> Better music track selection
Next on my to-do list once implementing the new features is done. Probably will make it into the -A release.
EDIT: It's done. Check the screenshot attached. :) The "Master System Music Pack" checkbox is because there's 4 tracks on the Master System version (and thus, in that version's music pack) that aren't in other versions, so it modifies the list to have their names. The positions of them in the track order in the NeoCustLemmix music pack is the same as those of the missing tracks, so nothing that
is in both versions gets reordered.
(The display of an (incorrect) name in the disabled Music File textbox is just a display glitch, and has no bearing on the actual level.)
Quote> Quicker changing of terrain piece / object types
IIRC, Mobius suggested this one. So, Mobius - or anyone else - what would you like to see in this regard? I'm happy to look into it, but I'd like to know what exactly you'd like to see.
Quote> More user-friendly setting of S-value / L-value based object properties
This one is probably going to sit on the "todo" list for a while longer.
Just a minor thing, but in the level skillset window, it still say Mechanic instead of Disarmer.
Yep, I noticed that the other day. The same thing applies to the quick-select dropdown for pickup skills. Will fix it in the next update. :)
Quote from: namida on June 12, 2015, 03:05:25 AM
Re: currently noted suggestions
Quote> Quicker changing of terrain piece / object types
IIRC, Mobius suggested this one. So, Mobius - or anyone else - what would you like to see in this regard? I'm happy to look into it, but I'd like to know what exactly you'd like to see.
well, 1 simple idea is to have the mouse wheel scroll through the list [without opening the list or with idk] and change the piece automatically with each scroll. Since mouse wheel is also used for zooming maybe hold down control or something. Personally I don't need the wheel to zoom in the editor. [Normally that's an important thing for me but in this case for some reason it isn't]
idea 2; make the pop up menu larger so more pieces can fit inside and you can look at more at a time. Currently looking through the list is dumb and time consuming.
If I playtest a level in NeoCustLemmix, it saves a "temptestlevel" in the same folder as the editor and NeoCustLemmix.
The test mode I am using is "Preview + Postview".
this happened before on an older version of the editor.
I just tested it now but I didn't have this problem. I have version 35 C.
I don't know what version of player but it's not the latest.
Quote from: DynaLem on June 26, 2015, 03:15:45 PM
If I playtest a level in NeoCustLemmix, it saves a "temptestlevel" in the same folder as the editor and NeoCustLemmix.
The test mode I am using is "Preview + Postview".
Yes. NeoLemmix Editor has no way to detect when playtest mode stops running, so it just leaves the level there (the file is saved so that the player can load the level, as I'm not entirely sure how to communicate between the two otherwise). While I could make the player delete the level once it's loaded, there's been more than a few times that I personally have been glad the file was still there, and it's a 10KB file at most so it shouldn't really be a huge deal?
I could possibly look for some way to get rid of its persistance if anyone feels it's really a major problem.
Quote from: möbius on June 26, 2015, 09:10:14 PM
this happened before on an older version of the editor.
I just tested it now but I didn't have this problem. I have version 35 C.
I don't know what version of player but it's not the latest.
Not sure what you're referring to here?
nevermind I was being stupid as usual. This isn't a problem.
Would it be possible to have the editor remember which window panels are placed where? I always have the same setup (left square skills, middle bar inspector, right bar room settings), and it'd be very convenient if you could set a standard setup like that.
Whenever I Validate Level, it always sas "Object X/Terrain X refers to an object/terrain piece not found in the current graphic set" for every single object and terrain piece. When I click "Fix All", everything gets deleted. I have no idea why it does this, when the level actually works very fine.
Will check that out. I haven't tested that feature in quite a while, so it's very possible something's broken in one of the updates.
@607: I'll look into it. I don't know if I can make them snap back onto the panels, but I should at least be able to set their on-screen coordinates to what they were last time the editor was used.
The hot keys don't want to work, they work until i put in the tools for editing the levels
i want to use the cheapo set for Resident GigaLems so added preplaced lemmings into those tileset would be perfect
DynaLem: Are you building Lemmini levels? I had this problem, too. I think it has something to do with how Lemmini graphic sets work in that it uses multiple images for the different tiles, and uses masks for which parts of the tile are actually solid.
Suggestion: I'm not sure how easy this would be, but maybe allow the inspector window and such things to be changed in size(e.g. you can stretch it and the input boxes would move with the stretching). I seem to have a hard time having to move all of the windows around instead of being able to just dock them(if I dock them I can't see half of the options, and if I pull up the place where you do dock them it covers almost half of the level). If that would be too hard/time consuming to do, could you possibly simply rearrange the input boxes/labels so that it wouldn't be so vertical?
Could you maybe also make the trigger areas show up for Lemmini objects? It's really hard not to be able to see if a trap will work or an exit trigger.
These are just things that would be nice to have; they aren't necessary.
Quote from: exit on July 30, 2015, 04:04:54 PM
DynaLem: Are you building Lemmini levels? I had this problem, too. I think it has something to do with how Lemmini graphic sets work in that it uses multiple images for the different tiles, and uses masks for which parts of the tile are actually solid.
I'm actually building NeoLemmix levels. Looks like the Validate level affects
all tilesets, whether (Neo)Lemmix or (Super)Lemmini.
That's interesting. :-\ But namida did say that he hasn't used/tested it in a while(and I don't think he's changed any of the code behind it), so if NeoLemmix has a different graphic set format, which I think it has, the tool probably doesn't know how to handle the new graphic sets.
The code for handling graphic sets within the editor is format-independant once they're loaded; but there's definitely something not working correctly with the validate level.
I haven't updated the editor in quite a while, but that doesn't mean I don't plan to - once V1.35n-C of the player is out of the way, fixing up these issues with the editor is the next task.
In regards to trigger areas in Lemmini sets - this should be doable as long as they're rectangular shaped. I'm not entirely sure if Lemmini requires them to be (although all graphic sets so far, they are rectangular); it'd be more hassle than it's worth to make the editor handle non-rectangular ones. I'll look into that.
I have no experience in in ripping sprites from games but...
Can we see a set that has all the Lemmings plus tilesets(plus doomsday)
or one with all copycat lemmings tileset (not the custom converted sets)
Do you mean as in a mixed graphic set, along the lines of the "Epic" Lemmini set? You can VERY easily make this yourself with the graphic set editor - yes, it will take some time, but you aren't going to need to use anything other than the graphic set editor itself, you aren't going to have to work out any coordinates (just use the data that's already there), etc. If you can't be bothered to do this yourself, then please don't assume someone who isn't even interested in using such a tileset is going to do it on your behalf; it's different when you're having difficulty with something, but since this is pretty much a matter of "save image, take note of properties, import image into new graphic set, enter identical properties", I find it very difficult to believe you'd have any trouble for any reason other than that you aren't trying.
Because of the plans to make a new editor for V2.00n, I'm going to put the editor (and all tools, for that matter) under the same status as the main game. In other words;
- Generally, there won't be any updates just to add new features or optimize how things work.
- Any game tool-breaking bugs can have updates to fix them. This can apply even in cases where "it doesn't quite work as it should, although a workaround does exist", especially if doing things in the "normal" way can cause issues that aren't immediately noticable.
- Less-severe bugs will not get dedicated updates just to fix them, but may be fixed alongside more significant ones if there's an update anyway.
Quote from: namida on June 12, 2015, 03:05:25 AMQuote> Quicker changing of terrain piece / object types
IIRC, Mobius suggested this one. So, Mobius - or anyone else - what would you like to see in this regard? I'm happy to look into it, but I'd like to know what exactly you'd like to see.
What I hope to see for the 2.0 editor is something closer to Lix or Cheapo, where the available terrain pieces are presented in a grid and you can immediately click on any desired piece. The Lemmix editor's terrain selection is a huge hassle to use, which is a big disappointment when NeoLemmix has improved on Lemmix in so many other regards. If we got an improved editor, I would definitely be looking forward to having a go at making a NeoLemmix pack when 2.0 comes out.
The other big problem with the editor is that only the top half of the screen is used, so you can't see what a level looks like as a whole unless you zoom really far out -- which is not a convenient mode for placing further pieces.
Quote from: Proxima on September 04, 2015, 05:21:56 PMWhat I hope to see for the 2.0 editor is something closer to Lix or Cheapo, where the available terrain pieces are presented in a grid and you can immediately click on any desired piece. The Lemmix editor's terrain selection is a huge hassle to use, which is a big disappointment when NeoLemmix has improved on Lemmix in so many other regards. If we got an improved editor, I would definitely be looking forward to having a go at making a NeoLemmix pack when 2.0 comes out.
So to be clear, the problem was mainly that the current selection UI is using a vertical single-column list instead of a multi-column grid, or is it other factors? One thing I remember people complaining about the Lemmix (not NeoLemmix) editor was the "insert terrain" command not directly bringing you to the selection screen to let you pick the terrain you want to insert. Then again maybe that's only for Lemmix editor and was already fixed in the NeoLemmix editor.
Quote from: Proxima on September 04, 2015, 05:21:56 PMThe other big problem with the editor is that only the top half of the screen is used, so you can't see what a level looks like as a whole unless you zoom really far out -- which is not a convenient mode for placing further pieces.
So basically sounds like you want a minimap in the editor. That's a pretty good idea considering that most levels are probably much longer than they are tall, so most of time some vertical portions of the screen will be left unused. I guess this suggestion could also apply to Lix's editor?
An alternate solution could be a special zoom-out button/hotkey that immediately zooms out far enough to fit the entire level on the screen, then invoking button/hotkey again will restore the previous zoom level. So you can quickly glance at level-as-a-whole and then just as quickly go back to where you were before.
Simon has vented his rage on the NeoLemmix player, so I may have my own little rant about the NeoLemmix editor ;).
1) Missing documentation
There is no readme file coming with the editor, explaining all the buttons, menus, ... (and I don't know whether one actually exists). Some examples, what should be explained even for people that know the original Lemmix:
- All options in File-Settings
- There is a unlabeled box under "Index" in the Inspector menu.
- What are "S Val" and "L Val"? What "Reset ID"?
- There is a drop-down menu at the bottom right of the Inspector menu. What does it do?
- System.Dat Editor? Huge pile of options and only some are self-explanatory. For a new user, it is not even clear what this whole editor can be used for! And isn't there a barely visible textbox at the very bottom?
- "Help" does not help, but gives the credits. Perhaps give some in-editor help/explanations here?
- What does "Validate Level" do exactly? How does it fix which issue?
- There are some grey boxes in the lower half of the editor. What are they there for?
- ...
(many of them are rhetorical questions for me, because of dedicated experimentation - so no need to answer them here)
2) Remove "Selection" from the top bar and replace it by "Windows" (or something similar)
I rarely need the "align" function, but frequently want to open the skill window, inspector window, ... So I would prefer moving the "align" functions to the bottom of "Edit" and move all the windows to a separate drop-down menu. Then the "View" menu would be much smaller.
On a related note:
- Why is "Dos Levelpack Editor" under "View" and not under "Tools"?
- Is "Align to grid used by Dos" really needed anymore? You cannot save levels in the old Lemmix format anymore, can you?
- Minor point: The order of the window options and view options does not coincide with the order of the FX-keys. Perhaps they can be ordered within the drop-down menu to reflect the order of the FX-keys (though the pairing between options and FX-keys should be kept).
3) Revamp Skillset window
- Currently some of the less used skills are quite at the top of the window (like disarmer, swimmer and stoner), white important ones are at the bottom. The ordering possibly reflects the ordering in the skill panel later on, but here it is more important to find much-used skills easily.
- The miner is far away from basher/digger and floater/glider could be next to each other as well. You probably intended this window to be read horizontally, but with the clear separation into two colums, I always read it vertically.
- Minor issue: Could you fix the internal order of the boxes. Hitting tab gives a random walk around this window ;). At least all the boxes with the number of skills should be consecutive when hitting tab.
4) Revamp Gimmick window
- About half of the space is taken up by two gimmicks that are rarely used (and that I did not even know about before seeing them here). This space could be used much better by displaying a short description of the current gimmick. If one selects the clock gimmick or bait-and-switch then it may still display the additional options, but otherwise it is simply uninteresting.
- The drop-down menu to select the gimmick shown only 8 out of 44(?) gimmicks in total. It would be better to show a larger number of gimmicks at once.
-whatever you do, please don't get rid of the align function; I use that quite a bit.
-how about the option to have all of the menu windows [like skill menu, stats, terrain selection] appear automatically when you open the program. Currently; every time I open the editor I press the F7-F10 or whatever to make them all appear and re-arrange them in the bottom bar.
-I don't think you need a "windows" menu, just eliminate the "selection" menu altogether and put the align function in either EDIT or TOOLS.
Just a reminder of some issues which aren't exactly issues anymore but could be something to keep in mind when you're working on it;
-the copy/paste bug which apparently only I have..
-the bug which makes keyboard buttons stop functioning in the editor when you re-arrange the sizes of the bottom panels.
Since I'm planning to do a new editor with V2.00n, I'm not going to make any major changes, but I can take into account some of the minor ones (and your suggestion for more documentation - actually, there's some on the NeoLemmix website, though it's very out of date at this point). Many of these complaints are simply stuff that was never changed from the standard Lemmix editor.
Quote- Is "Align to grid used by Dos" really needed anymore? You cannot save levels in the old Lemmix format anymore, can you?
Yes, you can. Choose the "CustLemm" style instead of the "NeoCustLemmix" style when picking graphic sets. It automatically decides based on the
style whether to save as NeoLemmix LVL or DOS / Lemmix LVL.
Quote- Minor issue: Could you fix the internal order of the boxes. Hitting tab gives a random walk around this window ;). At least all the boxes with the number of skills should be consecutive when hitting tab.
A lot of sections have unpredictability when the tab key is involved. This is because many of them are very difficult to make modifications to (basically, all has to be done by editing a text file, rather than the GUI form designer) due to them using components that exist in the editor's source code, but the Delphi IDE has no knowledge of. I have no idea why EricLang decided to do this when designing the editor; perhaps he designs all his forms by text rather than through the IDE (in which case it wouldn't matter too much).
Quote from: namida on September 29, 2015, 12:00:23 AM
Since I'm planning to do a new editor with V2.00n, I'm not going to make any major changes, ...
Sounds sensible.
Quote from: namida on September 29, 2015, 12:00:23 AM
... but I can take into account some of the minor ones (and your suggestion for more documentation)
Currently there seems to be no link to your help page on the forum. So I would suggest:
- Adding a link to the help page to the "NeoLemmix Info, Downloads, Etc" topic.
- Making a .txt or .pdf-file with all the documentation and adding it to the dropbox folder with all the editors. Alternatively zip it to the .exe of the editor.
Of course all of this can wait until you have the V2.00 editor, if that saves you work.
As a user I prefer documentations that are stored locally on my computer to ones that on the web (especially if I have to search for them each time).
Quote from: möbius on September 28, 2015, 09:50:50 PM
-how about the option to have all of the menu windows [like skill menu, stats, terrain selection] appear automatically when you open the program. Currently; every time I open the editor I press the F7-F10 or whatever to make them all appear and re-arrange them in the bottom bar.
Not too fond of this suggestion, due to my different style: I usually have one big window displaying the level (with the grey boxes at the bottom reduced to minimum size) and only the inspector window open as a separate window. Having more windows open would only require screen space that has better uses.
I don't use the three docks for the windows. I like to work at a 1 to 1 display when making levels and use almost all the vertical space available in the main window for the level. Usually I have the inspector, level properties, and skill set windows open and off to the right of the main editor window. I would like to be able to dock the smaller windows to the left or right of the editing area, instead of what I do now which is having them float off to the side.
Quote from: Nepster on September 29, 2015, 04:26:44 PM
Quote from: möbius on September 28, 2015, 09:50:50 PM
-how about the option to have all of the menu windows [like skill menu, stats, terrain selection] appear automatically when you open the program. Currently; every time I open the editor I press the F7-F10 or whatever to make them all appear and re-arrange them in the bottom bar.
Not too fond of this suggestion, due to my different style: I usually have one big window displaying the level (with the grey boxes at the bottom reduced to minimum size) and only the inspector window open as a separate window. Having more windows open would only require screen space that has better uses.
I meant to have the menus appear IN the grey boxes at the bottom. I always put them in there; it's convenient; there are out of the way. I never have them as separate windows. The grey boxes make the whole screen space work very nice for me, I'm frankly surprised that apparently not many other people use them? ??? There is still plenty of space above for the picture of the level.
Granted it works nicely if you're only making mostly horizontal levels like Traditional Lemmings. On that note: I've never been a huge fan of vertical or huge levels. I've liked a small few but I just prefer the classic style.
IchoTolot and GigaLems have additional styles (L2/L3 resp. Epic) for NeoLemmix. Why aren't these automatically included in the CustLemmixNeo download (assuming that IchoTolot and GigaLems are fine with it)?
(Less work for user to download, ... = more chance for users to use it)
Edit: Remembered that styles come with the player, not editor. @namida: Could you please move this to the player suggestion thread? Thanks.
They actually have to currently be included with both (the editor's copy is only useful to the player if manually copied/pasted to it, or when using playtest mode). I shall take into account the suggestion of including them all by default and, assuming there's no significant objections, do so from the next update.
EDIT: Got the okay from DynaLem to include his ones. Just waiting on IchoTolot's.
Have you ever thought of Traps that activate in the water
Another friend of mine is making a tileset for me to use, and has an idea for a trap for water, and has made a few sprites for it
Hopefully this is possible for for neolemmix and its editor to have a trap that will kill lemmings if they try to swim through it
As for the WIP here is what it looks like
and of mock up of what is could look like in action
Quote from: GigaLem on November 08, 2015, 08:54:53 AM
Have you ever thought of Traps that activate in the water
Another friend of mine is making a tileset for me to use, and has an idea for a trap for water, and has made a few sprites for it
Hopefully this is possible for for neolemmix and its editor to have a trap that will kill lemmings if they try to swim through it
As for the WIP here is what it looks like
and of mock up of what is could look like in action
Good idea :) , but:
The trap must be visible! Like a little hand looking out of the water.
It doesn't need a special object type. Just make it a trap, as usual. It will work.
My friend has made more progress
-New entrance
-New trap
-and some refrences used
I should have reported this error a long time ago...
Validate level still doesn't work, and gives that (pesky) List index out of bounds error again.
Hm, it's working for me on some levels, but not on others. I'll have to look into this and find out exactly why.
EDIT: I sent you a test version that should have fixed this issue, let me know. :)
By the way - while this has kind of been unofficially my policy for a while anyway, I'm now officially reducing the status of SuperLemmini support from actively supported, to the same "passively supported" status that Lemmix and Lemmini have - ie: I won't generally go out of my way to support new features (if any are added to SuperLemmini), and won't actively test for bugs myself; but will still try to fix any bugs that get reported in relation to SuperLemmini levels. The reason for this is quite simple - SuperLemmini has not caught on at all; with only a few people using it, mostly only to play levels rather than actually make them. Thus, it doesn't make sense to try and actively support an engine that no one really uses. Of course, I'm open to reversing this decision if SuperLemmini does suddenly spring to life.
This does not mean that SuperLemmini support will be removed - it will stay there, and bugs will be fixed if reported. It just means I won't make a special effort to keep up with new SuperLemmini features, or actively test for bugs that are exclusively related to SuperLemmini editing.