Sometimes, if you have a level saved in C:\[path to lemmix folder]\[another folder], Lemmix gets the paths in LemmixSyles.ini (or something like that) mixed up until the program is closed and reopened, which is probably the cause of a problem I posted (but I deleled the topic, because it fixed itself).
By the way, if anyone wants to know what the actual problem was? It was that Windows sucks.

The previous glitch was caused by a copy/paste error in Windows when Lemmix complained that it could not find the GROUNDxO/VGAGRX files, so I pasted them into the folder where the levels were saved.
Oh crap. I think my sets actually DID corrupt. I can't find the steel pieces in the Bubble set. Or maybe it doesn't have metal blocks (though that would be awfully odd...)?
Have you ever seen steel blocks in a bubble level? I certainly haven't.
They don't exist.
hahahahaha, I can't believe I never noticed that before.
WELL THEN... I'll just steel up the sides.
OK, I have another (possible) bug. The F12 key doesn't work in the editor, or am I wrong?
Do you mean the playtester, or the editor screen itself? F12 on the editor screen is supposed to bring up the "Map editor" - but the map editor is always open. Lemmix
is the map editor
I see, so that's why I think it's broken, and I
was talking about the editor.
Now it's my turn to have problems with Lemmix.
I have a huge problem with opening Oh No! styles. I load a first Oh No! level (let's say it's a brick level), and it opens fine. When I try tp open another brick level, it complains that it can't find the style. I close Lemmix, check LemmixStyles.ini, and find that Lemmix has changed the brick style from GROUND0O.dat to GROUND5O.dat (The same is true for VGAGR0.DAT, changing to VGAGR5.DAT). I revert the changes, and try again. It opens the first brick level fine, then the same thing happens when I try to open a second one. I'm getting tired of having to close Lemmix, save LemmixStyles.ini, and reopening it every time I want to load two or more brick style levels. And it's not just the brick styles. The same happens to the other three, adding 5 to its respective GROUNDXO.DAT and VGAGRX.DAT files.
Does anybody have any idea why this is happening, and how I can fix this?
EDIT: I solved the problem by reinstalling Lemmix, and setting everything up. I wonder why it happened in the first place?
Hmm, if this happens again, might setting the file to READ-ONLY work?
Thanks for bumping this, I just remembered something that I keep forgetting to post.
Overlapping objects don't display correctly. More specifically, they display one way in the editor, and the other way in playtest mode, so of course it must be wrong in one of them. (I don't know which though

) I recommend looking at Blitz 3 if you want to see this for yourself. This appears to happen if both objects or neither has "no overwrite" selected - when one is on "no overwrite" they display correctly.
Run the level in Custom Lemmings. That *should* tell us the answer to which one it is.
Overlapping objects don't display correctly. More specifically, they display one way in the editor, and the other way in playtest mode, so of course it must be wrong in one of them. (I don't know which though
)
I specifically remember Wicked 19, which has a trap overlapping with the exit, looking distinctly "more wrong" in one of the modes (I think it's playtest mode, but I might've remembered wrong). Then again, the
screenshot at Lemmings Encyclopedia shows that maybe it doesn't look perfect in the actual game either, so maybe the "more wrong" mode is actually the more accurate mode?
I'm pretty sure actually that neither mode is 100% correct. For example, if I remember correctly, in the actual games the no-overwrite flag actually still overwrites pixels that use the lower half of the color palette (ie. 0-7, normally not used by terrain but may be used by objects). I don't think I ever communicated that to Eric so I doubt Lemmix handles that aspect accurately, for example.
Have you ever seen steel blocks in a bubble level? I certainly haven't.
They don't exist.
Indeed, which is one of the reasons I don't use this set very much.