Post by: GuyPerfect on September 16, 2009, 12:08:14 AM
In this case, though, I want to construct a simple system that incorporates several smaller systems into a singular workload processor. And the exercise is one I'm sure will be welcome in this community: Lemmings level editors!
Normally, level editors would be standalone programs, but I'd like to devise and implement a system that binds multiple editors together into a single structure, while still enabling individual parts to be detached or new parts to be introduced later on. This means I'll be able to work as hard as I want and once I get the system working, I don't have to do any more if I don't want to. (-:
Of course, the other side of that coin is that I can introduce new editors whenever I make new modules, so it should eventually become some sort of all-encompassing project that this community will be able to hold up to the rest of the internet and brag about. What fun!
I know that this project will be stepping on some toes, and I apologize for that in advance. If you've been working long and hard on a level editor for a Lemmings game and I come along and one-up you or your loved ones, bear in mind that it's all in good fun and in the name of computer science... Besides, I'll be back to making Metroid before long, so other people's toes will be stepped on instead of yours. (-:
Regretably, I'll be doing Lemmings the first first. It always gets all the attention! But, alas, it is likely the simplest, so it would be the best place to start.
Post by: ccexplore on September 16, 2009, 12:32:06 AM
).What I'm confused about is whether you're just trying to make the level editor as extensible as possible (but still requires programming in C to actually extend it, in which case I'm not sure if it's any better than just open sourcing), or whether you're trying to create a meta-system that somehow allows multiple otherwise independent programs to work with each other (sort of an integration of a number of separate tools). Or maybe both.
I'll warn you though, IMHO LemEdit and Lemmix has set the bar fairly high for this. I frankly won't worry about "stepping toes"; just worry that you will find someone's toes to step on in the first place
(that is, make sure your level editor is compelling enough for other people to even bother switching to using it in the first place).
Post by: GuyPerfect on September 16, 2009, 12:49:37 AM
Post by: ccexplore on September 16, 2009, 01:32:24 AM
, you could probably reuse a lot of the same code for the different editors. It wasn't clear from your first post that you were targeting a number of games in the Lemmings series.Well in that case, for anything else besides Lemmings/ONML/Holiday Lemmings, I don't think you need to worry about stepping toes since I don't think there's anyone there yet.
Post by: namida on September 16, 2009, 08:39:15 AM
Post by: Clam on September 16, 2009, 09:01:14 AM
Post by: GuyPerfect on September 16, 2009, 09:59:02 AM
Having said that, I do have a question. I've written a parser and decompressor for the Lemmings .dat files, and I'm noticing a shortage of levels. There are 10 level files each with 8 levels inside, making 80 total levels. But the game has 120. Where'd the other 40 go?
EDIT:
Hold that thought. ODDTABLE.DAT seems to contain information for re-using level terrain. A quick search for the word "Ozone" told me all I needed to know. (-:
Post by: namida on September 16, 2009, 10:15:34 AM
Post by: GuyPerfect on September 16, 2009, 10:02:19 PM
In particular, I found that they used a commercial utility called PKLITE, which compresses the contents of DOS executables (be it .EXE or .COM) and packs them into a new .exe with the decompression code at the top. When the program is run, it decompresses the original program code and loads it into memory, then transfers program control to it in an invisible process that has no effect on the execution of the original program. A side-effect of this process is that executables packed in this manner cannot be decompressed like data files, which makes accessing the information within the Lemmings executable impossible without running the program itself, and that throws a wrench in the works in my efforts to create a level editor for the game.
In order to properly hack this game to suit my unbearably high standards, I will not only require access to the contents of VGALEMMI.EXE, but also must be able to create a new version of the file consisting of any changes made during the edit process. Fortunately, the structure of a DOS program is fairly simple and there is nothing insurmountably difficult in reconstructing the original VGALEMMI.EXE file by interprating the code in the compressed version. It is, however, an involved process that will take a lot of time to implement, and I must save it for some other time.
Subsequent Lemmings games do not have this limitation. Their levels are stored and sequenced in individual files. Much to the delight of he who thinks clams have big eyeballs, I will now be turning my attention to Lemmings 2.
Post by: chaos_defrost on September 16, 2009, 10:47:18 PM
Post by: Dullstar on September 17, 2009, 12:37:55 AM
Post by: Clam on September 17, 2009, 12:46:11 AM
Oh, sweet!
I'd better get the pencil and paper out and start doodling...
Post by: Dullstar on September 17, 2009, 12:47:50 AM
Make a Linux version!!!
Post by: GuyPerfect on September 17, 2009, 01:08:46 AM
Also, the compression scheme for the Lemmings 2 levels is hecka funky, but I'm *this* close to cracking it. I should have something to show by the end of the day.
Post by: Dullstar on September 17, 2009, 01:11:12 AM
So, what coding do I need to make my game? I swear most tutorials on the Internet are crap. What good is just listing the code without explaining the structure any?
Post by: GuyPerfect on September 17, 2009, 01:46:39 AM
The part that was throwing me off is that symbols can be redefined as the decoder works down the definition list. With the example above, I can re-define 0x03 as 0x04 0x04, which overwrites the old 0x03 definition with the new one: 0x12 0x34 0x56 0x12 0x34 0x56. So now we have a one-byte symbol that represents six bytes.
This dynamic setup makes the task of coding an optimal compressor quite a daunting one that will take many hours or even days of careful engineering to design and implement...... ooooooor, I could just store new level data in the files as raw data and bypass the dynamic symbol list altogether. I mean, we're not interested in saving file space, right? Just patching new levels to the game? (-:
I'll write a decoder and simple raw encoder and see about getting an 8-bit paletted OpenGL context set up. I still need to hack the graphics, but it won't be long before I can display levels. And then it's just a little interface programming before we can make levels.
Concerning your question, Dullstar, it's something that can take up a whole 'nother thread, so I'll have to get back to you on that.
Post by: Dullstar on September 17, 2009, 02:01:36 AM
Post by: ccexplore on September 17, 2009, 03:55:13 AM
In particular, I found that they used a commercial utility called PKLITE <snip>
You really should learn to use the internet better, instead of just reflexively sneer your nose at things like say Wikipedia or the C FAQ (I do understand your reasonings to be skeptical and it's good to have a healthy dose of skepticism, but still...)
In the case of pklite, a quick search with Google or similar years ago quickly led me to a program called "unpklite" which will readily undo the compression of PKLITE on the Lemmings executable. This is how I managed to reverse engineer enough of the game to accurately reproduce the game mechanics for benefit of projects like Lemmix's playtesting features (as well as the all-important compression algorithm for the game's data files).
I should note though that for some reason unpklite fails to work on Xmas Lemmings, and I still haven't found a program that works. But if you have a debugger, it looks like a close enough alternative would be to just run the program through a DOS debugger, and then examine the memory after the program exits--most if not all of the code, in uncompressed form, will still be there.
That said, like Clam, I'd rather you work on Lemmings 2 anyway. And I probably can answer all the questions you may have on Lemmings 1, given that I've done a whole bunch of reverse engineering of the EXE already. (Plus, some of the information like the formula for passwords to next level is actually already information available in, you guess it, the internet.)
Post by: ccexplore on September 17, 2009, 04:02:04 AM
This dynamic setup makes the task of coding an optimal compressor quite a daunting one that will take many hours or even days of careful engineering to design and implement...... ooooooor, I could just store new level data in the files as raw data and bypass the dynamic symbol list altogether. I mean, we're not interested in saving file space, right? Just patching new levels to the game? (-:
I agree. Compression was mainly for the era when games still ship in floppy disks. Unless the poorly compressed data is causing problems with the game, I suggest start simple and come up with the simplest compression scheme that works, no matter how suboptimal it is space-wise. LemEdit for example have a similar poor compression scheme compared with the actual game's, and that hasn't hurt anything.
Post by: GuyPerfect on September 17, 2009, 04:49:27 AM
You really should learn to use the internet better, instead of just reflexively sneer your nose at things like say Wikipedia or the C FAQ (I do understand your reasonings to be skeptical and it's good to have a healthy dose of skepticism, but still...)
Holy grudge, Batman! That thread almost made it out un-jacked!
While you may have perfectly valid and substantiated assertions that I am incapable of conducting significant independent research and am afflicted with ethical depravity for failing to embrace a subjective work as a basis for one of my philosophies, I'm afraid you are nonethless missing the point.
If my goal consisted entirely of producing level editors for Lemmings games, I'd hunt down all manner of existing documentation and tools that do the hard work for me so that I don't have to do it myself. However, I find much joy in hacking these things, and the true reward for me comes from creating systems that take everything I've learned into account to accomplish whatever thing I was after in the first place. That is to say, I'm in it for the hacking, not the level editing.
Decompressors already exist for Lemmings and Lemmings 2 (heck, I was easily enough able to find documentation for the algorithm used in Lemmings), but I have nonetheless spurned such solutions in favor of figuring things out on my own. It's fun on the one hand, practice on the other, and the whole exercise is one that I greatly enjoy. But since I'm not after the decompressed data itself--and indeed, not after the decompressed executable--it's not a matter of knowing how to use Google; it's a matter of using the opportunity to put my skills and one of my favorite activities to good use.
With an unPKLITE'd Lemmings program file, any edits wouldn't fully be something that I've done, and that's one of the bigger points of doing this in the first place. I wish for my efforts to be comprehensive in hacking these games, and that's not something I can do without programming it into the project myself.
IN OTHER NEWS...
I've got a decompressor written up for Lemmings 2. I accidentally pulled a Nintendo and wound up using strncpy() instead of memcpy() in one spot, but found out what was going on during debugging. Making a raw data encoder was a trivial accomplishment, so the next step is graphics. I'll do that tomorrow, though... Been staring at hex numbers all day.
Post by: ccexplore on September 17, 2009, 06:12:40 AM
Just remember that when/if you do get tired of it, and you're still philosophically opposed to using unpklite, remember what I told you about examining the memory after the program has run--let pklite unpack the program for you. (Not sure where that falls under your philosophy......)
I accidentally pulled a Nintendo and wound up using <snip>
I have to admit I never heard that expression. What debacle of Nintendo's is the expression specifically referring to?
Post by: Simon on September 17, 2009, 12:51:15 PM
I've written DAT decompressor code, with using the available docs. But it was just because the existing tools were either under the GPL or the ask-ccexplore license, both too restrictive for a WTFPL project.
Good luck on L2, I'm looking forward to your results.
-- Simon
Post by: GuyPerfect on September 17, 2009, 05:24:26 PM
I have to admit I never heard that expression. What debacle of Nintendo's is the expression specifically referring to?
Looking up what happened in the first place, it seems my recollection was a bit off. Nintendo's fluke happened with using strcpy() instead of strncpy(), but the resulting bug was still because of assuming 0x00 as a null terminator.
What happened is that people loaded up their Twilight Princess save file in a hex editor and changed the name of their horse to something that didn't end with 0x00. The game loaded the horse's name with strcpy(), which doesn't check the length of strings, and the result happened to end up as a stack overflow. While I'm not intimate with the coding of the game, I'm aware that this enabled hackers to execute their own code from the SD card, which was how homebrew on the Wii was originally made possible.
My bug came from the behavior of strncpy() in that any "copied" bytes after a null terminator are simply padded up with 0x00 to fill the destination buffer. It ended up making 00 00 9F get copied into a new buffer as 00 00 00. memcpy(), on the other hand, will copy all bytes intact.
Dear holy knight of the char* [...]
That's high lord of the unsigned char*, thank you very much. (-:
Post by: Dullstar on September 17, 2009, 10:22:41 PM
Post by: geoo on September 18, 2009, 02:35:32 AM
A lemmings 2 editor? Oh wow, that would be asbolutely amazing if you made one and I'd probably get back into level editing if that were the case.I love your enthusiasm; I'm not sure whether you were active when I released that provisional Lemmings 2 editor, so just in case not, if the price you are willing to pay for editing levels is high enough (i.e. a user unfriendly interface, having to decompress files first, setting the skillset with a hex-editor), you might try this as a temporary solution - with the afore mentioned issues.
(I intend to start learing to use Qt till the begin of the next semester, and might try re-writing this as an exercise for it. But hopefully anything of that will be made redundand by whatever GuyPerfect will be able to come up with.)
(And finally, sorry for sort of hijacking this thread.)
Post by: GuyPerfect on September 20, 2009, 10:09:24 PM
Anyhow, I've got the level data partially decoded... it's actually more than it looks, but things like palettes and tile pixel arrangements go on behind the scenes and you can't really see how much work that was just by looking at the pictures. But whatever the case, I can now output images of the levels sans steel blocks, water, special objects et al. This is just the normal terrain.
Behold!
What I've decoded:
The original:
Check out those extra tiles on the top and bottom. Intriguing, no? It's always fun to hack levels in video games and see just how much unnecessary garbage there is in the level data that's usually leftovers from level creation. Lemmings 2 is certainly no exception. See all those blocks making up the floor and walls? In the final version of the level, those are steel blocks. Yeah. So them being there is just taking up file space, as the level would play just the same without them.
Take special notice of the few blocks jutting out the top, because they're there for a reeeeeeeally interesting reason. Notice how they graphically connect to the pixels below them? The level designers had pre-set blocks and said "I want a vertical block right about there, going off the top of the screen." The upper part of the vertical block is still stored in memory, though.
Now get this...
The levels, much to my surprise, are not built of these pre-set blocks. They are explicitly defined on a per-tile (in this case, 16x8 pixel) basis. ALL the extra tiles that you'd never see can easilly be removed to allow the data to be compressed more.
Having said that, we seem to be very fotunate in this case. Turns out the developers left those pre-set blocks in the game for us to use! They're completely unnecessary for the program to function, and indeed only waste file space in the end, but they're defined in the STYLES directory and we'll be able to use them in our own levels without doing the work to reconstruct them ourselves.
With those pre-set block definitions, I'll be able to make the editor run a pass through the decoded level data and match up applicable tile combinations with the presets to make level editing MUCH easier. As it is, it's just a grid of 16x8 tiles, and that's not easy to edit at all. If I can do the math backwards and turn those tiles back into block presets, we can move them around just like the level designers did when making the levels in the first place.
This is a rather exciting turn of events that I wasn't expecting, but I am very much interested in making it work. Oh yes, and rest assured that when the editor I make outputs level data to file, it will remove extra tile information that isn't needed. (-:
Post by: Dullstar on September 20, 2009, 11:28:44 PM
Post by: Dullstar on September 20, 2009, 11:31:58 PM
Have you gotten levels in any other tribes decoded?
Post by: Pooty on September 20, 2009, 11:40:11 PM
I have a question... are those blocks actually useless, or do the metal blocks function as visible steel areas (say, if the blocks hidden by the steel weren't there, would the lemmings just fall through?)
The blocks really are useless because the Lemmings will interract with the steel blocks whether there is terrain beneath it or not. Shadow 10, for example, has some steel blocks that you are expected to stand on after you finish pouring glue, but there is no terrain underneath them.
Post by: Dullstar on September 20, 2009, 11:46:28 PM
Man, the solution for Shadow 10 was odd... I NEVER would have thought of the piece of game mechanics used to solve the level. I had no idea it was possible to use a builder as a platform for the glue from the glue pourer to function. Well, if any other levels use that, I won't have to use the Lemmings Encyclopedia to find that out.
Post by: GuyPerfect on September 21, 2009, 12:08:53 AM
[...] I really don't think 16x8 tile grids would be hard to edit.You'd have to pick a cell on the grid, then choose from one of hundreds of tiles to put in its place. And if you want to get adjacent tiles to line up graphically, you're going to have to look at dozens of tiles with similar appearance to find the one you're looking for. Using the presets will make the task of level designing much quicker and more efficient.
What I have in mind will pick out any tile formations put in the level that could be formed with preset blocks, then everything else will be a tile-for-tile specification. Think of the blocks as groups of tiles glued together, though the level in its final form is just tiles.
Have you gotten levels in any other tribes decoded?All levels in the game can be decoded in the manner I'm using right now. The process is incomplete in its current state, however.
Post by: Dullstar on September 21, 2009, 12:21:33 AM
Post by: Simon on September 21, 2009, 01:01:19 AM
It does not appear in the real level. Yet, it's not overwritten by any special object, unlike the yellow bricks behind the water.
Or does the water actually erase the terrain behind it instead of hovering over it?
-- Simon
Post by: GuyPerfect on September 21, 2009, 01:51:32 AM
Post by: Dullstar on September 21, 2009, 02:30:13 AM
Post by: Clam on September 21, 2009, 11:00:44 AM
Check out those extra tiles on the top and bottom. Intriguing, no? It's always fun to hack levels in video games and see just how much unnecessary garbage there is in the level data that's usually leftovers from level creation. Lemmings 2 is certainly no exception. See all those blocks making up the floor and walls? In the final version of the level, those are steel blocks. Yeah. So them being there is just taking up file space, as the level would play just the same without them.
Cool.
If you find any more of this sort of thing, be sure to post it in this thread over here. I found some similarly useless stuff in the original Lemmings levels while playing around in Lemmix.
Post by: GuyPerfect on September 22, 2009, 05:05:22 AM
... until next time. (-:
Got the animation business figured out. Objects in levels can be comprised of multiple animations (such as the flag on the Medieval exit being a separate graphic from the little castle that makes up the majority of the exit), and all the tile references seem to be sorted out now.
The sorry loser who coded the STYLES decoder was either drinking heavily, high on some kind of substance, or most likely some obscure combination of the two. There's one pointer table that simply refers to tiles, see. It's got a number of entries, and the first value is the number of bytes taken up by the tile list, and then there's the tile list. Easy, right? Well, the table that references it uses an offset that pretends those "number of entries" values aren't there at all! It'd be one thing if, say, the third referencing table always referred to the third list of tiles, but it's completely arbitrary, which makes a direct resolution of the exact tile list to read far more complicated than it needs to be. I ended up writing a function that skims through the entire group of tile lists to determine what the REAL data offset is, then wrote THAT into the table instead.
If any of that makes sense, you may share in my anger.
In any case, it shouldn't be too much longer before I get a full image dump of the levels prepared. The day of editing is drawing ever closer.
Post by: GuyPerfect on September 22, 2009, 07:54:05 PM
A cursory glance through the level files suggests that the only thing I haven't implemented yet are the objects that the user interacts with, such as the cannon, the catapault and the chain swing. I'll look into those things eventually (as there are still a few data chunks in the STYLES directory I haven't messed with yet), but I'll easily be able to cheat to make a fully-functional level editor and come back to it later.
Well, hrmm. I guess the next step is to load up an OpenGL app and make an editor, huh?
Post by: GuyPerfect on September 22, 2009, 09:52:12 PM
So if you have anything to say about your fascination with game hacking or how excited you are to be able to make levels for Lemmings 2, get it out of your system now. (-:
Post by: Dullstar on September 22, 2009, 10:58:53 PM
Post by: GuyPerfect on September 22, 2009, 11:22:12 PM
Post by: Mindless on September 24, 2009, 12:21:39 AM
I know that this project will be stepping on some toes, and I apologize for that in advance. If you've been working long and hard on a level editor for a Lemmings game and I come along and one-up you or your loved ones, bear in mind that it's all in good fun and in the name of computer science...
I don't really think this is something you need to worry about. If you one-up lem3edit, I'll appreciate it... I only did enough work on it to make it usable, not user-friendly.
This dynamic setup makes the task of coding an optimal compressor quite a daunting one that will take many hours or even days of careful engineering to design and implement......
I made lem2zip to be an optimal compressor for the algorithm, but I don't expect you'll use it since you don't seem to trust that other people's code can be perfect enough. If you couldn't tell, this aspect of you bothers me. In my book, being self-confident is okay... being condescending is not. And to me, that's the way you come off.
Reinventing the wheel will never make you great; instead, you build upon the work of others. "If I have seen a little further, it is by standing on the shoulders of giants," as Newton put it. Think about it.
That said, I hope to see useful results from this project.
Post by: GuyPerfect on September 24, 2009, 05:06:52 AM
Not anything tangible for anyone not at my workstation, but I've got a level viewer loading up all the game's graphics into the OpenGL pipline and rendering full-level frames for one's viewing pleasure. As you can see, that flamethrower was captured mid-spew, because this viewer does indeed animate objects while you sit there and stare at it.
The editor will show things like water and flames animating while you're editing. What you'll look at is for all intents and purposes what you'll play when you load up DosBox.
----------
I made lem2zip to be an optimal compressor for the algorithm, but I don't expect you'll use it since you don't seem to trust that other people's code can be perfect enough.
[...]
Reinventing the wheel will never make you great; instead, you build upon the work of others.
The purpose is not to do the work. The purpose is to hack and make something out of it. If I make an editor using someone else's hacking notes, I deny myself the first half of the fun. And I'm definitely in it for the fun.
I rarely use other people's code. It's not because I don't think it's of adequate quality; it's because other people's code is not mine. If I use whatever programming to accomplish whatever task that someone else made, I'm denying myself the second half of the fun. And I'm definitely in it for the fun.
Post by: Clam on September 24, 2009, 09:16:30 AM
The editor will show things like water and flames animating while you're editing. What you'll look at is for all intents and purposes what you'll play when you load up DosBox.
Hey, that's a nice touch. Lemmix and other level editors do look rather lifeless...
This is really exciting stuff. I've got a level drawn up on paper already, and can't wait to build it
Post by: geoo on September 24, 2009, 02:42:40 PM
I'm pretty impressed by your fast progress, though considering you seem to be an experienced programmer, perhaps that's to be expected.
I can actually understand why you'd want to re-do the 'hacking' part of it, I also had a lot of fun doing it, while the actual programming part put me off (due to my inexperience with GUIs though). In that regard I'm actually glad that I don't have to do the latter part myself anymore, especially if you can offer something of decent quality as opposed to me.
(Being into algorithms, I can imagine writing a compressor fun as well; not having looked into it, from your description it sounds like Huffman compression?)
I think I can see both points:
Sure, building upon work of others will get you further, and faster to the destination as well.
But if you set your emphasis not on the destination, but the journey, with the final result only considered as a side product, I think reinventing the wheel is totally acceptable for oneself, and has the positive side effect of really knowing your stuff.
Post by: GuyPerfect on September 24, 2009, 07:12:25 PM
You're writing the GUI from scratch (apart from relying on OpenGL)?
I built a cross-platform API for creating and managing windows and OpenGL contexts (as well as enabling the POSIX TPC/IP API and will get around to audio eventually) to run on Microsoft Windows and any installation of Linux running the X Window System. Because of this, any user interface stuff needs to be in my programming and cannot rely on system APIs to produce buttons or menus for me.
Being into algorithms, I can imagine writing a compressor fun as well; not having looked into it, from your description it sounds like Huffman compression?
Not Huffman. It'd be easier to just give you my notes than to explain what else it could be:
Code: [Select]
Data types
String*X A string consisting of X bytes. No null terminator.
Byte An 8-bit, unsigned integer.
UInt16 A 16-bit, unsigned integer. Little-endian.
UInt32 A 32-bit, unsigned integer. Little-endian.
Type[] Indicates an array of type Type. Size may vary.
Format specification
Element Type Size Note
--------------------------------------------------------------------------------
File
====
Identifier String*4 4 "GSCM"
UnpackedSize UInt32 4 Size of decompressed data
Chunks Chunk[] * Compressed data chunks
Chunk
=====
Last Chunk Flag Byte 1 Last chunk 0xFF; 0x00 otherwise
Symbol Count UInt16 2 Number of symbol definitions
Symbol List Byte[] Count Destination symbol names
Symbol Values A Byte[] Count First byte of symbol
Symbol Values B Byte[] Count Second byte of symbol
Data Size UInt16 2 Number of bytes in encoded data
Data Byte[] Size Encoded data bytes
--------------------------------------------------------------------------------
Remarks
There are 256 symbols at all times: 0x00 to 0xFF. Before decoding each chunk,
all symbols should be intitialized to one-byte values matching the symbol ID
itself. That is to say, the symbol with ID 0x00 should represent the byte 0x00
and so-on.
For each chunk, the Symbol List is an array of symbol IDs that will be
redefined before decoding the chunk. All symbol redefinitions come in two
parts, which are stored in Symbol Values A and Symbol Values B. Assuming
concatenation being represented with the + operator, then for each symbol X
from 0 to SymbolCount - 1:
Symbol[List[X]] = Symbol[ValueA[X]] + Symbol[ValueB[X]]
The encoded data bytes are a list of symbol IDs to be copied to the output
buffer. Compression is made possible by the fact that the symbols themselves
can represent very large arrays of bytes.
Example
Consider the following data as a compressed file:
00000000 47 53 43 4D 0E 00 00 00 00 03 00 00 01 02 41 00 GSCM..........A.
00000010 01 42 43 01 05 00 00 01 02 44 45 FF 00 00 01 00 .BC......DEÿ....
00000020 01 .
The first four bytes, 47 53 43 4D, represent the string "GSCM" and the file can
be identified as a Lemmings 2 compressed file. The next four bytes,
0E 00 00 00, specify that the final Unpacked Size of the decoded data should be
14 bytes.
Since this is the beginning of a new chunk, we initialize all symbols.
The next byte, 00, indicates that this is not the last chunk in the file.
The next two bytes, 03 00, specify that there are 3 symbol definitions in this
chunk.
Symbol List becomes 00 01 02
Symbol Values A becomes 41 00 01
Symbol Values B becomes 42 43 01
Symbol 00 is redefined as Symbol 41 + Symbol 42, which is 41 42
Symbol 01 is redefined as Symbol 00 + Symbol 43, which is 41 42 43
Symbol 02 is redefined as Symbol 01 + Symbol 01, which is 41 42 43 41 42 43
The next two bytes, 05 00, specify that there are 5 bytes of encoded data:
00 02 01 44 45
Symbols 00, 02 and 01 are defined as above, which results in the following
being written to the output buffer: [41 42] [41 42 43 41 42 43] [41 42 43].
Symbols 44 and 45 are still initialized to 44 and 45 respectively, which means
only 44 45 is copied to the end of the output buffer to create the following
output: 41 42 41 42 43 41 42 43 41 42 43 44 45.
This is the end of the chunk.
Since this is the beginning of a new chunk, we initialize all symbols.
The next byte, FF, indicates that this is the last chunk of the file. The next
two bytes, 00 00, specify that there are no symbol redefinitions in this chunk.
The next two bytes, 01 00, specify that there is 1 byte of encoded data:
01
Since Symbol 01 was initialized at the beginning of the chunk, it no longer
contains the data it did in the previous chunk. Its current value is simply 01.
This byte is written to the end of the output buffer, creating this final data:
41 42 41 42 43 41 42 43 41 42 43 44 45 01
This is the end of the chunk.
This is the end of the encoded file.
Since this is 14 bytes--the same amount specified in the file header for
Unpacked Size--we can assume that the file was decoded correctly.
Post by: GuyPerfect on September 24, 2009, 10:32:59 PM
Post by: Dullstar on September 25, 2009, 04:28:25 AM
By the way, the way you say you're writing the GUI, I would expect the following OS's to be able to do it:
Linux
Mac OS X
Windows
*BSD systems?
ReactOS?
Some have question marks by them, meaning I'm not entirely sure.
Post by: ccexplore on September 25, 2009, 08:54:19 PM
Those are, by definition, part of the development process. I have no intention of making either of those public.
It depends on how exactly you define "alpha/beta" (such designations make more sense when you actually start with some sort of feature spec of the final product as they do in the commercial software business), but while it's a waste of time for everyone involved to release something to the public that crashes half the time, at a certain point, it would probably be more efficient to shift some of the testing effort from yourself to the general public, or at least to a larger number of users than 1.
Post by: ccexplore on September 25, 2009, 09:15:23 PM
The editor will show things like water and flames animating while you're editing. What you'll look at is for all intents and purposes what you'll play when you load up DosBox.
Hey, that's a nice touch. Lemmix and other level editors do look rather lifeless...
To be fair, Cheapo's level editor also animates the water etc. I do wish more level editors do that, because it's the only way to accurately assess how those objects would look with the surrounding terrain. Even when there's a playtesting feature, it can still be inconvenient when you're still in the middle of doing things like shifting terrain pieces etc.
LemEdit doesn't do it probably because it was designed for an earlier time with lower-end PCs, and Lemmix, well, it was only written to the point where it's functional for what Eric set out to do, so there's clearly plenty of room to improve.
Post by: ccexplore on September 25, 2009, 09:26:17 PM
Not Huffman. It'd be easier to just give you my notes than to explain what else it could be:
This reminds me, it would be really great if you can release all or most of your notes on all the stuff you've discovered about level file formats etc. While someone like you might not want such notes, I hope you can appreciate that there are a lot of other people that would.
Post by: ccexplore on September 25, 2009, 09:35:51 PM
The sorry loser who coded the STYLES decoder was either drinking heavily, high on some kind of substance, or most likely some obscure combination of the two. <snip>
I don't know the details of the tables you're referring to, but it's quite possible that the "pointer table with number of entries" was originally programmed for use by the editor used by the developers of Lemmings 2. In the context of level editing, knowing how many tile entries are in any single table can be useful if, say, they want to display the full list of tiles for "one style" or something in a toolbox window or similar. In the context of the game itself however, it might not need to care about such groupings of tiles, and therefore has no need to respect the number of entries in each pointer table (ie. it most likely just loads all the tables as one array and work off that).
Not knowing the history of how a piece of code came about, I personally would refrain from calling the developer a sorry drunk loser even in jest, but meh.
Post by: GuyPerfect on September 25, 2009, 09:51:00 PM
It depends on how exactly you define "alpha/beta" (such designations make more sense when you actually start with some sort of feature spec of the final product as they do in the commercial software business), but while it's a waste of time for everyone involved to release something to the public that crashes half the time, at a certain point, it would probably be more efficient to shift some of the testing effort from yourself to the general public, or at least to a larger number of users than 1.
The alpha stage of development is when the software is a work in progress by the organization creating it and isn't at a point that would be considered for release. The beta stage is when the product is considered more or less finished and is distributed to a group of people for testing, who then provide feedback in the form of opinions and bug reports.
I have a few people in mind to help with the beta phase, but I just meant I won't be releasing that build or builds to the general public, so you guys (the general public) will need to wait a little while.
This reminds me, it would be really great if you can release all or most of your notes on all the stuff you've discovered about level file formats etc. While someone like you might not want such notes, I hope you can appreciate that there are a lot of other people that would.
Fret not, for I do not consider hacking notes profane in any sense of the word. I just ignore the work of others when I feel like doing it myself... That said, I fully intend to release full documentation as it pertains to what I've found in my hacking sessions.
I don't know the details of the tables you're referring to, but it's quite possible that the "pointer table with number of entries" was originally programmed for use by the editor used by the developers of Lemmings 2.
What happens in there is that there's a table with two-byte tile counts, and each tile ID is 2 bytes. Something like this:
03 00 - List 0 tile count
12 34 - Tile 0
56 78 - Tile 1
9A BC - Tile 2
02 00 - List 1 tile count
98 76 - Tile 0
54 32 - Tile 1
That's basically what's in the STYLES directory. Now, in those same files, something might reference that very table with the value 06 00... which refers to Tile 0 of List 1... Huh? That 0x0006 is to be interprated as the data offset in those tile lists without the tile count values in the data. Indeed, if you snipped that 03 00 and 02 00 out of the picture, the byte at offset 0x0006 is the first byte of the tile ID for Tile 0 in List 1.
Granted, this doesn't mean anyone's cognition was incapacitated, but even the game's own decoder has to handle that mess, which makes me wonder exactly what was going on upstairs. Then again, they shouldn't be expected to make things easier for hackers, but that's not the point. (-:
Post by: GuyPerfect on September 25, 2009, 10:10:08 PM
While this image looks more or less like the last one I posted except with the level picture in the middle and the white pixels replaced with grey pixels, there's actually been a lot of work done behind the scenes:
- All tiles and level objects reference each other in a linked list. This allows new elements to be added, or existing elements to be reordered or deleted without manipulating big arrays of data. Easier to code, and easier on the processor.
- The OpenGL code was optimized a bit. Though it doesn't look it, the pixels drawn to the screen are in a very real way the representation of textured, 3D polygons. I've got all tile graphics loading into individual textures, then the textures being mapped to little 16x8 rectangles when drawn to the screen. The optimization uses what's called a display list, which basically stores the drawing instructions in graphics memory so that I don't have to make the program interact with the graphics card every time a vertex needs to be sepcified. Now, I just need two lines of code: Use texture X, and draw it.
- Obviously, graphics and levels can be loaded from file and decompressed.
- Zoom functionality is implemented. Levels can be drawn from 1x to 8x, though any factor is possible. I don't suppose anything more is necessary.
- This build cycles betwen the Classic levels. Don't have to stare at just one anymore. (-:
- Clicking and dragging anywhere in the window will pan the view around. Useful for when the zoom causes parts of the level to go off-screen.
- Those dotted lines represent the level boundaries. I'm working on those right now. You'll be abl to click and drag those lines to make the stage bigger or smaller.
Well, back to work. I have things to code!
Post by: Dullstar on September 27, 2009, 07:01:27 PM
Post by: GuyPerfect on September 29, 2009, 07:37:21 PM
Basically you just drag graphics onto a grid. It isn't any more involved than, say, arranging your desktop icons. I've been taking a brief break from programming, but the project as a whole is a very minor undertaking.
Post by: Dullstar on September 29, 2009, 11:06:43 PM
Awesome... can you give a progress report?
Post by: GuyPerfect on September 30, 2009, 03:15:03 AM
Although, using the keyboard to determine which objects and tiles to place isn't the pinnacle of user-friendliness, so there will be another little branch of the project to take care of before releasing it. There are two windows to implement, yet. One for the open/save features, skills and starting new levels among other things... and one for selecting objects and tiles to put in the level. Neither is difficult, and neither will take very long.
Also also, I wish to design and implement a custom file format for storing custom levels that will add a layer of abstraction between the user and the actual game data files, provide for distribution of whole level packs, etc. Another one-day project.
Though like I said, progress doesn't move forwards very fast while I'm taking a break. (-: To be honest, I haven't worked on this since Friday and had I been, I'd probably be done with everything mentioned in this post by now. I was approaching the legendary "project burnout" since every step up had another step in the way before I could really do anything with what I was making. I've learned over the years that if I just take a few days to forget all about whatever I'm working on, it's so much more entertaining when I get back to it.
Just before logging on right now, I wrapped over the story from Paper Mario: The Thousand-Year Door and got into the little "do whatever you want after you beat the game" phase. Normally I'd call it quits here, but there's still something I've never done... I'm gonna beat Bonetail, which is the game's optional super-boss that makes even the final boss look like easy beans. But since the final boss was easy beans (two Power Plus badges, P-Up D-Down, Jumpman, Soft Stomp and Rally Wink make for a good 40 damage to the enemy every turn), I doubt it'll take me very long.
Once I'm done with Bonetail, I can put the game back in its box for a few years and get back to work on my Lemmings project. (-:
Post by: chaos_defrost on September 30, 2009, 03:42:59 AM
Very much looking forward to this once it is released!
EDIT: Also, as a Mario fanatic, Bonetail isn't that hard if you take proper precautions first. If you have the item that allows you to hold 20 items instead of 10 (at floor 50 of the Pit), it's even easier.
Post by: GuyPerfect on September 30, 2009, 05:58:36 AM
Bonetail's dead, too. As is Ms. Mowz... Sad story, really. I told Mario to use an item, but he turned around and stomped his mousie teammate for a good 8 points of damage. The battle was much more interesting than the Shadow Queen at the end of the game. It wouldn't have taken so long if I wasn't confused all the time, but it turned out alright. Went through three Zess Deluxes and five Jelly Ultras, but only one Trial Stew! So now that I have the Return Postage badge, I can delete my save file and put the game away for a few years. (-:
Guess tomorrow is back to work on Lemmings!
Post by: GuyPerfect on October 01, 2009, 03:55:22 AM
Things I got done today:
- I gutted the code behind the user input handler and re-did it. I noticed I was re-writing the click-and-drag code lots, so I set up a dragging system and now anything that needs to be dragged by the mouse is taken care of automatically. Made life a lot easier. Drawing routines were isolated into their own functions as well, so I can concentrate on each little bit of the visual display without making a huge function with a zillion variables declared at the top. (-:
- As the picture shows, element selection is implemented. A selection box can be drawn to pick elements, and selected elements can be dragged around or deleted. If you click-and-drag with nothing selected, it will drag whatever you clicked on. If you didn't click on anything, it starts drawing a box. If you want to draw a box even when clicking on something, just hold the Ctrl key.
- When nothing is selected, the element the mouse is hovering over will be hilighted. This actually gives me a lot better idea of where things are situated, since things like angled slopes are still aligned to the grid and it's nice to see it in graphical form.
- Various bug fixes and/or finishing up existing features took place. In particular, the feature that allows placment of the default screen position was fixed up and its graphics are a bit bolder now.
- Dragging with one mouse button and clicking the other will cancel the current operation entirely. This applies to panning the display (dragging with the right mouse button), resizing the level, drawing a selection box, moving elements and moving the default screen position.
There's only so much playing around one can do without adding elements, but that's the next step. What I did do, however, was make an arguably more interesting level out of an existing one with two simple clicks of the mouse. (-:
EDIT:
I had some extra time tonight, so I did some touch-up work to tweak things the way I like them. I've made the following changes:
- The "hover hilight" for when you mouse over an element now continues to appear even if other elements have been selected.
- Holding the Shift key allows you to draw a new selection box without losing your old selection. This allows you to select multiple groups of elements without selecting everything in between as well.
- Holding the Ctrl key also allows you to draw a new selection box, but elements bound by it will invert their selection state: those that are selected will become unselected in addition to those that are unselected becoming selected.
- Both the Shift and Ctrl keys will force a selection box to be drawn, even if you click on an existing element. With neither key pressed, the element you click on will immediately be dragged.
- The default screen positioner, which was formerly mapped to the Shift key, is now mapped to the Spacebar. Additionally, dragging the default screen position requires clicking within the box's bounds instead of anywhere in the window.
- The "drag with the left mouse button then click the right button" cancel feature has been tested with all these new modifications.
For those who are curious, the default screen positioner just draws a green box where the screen will be when you first load up a level in-game before scrolling around:
Post by: Minim on October 01, 2009, 03:28:15 PM
Post by: GuyPerfect on October 01, 2009, 05:48:16 PM
Post by: GuyPerfect on October 01, 2009, 09:49:28 PM
Edit go!
Things I got done today:
- Revised the element memory to put everything in the same big list. Checking element type (tile, preset, object, etc) is easier than having one group for every type of element. It also allows for levels to be designed that temporarily break the game limits, but to delete the extra objects later.
- New element placement is implemented. You just pick what type of element you want, then click where you want it to go. For water, steel and presets, you can click-and-drag to specify how many blocks horizontally and vertically will be represented by the element. That big grid of grey squares in the image is just one element.
Well huh. I expected that list to have more bullets. No matter. I've got a few loose ends to tie up, but for all intents and purposes, the application is now fully capable of authoring and editing levels for Lemmings 2. Editing day... is today!
This is the end of the line as far as what I can do with just the preview interface. I cannot make it any more functional at this point without implmenting additional UI elements, so it's time to sit down and brainstorm exactly what I want. Figuring that out will take more time than actually doing it, but I like to have options. (-:
I've attached the level file for this level to this post. Just replace the game's LEVEL000.DAT with this one (but be sure to backup the old one!) Think you can beat it 100% on your first try? I must warn you: it's reeeeeeeeeeeally hard! (-:
Post by: Dullstar on October 01, 2009, 10:20:59 PM
Post by: GuyPerfect on October 01, 2009, 10:57:13 PM
On a more honest note, I don't know when I'll be able to release the editor because I can't pinpoint when it'll be done. There's still a number of things to take care of. However, most of the heavy-duty mechanical work is already done, so it's just a matter of enabling the user to tell the program what they want to do.
The following still needs to be taken care of:
- A graphical interface needs to be made to give the user something to click on so they can select what element they want to add to the level. In its simplest form, this would just be a box with little squares in it, and the squares show what each element looks like.
- The user needs to be able to specify level meta data, which includes the skills, level name, gold requirement (can lose X and still get gold), time limit and release rate. This can basically be taken care of with a number of text-entry fields.
- Save/Load needs to be implemented. In addition to the proprietary file format I'll conjure up, there's some system-specific directory navigation code I need to build into the cross-platform API that the project is built on. I'd likely devote a whole day to this one.
- Some elements have properties. Any tile or preset can be set in the background instead of terrain, and steel blocks and the like can repeat both horizontally and vertically. The user needs to be able to view and specify these parameters.
- A few element manipulation functions need to be introduced, such as Bring to Front/Send to Back, Undo/Redo and Cut/Copy/Paste.
- Profit!
Post by: Dullstar on October 01, 2009, 10:59:38 PM
Post by: Pooty on October 01, 2009, 11:15:14 PM
I played your custom level, and eventually got gold (I fell for the trap
). I did notice a few invisible block boundaries that my lemmings kept bumping into, mainly at the bottom of the level. Was that intended?Profit? You aren't planning on selling this, are you? That would be very stupid.
Not likely. I think by "Profit!", he means it'd be completed and released.
Post by: ccexplore on October 01, 2009, 11:34:26 PM
Profit? You aren't planning on selling this, are you? That would be very stupid.
I'm pretty sure he's kidding. Right? Right?
The user needs to be able to specify level meta data, which includes the skills, level name, gold requirement (can lose X and still get gold), time limit and release rate. This can basically be taken care of with a number of text-entry fields.
How about the size of the level area? Just making sure you didn't leave something out from the list. Just double-check with the level file format to make sure you covered all available level metadata.
A few element manipulation functions need to be introduced, such as Bring to Front/Send to Back, Undo/Redo and Cut/Copy/Paste.
Don't forget "Select All"!
Here are other possible features to consider (not necessarily for version 1 though); no doubt you already have your own list though:
- option to show objects' trigger areas, that is, which tiles of the object are actually the ones that Lemmings interact with (for example, only a small part of the exit object actually causes the lemming to exit, the rest being just graphics). Showing can be done using translucent highlighting like how you're showing selections right now, except with a different color (eg. magenta).
- a level mini-map, showing a reduced-size version of the level, that you can click on to quickly jump (ie. scroll the view) to the corresponding area.
- a keyboard/mouse/menu shortcut to set the zoom and/or viewport size, so that exactly one screen's worth of level area is shown in the editor (ie. what you see is exactly how much fits onto the screen at any time when actually playing the level).
- a way for the user to tell the editor to show the animation of a specific object. For example, objects like entrance trapdoors and certain traps do not loop their animation continuously, but instead are only played once or triggered. Yet in the level editor, you may want to, for example, see how the entrance trapdoor looks with the surrounding terrain before and after it's fully opened. It would probably be annoying to loop such objects' animations continuously, so the alternative would be a way for the user to tell the editor to play the animate sequence for a specific such object on demand.
- an eraser feature to erase individual tiles, so that you can for example, place a preset onto the level, but then take out some of the tiles from it.
- possibly a selection mode that acts on individual tiles rather than presets (it's hard to tell right now what resolution your selection method acts in), or vice versa. There are cases where one may want to manipulate an individual tile, and other case where the user implicit wants to manipulate not just the one tile, but the entire preset combination that the tile belonged to. If this is already implcitly available then please ignore.
- ability to have multiple levels open at once. Equivalently, support having multiple instances of the editor running, and have the cut/copy/paste feature work across instances. It's probably acceptable to not actually show more than one level at a time (eg. maybe there are tabs and you need to click on a tab to view the corresponding level).
- possibly a UI that lets you manipulate the ordering of levels within a levelset without actually opening the levels.
- allow selection to be moved using keyboard arrow keys as well as being dragged by mouse. Though I suppose now that the level is tile-based (so you can't positioned things at arbitrary pixel locations), this may be less necessary.
- support for the user to define their own presets (ie. their own combination of tiles to treat as one unit). These user-defined presets don't necessarily have to be stored in the Style files/directories like the ones that come with the game. Defining a preset may be as simple as an option that takes the current user selection of tiles as a preset.
Actually, I think after you get to the "profit" stage as noted in your post of things-to-do, I think that would be the time to do either a public or limited release, since at that point, I think you need feedback from multiple users to properly determine what additional features are important enough to be considered adding or improving.
Post by: GuyPerfect on October 02, 2009, 12:05:53 AM
Profit? You aren't planning on selling this, are you? That would be very stupid.
It's an expression that you'll see around the internet. It's usually used in the form of "Step 1: Form a plan. Step 3: Profit!" or some-such.
I did notice a few invisible block boundaries that my lemmings kept bumping into, mainly at the bottom of the level. Was that intended?
It's a known bug. If we can figure out what causes it, we should be able to do something about it.
How about the size of the level area?
Level boundaries are specified by dragging those dotted lines bordering the preview in the editor interface. Since levels can be arbitrarily extended or collapsed in any of the four directions, I think it'd be better to merely display the level's width and height in the meta data window than to allow them to be edited there.
- a way for the user to tell the editor to show the animation of a specific object. For example, objects like entrance trapdoors and certain traps do not loop their animation continuously, but instead are only played once or triggered. Yet in the level editor, you may want to, for example, see how the entrance trapdoor looks with the surrounding terrain before and after it's fully opened. It would probably be annoying to loop such objects' animations continuously, so the alternative would be a way for the user to tell the editor to play the animate sequence for a specific such object on demand.
What I'd like to do is that for the entrances, traps and a few other "limited animation opportunity" objects, to simply have them go through their thing when the mouse hovers over them.
- an eraser feature to erase individual tiles, so that you can for example, place a preset onto the level, but then take out some of the tiles from it.
I'd already planned to have an option to split a preset into its elemental tiles. Somtimes you just need to pick it apart, you know?
- ability to have multiple levels open at once. Equivalently, support having multiple instances of the editor running, and have the cut/copy/paste feature work across instances. It's probably acceptable to not actually show more than one level at a time (eg. maybe there are tabs and you need to click on a tab to view the corresponding level).
Fortunately, the way I programmed this thing allows for this kind of instantiation. I learned THAT lesson a long time ago. (-: Like you said, this would be an option to consider at a later time, but it's a good idea and it wouldn't be hard to do.
- possibly a UI that lets you manipulate the ordering of levels within a levelset without actually opening the levels.
There will be a little mini-interface for patching levels to the game, and you can select what stage goes where at that time.
- support for the user to define their own presets (ie. their own combination of tiles to treat as one unit). These user-defined presets don't necessarily have to be stored in the Style files/directories like the ones that come with the game. Defining a preset may be as simple as an option that takes the current user selection of tiles as a preset.
I briefly considered doing this, but the tiles used in the game are rather explicitly made for use with the provided presets. The most effect you'd get out of such a feature is gluing multiple presets together; in which case you might as well just use two.
Actually, I think after you get to the "profit" stage as noted in your post of things-to-do, I think that would be the time to do either a public or limited release, since at that point, I think you need feedback from multiple users to properly determine what additional features are important enough to be considered adding or improving.
My normal channels haven't been receiving a lot of interest for beta testing this project, so I'll probably just post it in this thread for you guys to give feedback on.
Post by: Yawg on October 02, 2009, 02:19:53 AM
Looks like it's shaping up to be a great project, and it may be just what I need to get out of the creative slump I've found myself in since the start of classes...
Post by: Clam on October 02, 2009, 03:42:48 AM
I did notice a few invisible block boundaries that my lemmings kept bumping into, mainly at the bottom of the level. Was that intended?
It's a known bug. If we can figure out what causes it, we should be able to do something about it.
Oh, come on. Don't even try to tell me that all those blocker fields weren't intentional. You've hacked this game to death and then some - you knew exactly what you were doing. And the steel block turning into a trap is just ridiculous. Please, please, PLEASE don't even consider including such BS in the editor's capabilities. There's absolutely no chance that anything good will come of it.
[/vent]
I'm going to calmly assume this level was intended merely to demonstrate some of the lesser-known "features" that this game provides, and not specifically to butcher the game and annoy people. (Which, in case you couldn't tell, you succeeded at
)
Post by: GuyPerfect on October 02, 2009, 03:54:45 AM
- Tile ID 0 is now treated as nothingness throughout the application. This applies to loading tiles from the level as well as drawing/saving presets with that tile in them.
- The mouse picker now makes three passes: first for objects, then presets, then tiles; according to the order they are drawn to the screen. This ensures that what you click on is what you select.
- Maximum level dimensions are now restricted. Dragging one boundary will simply stop when it reaches the max, but dragging two boundaries at once will turn red if the desired level size is not possible.
Oh, come on. Don't even try to tell me that all those blocker fields weren't intentional. You've hacked this game to death and then some - you knew exactly what you were doing. And the steel block turning into a trap is just ridiculous. Please, please, PLEASE don't even consider including such BS in the editor's capabilities. There's absolutely no chance that anything good will come of it.
The invisible wall(s?) aren't in the level data anywhere. I don't know what causes them. If you do, any information would be appreciated.
As for hiding traps behind steel blocks, it's just a matter of arranging objects in order, and will be possible with the editor. I'll also throw in an option to render steel blocks as normal dirt tiles, or even as background tiles. There's more potential agony than what I've done in the level I made a few posts ago.
When dealing with user-generated content, you gotta assume that crap will be made. There's no avoiding it. However, if you know and trust the person you're using levels from, you won't have anything to worry about.
EDIT:
Eh, having second thoughts about the dirt-steel. I can't think of any reasons to use it except to annoy people. I remember that block at the end of Medieval 5 and how bogus it felt, and I certainly don't want people to do that just because they can.
I'll still code in the option just in case I do need it in the future for whatever reason, but it will be disabled until such a time.
Post by: Dullstar on October 02, 2009, 04:08:54 AM
Post by: Clam on October 02, 2009, 04:53:33 AM
The invisible wall(s?) aren't in the level data anywhere. I don't know what causes them. If you do, any information would be appreciated.
Sorry, I still don't believe that. Considering the layout of weird invisible stuff leaves a convoluted route to the exit, whereas if it really was unknown and random, it would more than likely block the exit entirely and make the level impossible. And I'm fairly certain this isn't the same as the glitch I mentioned in the other thread (though it may be related) - that required you to use a blocker, basher and exploder to make a temporary invisible wall appear.
I know you can't necessarily stop this sort of nonsense from creeping into custom levels (heck, if you want it that badly you can hex-edit it in), but I would like to think you can prevent it in the editor. For example, you could:
- Delete traps that get buried behind terrain when editing, just as you would with terrain.
- Disable setting as background for terrain pieces, except for those which were clearly intended to be background objects (polar bears and the like). And preferably make those background-only (i.e. can't be used as terrain) and group them along with the trapdoors and exits to avoid confusion.
- (This one you've acknowledged already) make steel act as steel and nothing else.
The discoveries posted in this thread actually disturb me somewhat. Unlike in the original Lemmings (and Lemmings 3 as well), there's some surprising stuff in here that's just unbelievably bad, and will do (and can do) nothing but break the game. Is it even a good thing for people to know about all this? Well, to avoid being unfair on those who haven't seen this thread, it probably is. But allowing it in the editor is just asking for some noob to pick up the editor, find all this new stuff, and make a bunch of
Sorry to rant, but I feel quite strongly about this.
Post by: Yawg on October 02, 2009, 05:21:12 AM
When dealing with user-generated content, you gotta assume that crap will be made. There's no avoiding it. However, if you know and trust the person you're using levels from, you won't have anything to worry about.
I second this. Despite the potential for abuse, I'd take a full editor over something thats been gimped out of fear any day of the week. The greater control the user is given, the more chances they have to create utter crap. But the more flexibility these tools afford them, the more oppertunities they have to innovate. I'm not advocating hidden traps, invisible walls or the like, but I am offering my support for the most powerful and flexible editing tools we can get.
Post by: Clam on October 02, 2009, 06:05:42 AM
Believe me, I'd be more than happy to use an editor that allows for such "innovation". As long as it does what I need it to, then it can have as much useless junk on the side as it wants.
Post by: chaos_defrost on October 02, 2009, 06:08:28 AM
Post by: Minim on October 02, 2009, 06:23:20 AM
Will you be able to hack a new graphics set or some new skills or is that not possible?
Post by: GuyPerfect on October 02, 2009, 07:00:53 AM
Sorry, I still don't believe that. Considering the layout of weird invisible stuff leaves a convoluted route to the exit, whereas if it really was unknown and random, it would more than likely block the exit entirely and make the level impossible.
Well, I don't know what to tell you. There is nothing in the level format that even allows for an invisible wall, let alone me selecting where they would go. Trust me, if I knew how to prevent it from happening, I'd be all over it.
- Delete traps that get buried behind terrain when editing, just as you would with terrain.
In Lemmings 2, all terrain is drawn first, then all objects on top of it in the order they're secified in the file. Traps and exits cannot be hidden behind terrain this time around, but objects can obscure other objects, which is what I did with that ten-tonsamajig in the level I made earlier.
Though for what it's worth, I'm not up for making an algorithm that detects whether or not the user is trying to be onery. It's against my religion.
- Disable setting as background for terrain pieces, except for those which were clearly intended to be background objects (polar bears and the like). And preferably make those background-only (i.e. can't be used as terrain) and group them along with the trapdoors and exits to avoid confusion.
It's true that certain presets were intended to be used as background and everything else as true terrain. And I'm certainly interested in preventing magical secret passages by altering the background property of a few choice tiles... I'll probably end up making a built-in list as to which presets in which tribes need to be backgrounds. And if they need to be backgrounds, you can't split them into tiles... I'll think on this one some more.
But allowing it in the editor is just asking for some noob to pick up the editor, find all this new stuff, and make a bunch of"groundbreaking"game-breaking levels.
Game-breaking being the key point there. While I started at this with the idea of giving all possible options to the user, after taking time to think about what can be done, I do agree that certain options can really only be useful to someone who wishes to be a jerk. There's the off chance someone wants to make a "sneaky" set of levels where the whole point is to look for the hidden secrets, but under any other circumstances, such design would be game-breaking.
I personally don't feel that hiding traps falls under this category, however. There are traps in the game that you can't see at all until their activated (Egyptian has a "from the sides" smasher that you can't see) as it is. Though if every level a user makes has a steel tunnel with hidden traps, I'm likely to stop playing that user's levels.
Will you be able to hack a new graphics set or some new skills or is that not possible?
Adding graphics is a cinch, but skills would require reprogramming the game and I haven't even touched that. However, the level editor is designed to work only with the original files that shipped with the game, so any new additions won't be supported. I'm not interested in playing someone's tribute to Hello Kitty during my special Lemmings time of day.
Post by: ccexplore on October 02, 2009, 07:50:27 AM
So that's what so hard about level. Great, thanks for spoiling that for me
(no, I still haven't got around to trying it out, told you I'm busy).Sorry to rant, but I feel quite strongly about this.
Well, everyone's entitled to their opinions. I have to say in my mind this is a bit of overreaction. Someone really determined to make "bad" levels can always do so via hex-editing or other such techniques. I suppose it would be nice to make sure the editor's design does not allow users from accidentally creating such "bad" designs, and there's certainly no need to spend extra work to make the editor supports something unpopular that it can't already do, but I do feel a little offended at the notion of having the editor doing anything beyond that (ie. actively trying to restricting level designs that it can already handle).
And now, let me actually read what people have posted and respond to the specifics:
- Disable setting as background for terrain pieces, except for those which were clearly intended to be background objects (polar bears and the like). And preferably make those background-only (i.e. can't be used as terrain) and group them along with the trapdoors and exits to avoid confusion.
It's true that certain presets were intended to be used as background and everything else as true terrain. And I'm certainly interested in preventing magical secret passages by altering the background property of a few choice tiles... I'll probably end up making a built-in list as to which presets in which tribes need to be backgrounds. And if they need to be backgrounds, you can't split them into tiles... I'll think on this one some more.
Instead of trying to restrict the user, you can mitigate the objection simply by having a way in the editor to show what exactly is background and what exactly is terrain. For example, a mode that hides all background. In fact, such a feature is probably useful even ignoring this concern, by allowing the level designer to focus on the parts of the level that matters to the solution.
I suppose I can live with a mode that warns user when they try to use tiles meant for background as terain and vice versa, or at least some default mode that makes such "abuse" harder to come by, but I don't really think we should go as far as trying to censor it outright in the editor. The best way IMHO to discourage abuse is for the community to throw pie in the face of the level designer (so to speak), not censorship. And remember that there's always the hex editor.
- Delete traps that get buried behind terrain when editing, just as you would with terrain.
In Lemmings 2, all terrain is drawn first, then all objects on top of it in the order they're secified in the file. Traps and exits cannot be hidden behind terrain this time around, but objects can obscure other objects, which is what I did with that ten-tonsamajig in the level I made earlier.
Though for what it's worth, I'm not up for making an algorithm that detects whether or not the user is trying to be onery. It's against my religion.
Again, an easy way to deal with this is simply to make it impossible to truly hide anything in the editor. You may recall on my feature list talking about a feature that highlights the trigger areas (ie. the tiles that actually affect lemmings) of objects. Having such a feature would ensure that such hidden stuff would not survive a brief examination in the level editor, and community flocking would quickly discourage those who dare to abuse.
I'm not interested in playing someone's tribute to Hello Kitty during my special Lemmings time of day.
LOL
Though consider that there could always be someone out there who is interested. More to the point, being able to make your own styles is something that I think will interest level designers, and we've seen this as one of the features where Cheapo is superior over something like Lemmix or LemEdit. Certainly not a feature for version 1, but don't be too quick in dismissing the possibility.
You can make it difficult without having to make it impossible
That sounds reasonable, although I'd go a step further and say that the main goal should be to prevent accidental bad design, not to actually trying to go out of the way to actively thwart someone who's determined to create bad designs.
Also, I think the scenario of a "n00b" creating tons of abusive levels sounds rather alarmist to me, especially within the community of this forum. Such a level designer would quickly be ignored like you would a spammer or troll.
Post by: ccexplore on October 02, 2009, 07:57:39 AM
EDIT:
Eh, having second thoughts about the dirt-steel. I can't think of any reasons to use it except to annoy people. I remember that block at the end of Medieval 5 and how bogus it felt, and I certainly don't want people to do that just because they can.
I'll still code in the option just in case I do need it in the future for whatever reason, but it will be disabled until such a time.
Consider that in LemEdit/Lemmix/CustLemm, there had been cases where steel areas are used as a cheap fix against unintentional backroutes that may otherwise spoil the level. I suppose this may be less applicable in the tile-based design of L2 levels (it's impossible to speculate on this until we actually have people trying to create custom levels for real), but with that in mind, don't be too quick to dismiss it as a 100% bad thing. Remember once again that there's always the "show me everything" mitigation--some mode that highlights all steel would quickly reveal the level's true nature.
Post by: GuyPerfect on October 02, 2009, 08:05:05 AM
I've discovered the dealie with the invisible walls. Turns out it's linked to the location digging tools were used, and only happens under two conditions: 1) the Lemming is below the 160th pixel from the top and 2) the current Tribe is Classic... The real bummer here is that it ALWAYS happens under those circumstances, which means Classic levels can only be one screen tall... Oh well.
Your reiteration of viewing levels with the editor before playing is very reassuring, ccexplore. I mean, you need to use the editor to at least patch them to the game, so it shouldn't be an issue to check the stages for any mysterious use of steel look-alikes or secret background passages/pitfalls. With that in mind, I do think I'll go ahead and give the user full control over what's what in the event they have a reasonable purpose for doing something that's otherwise taboo. And if someone thinks a level is a bit suspicious, they can just turn on the special hilight mode and see exactly what's-what.
Post by: ccexplore on October 02, 2009, 08:14:35 AM
I've discovered the dealie with the invisible walls. Turns out it's linked to the location digging tools were used, and only happens under two conditions: 1) the Lemming is below the 160th pixel from the top and 2) the current Tribe is Classic... The real bummer here is that it ALWAYS happens under those circumstances, which means Classic levels can only be one screen tall... Oh well.
Good job! It is a little sad that such a restriction exists in Classic Tribe (perhaps when you get to exploring the game mechanics, you will eventually find out the underlying cause and have a way to change it?), though I guess it really wouldn't be so classic if the level's more than one screen tall.
Post by: Clam on October 02, 2009, 08:43:58 AM
In response to ccexplore's points:
Quote
Someone really determined to make "bad" levels can always do so via hex-editing or other such techniques.
Well, yeah, but here's the thing:
Editing levels in the new editor will be easy. (Hopefully, really easy.)
Editing levels in a hex editor is hard. Really hard.
Anyone who wants to make crazy stuff happen in their levels would have to read up on the level file format and figure out what numbers to put where. Since these people are likely to be new designers, they're unlikely to take this step.
Quote
Instead of trying to restrict the user, you can mitigate the objection simply by having a way in the editor to show what exactly is background and what exactly is terrain. For example, a mode that hides all background.
Assuming you will have to open the editor anyway, then this is a great idea. Especially since DOSBox runs windowed so you can see the level in-game and the "real" level side by side. In fact, this just might be all we need.
Quote
I suppose I can live with a mode that warns user when they try to use tiles meant for background as terain and vice versa, or at least some default mode that makes such "abuse" harder to come by, but I don't really think we should go as far as trying to censor it outright in the editor.
The thing here is, if a polar bear (for example) is in the background in one level, and a terrain piece in another, it's going to cause confusion even if it wasn't intended to be abusive. By forcing it to be one or the other, you gain consistency and avoid potential problems. I don't know if any such inconsistencies exist in the original levels - but if they don't, then we have a good precedent to work from.
Quote
Also, I think the scenario of a "n00b" creating tons of abusive levels sounds rather alarmist to me, especially within the community of this forum. Such a level designer would quickly be ignored like you would a spammer or troll.
Come on, you know what it's like when you're new. You find something that wasn't in the original levels, and you just have to use it. And not all designers are going to read the forums extensively before playing with the editor. Keep in mind that we do need to be careful around newbies to avoid scaring them off - "throwing pie", while being fun at the time, isn't going to help in the long term.
I don't mean to get so uptight about all this. I'm just fed up with levels where the intention is to hide key information from the player. It was bad enough in Lemmings - hidden traps, hidden terrain behind objects, black (= invisible) terrain, fake exits, fake steel, steel on non-steel terrain... heck, this is worth a rant thread of it's own. And now I find out that even worse BS is possible in Lemmings 2. I'm sure you can appreciate my frustration.
Post by: GuyPerfect on October 02, 2009, 08:58:30 AM
This color-codes every pixel on the screen according to the element type they represent. Yellow is dirt, and grey is steel. It's easy to see at a glance exactly what type of terrain things are.
I will throw in a special pass to specifically hilight traps for those times when they're hidden behind objects (since their non-graphical pixels will still show up as black currently). It'll help the user identify when something's going to snap out at them.
Additionally, I've also prevented Classic levels from being able to be resized vertically.
Post by: Clam on October 02, 2009, 09:52:08 AM
Forget the terrain textures, I want to play the game in this mode. That's old-school
Post by: namida on October 02, 2009, 09:55:45 AM
Additionally, I've also prevented Classic levels from being able to be resized vertically.If the game mechanics doesn't disallow that, don't do it! >_>
Post by: Clam on October 02, 2009, 10:21:23 AM
I've discovered the dealie with the invisible walls. Turns out it's linked to the location digging tools were used, and only happens under two conditions: 1) the Lemming is below the 160th pixel from the top and 2) the current Tribe is Classic... The real bummer here is that it ALWAYS happens under those circumstances, which means Classic levels can only be one screen tall... Oh well.
And by the way - these are more like blocker fields (as I called them earlier) than invisible walls. How do I know? I noticed the following on GuyPerfect's level, in the lower half:
- I couldn't place any blockers.
- I got a basher stuck in the infinite loop of bashing and turning around, without using any blockers.
- I was digging a tunnel down the right-hand side, and the lemmings suddenly walked to one side and started glitch-climbing up the side of the tunnel - as though they had been pushed out by a blocker.
Post by: ccexplore on October 02, 2009, 10:24:43 AM
QuoteAlso, I think the scenario of a "n00b" creating tons of abusive levels sounds rather alarmist to me, especially within the community of this forum. Such a level designer would quickly be ignored like you would a spammer or troll.
Come on, you know what it's like when you're new. You find something that wasn't in the original levels, and you just have to use it.
I suppose. But after you use it once or twice and found everyone hating it, would you still do it a third time? Such cheap novelty wears off quickly.And more to the point, although I can't say that I've observed the Lemmings community longer than other people, I just really have never observed in the case of LemEdit there ever being some bad epidemic of people resorting to churning out tons of levels with hidden exits, fake objects, and other such "atrocities". I'd think people who are bothered enough to create levels in the first place are those who truly love the game, and we all know that the enduring qualities of Lemmings are anything but the hidden exits, fake objects, etc. Maybe someone will sneak it into a levelset one time, but that's about it.
Keep in mind that we do need to be careful around newbies to avoid scaring them off - "throwing pie", while being fun at the time, isn't going to help in the long term.
I was obviously exaggerating. What would happen of course is that there'd be a "Lemmings 2 Custom Level Review Game", and people would make it very clear that a levelset where all the levels are hidden-exit hunting levels gets lame very quickly, and hopefully the level designer will take that as a sign to try something else, to redeem himself in our eyes or risk having his future levelsets be avoided and ignored by everyone. This is all I have in mind when I exaggerate and say "throwing pie" and "community flocking".
I don't mean to get so uptight about all this. I'm just fed up with levels where the intention is to hide key information from the player. It was bad enough in Lemmings - hidden traps, hidden terrain behind objects, black (= invisible) terrain, fake exits, fake steel, steel on non-steel terrain... heck, this is worth a rant thread of it's own.
But how many such actual custom levels are we talking about out here? Clearly, it sounds like you had run into some major source of bad custom levels. Now you've got me really curious......
And I'd hope that with the editor having the power to reveal all these silliness, a level designer would be smart enough to know that relying solely on such silliness will simply not work for long.
Post by: Pooty on October 02, 2009, 01:29:48 PM
Forget the terrain textures, I want to play the game in this mode. That's old-school
I agree. It reminds me of the Spectrum.
I've discovered the dealie with the invisible walls. Turns out it's linked to the location digging tools were used, and only happens under two conditions: 1) the Lemming is below the 160th pixel from the top and 2) the current Tribe is Classic... The real bummer here is that it ALWAYS happens under those circumstances, which means Classic levels can only be one screen tall... Oh well.
Aww, darn. That's a shame. I was looking forward to vertically scrolling Classic levels, although that does make me wonder how blockers work in this game.
Post by: ccexplore on October 02, 2009, 07:35:27 PM
I've discovered the dealie with the invisible walls. Turns out it's linked to the location digging tools were used, and only happens under two conditions: 1) the Lemming is below the 160th pixel from the top and 2) the current Tribe is Classic... The real bummer here is that it ALWAYS happens under those circumstances, which means Classic levels can only be one screen tall... Oh well.
Hold on. I still haven't tried the level yet (sorry), but it sounds like this only happens if the level uses diggers?
Basically I'm wondering whether it's the case that a taller level will be okay as long as you avoid certain skills. If that's the case, then instead of disallowing taller Classic levels, a less restrictive thing to do would be to warn the user (level designer) of the problem, and remove offending skills (and disallows them to be added) if the level designer chooses to go ahead anyway.
(And actually, even this may be too restrictive, since it sounds like the lemming must be digging below the 160th pixel to trigger the bug, and the level may be able to guarantee that it will not happen.)
Post by: GuyPerfect on October 02, 2009, 08:33:53 PM
It reminds me of the Spectrum.
Check the filename of that image. (-:
Basically I'm wondering whether it's the case that a taller level will be okay as long as you avoid certain skills.
It's apparent that the game wasn't designed to allow for vertically-scrolling Classic levels for whatever reason, and there's some freaky memory mismanagement going on when using certain skills below that top screen's worth of pixels. I don't want to risk triggering any manner of memory leaks, buffer overflows, data corruption or the like by doing something that the game wasn't designed to do. At this point, misbehaving Lemming abilities are the least of my worries.
Traps are now shown with dotted lines while in reveal mode, even if they're hidden behind other objects. This should fully counteract anyone who's trying to be sneaky.
Post by: Clam on October 02, 2009, 11:14:34 PM
I agree. It reminds me of the Spectrum.
I never had a Spectrum, but I did see the pictures of those levels when they were posted on the old forum. I'm not sure why, but they just look awesome.
Quote
Aww, darn. That's a shame. I was looking forward to vertically scrolling Classic levels, although that does make me wonder how blockers work in this game.
As far as I can tell, they work in very much the same way as they did in the first game. They set up some sort of "force field", they push lemmings into walls, they prevent other blockers from being placed, and they turn lemmings around when they're using a skill.
I can't imagine there being a need for vertically scrolling Classic levels anyway. If you want a tall Classic level for whatever reason, you can always build it in another tribe and use the Classic skills. Assuming they let you use blockers in other tribes, that is (and I can't see why not).
Post by: Pooty on October 02, 2009, 11:44:31 PM
Post by: Dullstar on October 03, 2009, 12:36:08 AM
Post by: GuyPerfect on October 03, 2009, 02:21:12 AM
Post by: Dullstar on October 03, 2009, 02:28:17 AM
Good luck with the editor, it looks like for the most part, you just need to implement a few more things, and then it's suitable for use.
Post by: ccexplore on October 03, 2009, 11:04:41 AM
I also think I now have better insight on that too. I noticed that in the "Practice" screen of the game, nearly all the game's skills are available--except the blocker! (Okay, maybe there is some 1 or 2 other odd skills that also aren't there, but humor me.) All the other 7 Classic skills are selectable for Practice, and AFAIK only the Classic levels have blockers. This suggest to me that the support for blockers may be specific to the Classic Tribe only. The observed behavior with the "phantom blocker fields" suggests to me that they might have implemented blocker handling somewhat like Lemmings 1, using a map (2D array/grid) to keep track of blocker fields. In that case, it's easily possible that they might have hard-coded this map to only handle a height of 160 pixels. If that's the case, then positions below the first 160 pixels would calculate into memory addresses beyond that allocated for the blocker map. When the game sees whatever other data's in that memory and interpret them as blocker fields, you would end up with these phantom blocker fields. If my theory is correct, this does mean the game truly cannot support more than 160 pixels tall for Classic, no matter what the skillset is. (This is basically similar to the "LemSteven ceiling-bashing syndrome", but a bit worse since the level area can extend a lot more below 160 pixels.)
I also like to warn people like Clam that, given this is the first time we have the ability to create new Lemmings 2 levels, be prepared to run into other such more oddities until we better learn the quirks and limitations of how the game handles certain things. For example, in DOS Lemming 2's "Practice" screen, you may notice that when you start adding skills, the game may start disallowing certain other skills to be added, claiming "insufficient memory". While it could conceivably be just a bug in the Practice screen (or perhaps how I set up DOSBox?), and that in fact the game could've handled the resulting skillset, it's just as possible that the game prevents you from using certain combinations in Practice for the reason it claims.
As no one right now knows exactly how to calculate the amount of memory needed by the game for a handling a certain skillset, don't be surprised if weirdness ensues from using a skillset that happens to violate the game's memory requirements. (That said, I think the number of skills might matter just as much as the types of skills, because for example, I can't do "attractor, ballooner, fencer, scooper, roper, platformer, club basher, jumper" in Practice mode, yet those are the exact types of skills given in Beach 6, though not 20 of each as would be in Practice mode.)
Post by: GuyPerfect on October 04, 2009, 12:07:50 AM
This is only a mockup. It's not part of the project yet.
After several days of brainstorming stretching from the time I started this project, I've invented the image you see above. I even exchanged ideas with a roommate to come up with this one! It's a mockup of what an interface might look like to allow the user to pick what preset object or tile they want to add to the level.
This interface was selected for the following reasons:
- The user is easily able to find and graphically identify which element they want to place. This was the biggest goal.
- It takes up little space. The 640x480 default window size is the targt size for usability, and if the interface is too bulky to use at that size, it's too big.
- Since elements come in various shapes and sizes (some of which are very large, like the Medieval yellow dragon), all elements in this interface are presented in uniform fashion. In the image above, larger presets or objects will actually be scaled down to fit inside the little square.
- Being docked to the edge of the window means it is out of the way while editing and will resize according to the window's dimensions.
- This interface can be used for all three of object, preset and tile selection.
If this idea is used, the user can decide which of the four edges of the window to dock to.
Now, where you guys come in... This mockup will become the real interface unless someone out there with magical imagination powers comes up with a better idea. If your might of brainstorming so completely surpases my own that I have overlooked some amazing way to handle the situation, then please do speak up!
As it is, though, I'd be perfectly happy with an interface like the one in the image.
Post by: chaos_defrost on October 04, 2009, 02:13:48 AM
Post by: GuyPerfect on October 04, 2009, 02:16:40 AM
I hope that's a suitable alternative to a scroll box, 'cause I'm not liking the idea of putting a scroll bar in there.
Post by: Clam on October 04, 2009, 02:32:09 AM
Post by: GuyPerfect on October 04, 2009, 02:59:17 AM
Post by: Clam on October 04, 2009, 03:16:03 AM
Post by: Dullstar on October 04, 2009, 04:41:59 AM
However, here's one of my ideas.
It's not great, but I don't spend too much time on these.
Note that the lvl is an abbreviation for level, not the format used by the original lemmings games.
Post by: ccexplore on October 04, 2009, 04:44:02 AM
The current proposal is acceptable, and in fact is fairly similar to what Lemmix offers (except Lemmix shows it in a separate popup window, and has a vertical rather than horizontal list). Some comments:
- I assume the pane can be turned on and off as needed (ie. it isn't always there).
- While the right-click-and-pan is a reasonably good alternative to a scrollbar, I can see some people might like the visual indication offered by the scrollbar's thumb, allowing a sort of visual-muscular memory to be developed for scrolling to a particular place in order to get a particular preset or object.
A possible alternative to scrolling could be a button that upon clicking, can expand the pane to full height/width, temporarily obscuring the level area but now can display several rows of stuff instead of just a single row. Perhaps enough to show everything without scrolling. The user clicks on the piece he wants and the pane snaps back down to normal width/height.
Post by: Simon on October 04, 2009, 05:42:05 AM
I hope that's a suitable alternative to a scroll box, 'cause I'm not liking the idea of putting a scroll bar in there.
It can be done, but a scrollbar is better for several reasons. Its usage is immediately clear to the user, and it provides, as ccexplore has hinted, more ways of control than other things.
Anything uncommon hampers the user. You appear to be using the operating system's GUI widgets already, so I strongly advise to use the common, known-by-all solution to this design problem.
-- Simon
Post by: GuyPerfect on October 04, 2009, 08:09:33 AM
However, here's one of my ideas.
That's pretty much how it's already set up, though I'm extra certain scroll bars aren't needed for the level display. The levels simply cannot be big enough to warrant the presence of scroll bars. As for the menu bar at the top, I'm still going back and forth on that one. The final product may not have one.
[...] except Lemmix shows it in a separate popup window, and has a vertical rather than horizontal list
I've already begun working on this interface, scroll bar notwithstanding. It can be configured to be vertical or horizontal and on any of the four edges of the screen. The size of the squares is dynamic, too, though I'm not entirely sure I'll let the user change that setting. It can be hidden, though.
While the right-click-and-pan is a reasonably good alternative to a scrollbar, I can see some people might like the visual indication offered by the scrollbar's thumb, allowing a sort of visual-muscular memory to be developed for scrolling to a particular place in order to get a particular preset or object.
Deal. This is a very good point made possible only by the presence of a scroll box. If you can see the relative position in the list of the object you want, you know that it's always "right about there." I'll adjust my layout accordingly.
You appear to be using the operating system's GUI widgets already, so I strongly advise to use the common, known-by-all solution to this design problem.
Thank you.
Why thank you? Because I'm not using any system UI controls, so the fact that you couldn't tell means I'm doing my job correctly. Everything's handled internally by the program and will look and act exactly the same no matter what system you run it on.
Post by: ccexplore on October 04, 2009, 08:35:49 AM
As for the menu bar at the top, I'm still going back and forth on that one. The final product may not have one.
Hmm, I'm curious how then you intend to surface visible entry points to commands like saving a level. While you can potentially have no visible entry points and just use keyboard shortcuts, it can be frustrating if someone forgets what key to press.
===========
I still think having an option that can avoid scrolling/panning altogether is worth considering. Like the "expand to several rows" button I mentioned, although some user-testing may be worthwhile to see whether it's too disruptive or not (I don't think it is, and the user's not forced to use it, but...). This was also why I earlier suggested the mini-map thing for jumping to particular areas of the level, as a potentially faster means than scrolling/panning to get to where you want.
Post by: GuyPerfect on October 04, 2009, 07:46:27 PM
Anyhows, the introduction of additional UI elements has brought to my attention a need to modularize the handlers for user input. This isn't something I've had to do in the past, so I still need to think about the best way to go about it. That said, I'd expect a couple more days before I have any new updates to report.
Post by: Dullstar on October 04, 2009, 08:03:02 PM
The buttons in your mockup, GuyPerfect, could be held down so you wouldn't have to click-click-click through, and somewhere you could have something to the effect of a menu bar (that performs the proper functions, anyways.)
Post by: ccexplore on October 04, 2009, 10:29:39 PM
There's any number of other ways to access features graphically without using a menu bar.
Of course, but seems like a menu bar would take up the least screen real estate compare to other alternatives. What do you have in mind instead?
Post by: GuyPerfect on October 05, 2009, 02:28:29 AM
I've come up with a good method for modularizing user input between controls, and it's effectively the same as the one used by existing operating system UIs in use today. My project, however, is basically just the one interface (the level editor itself) with a bunch of shared variables thrown here and there and it's intermingled directly with the user input handler. The first thing I'll need to do is disconnect that interface and make it float out in space all by itself, then make each new interface similarly buoyant. Lo and behold: I'm having a little mini-application of what I started this project for in the first place. Go figure!
Achieving this task will require a significant reorganization (not to be confused with re-writing) of the existing code and will take the free time of a couple days to do correctly. However, this turn of events comes with its fair share of advantages. Since I'm in revision mode, I'll take a careful look at each existing function as I move it over into a new project and ensure it's all up to snuff and coded correctly. This will make the program's structure cleaner as well as ensure it comes out bug-free. Also, since the new project setup will require the editor to be instantiated, I might as well throw in the capability of having multiple levels loaded at any given time.
I'll post something more when I have something to report.
Post by: Dullstar on October 05, 2009, 02:49:48 AM
Linux users are standing by...
Post by: GuyPerfect on October 05, 2009, 04:00:53 AM
Post by: Dullstar on October 05, 2009, 10:30:42 PM
Post by: GuyPerfect on October 05, 2009, 10:33:15 PM
Post by: Dullstar on October 05, 2009, 10:35:22 PM
Post by: GuyPerfect on October 05, 2009, 10:37:03 PM
Post by: GuyPerfect on October 06, 2009, 04:37:12 AM
EDIT:
Okay, got my scroll bar drawing routine set up. Just a little coding and I'll have functional scroll bars. (-:
Post by: Dullstar on October 08, 2009, 03:09:03 AM
Post by: GuyPerfect on October 08, 2009, 04:34:26 AM
Post by: GuyPerfect on October 10, 2009, 10:16:01 PM
Everything kinda happened at once. I got a new job (which I'm still getting used to), my parents came to visit (since I haven't seen them for like a year) and I got things squared away with rent being due and the like. Well, parents have just left now, and I have a shift to work tonight, but things are more or less getting back to normal. I haven't been home since Thursday afternoon!
In any case, I haven't had the free time to work on this project this past week like I had before, but I was still working on it, even while not at home.
The scroll bars are done and implemented now, and they're awesome. The way I ended up organizing them was basically just by handle, and a custom Widget API does the rest of the work. An advantage to doing it this way is that I can set up the level editing interface and the element picker as widgets in and of themselves, which will let me composit the functionality of all features of the edtior dynamically and hard-code as little as possible, so I can avoid that big mess of global variables I was using before. This is very good for productivity.
However, like I said before, I want to disconnect all the editor code from the main application whatsoever, so I'm still in-progress of moving code over from the new project and making it fit the new organization. The next screenshot I post won't look like much work was done, but it's been a good learning experience and I'm glad things went the way they did. I should have something to show in the next few days.
Post by: Dullstar on October 11, 2009, 11:26:32 PM
Post by: Dullstar on October 14, 2009, 10:55:59 PM
Post by: GuyPerfect on October 14, 2009, 11:01:47 PM
Basically what happened is that, when I needed to introduce additional user elements, I found that I couldn't just keep slapping conditional statements in the input handlers (mouse clicks, for instance) and needed to reorganize things a bit to get multiple user elements in place.
At this point, the decision was made that the entire project should be pulled apart and structured differently, despite the necessary changes to achieve this. Most of the functions in the program make use of one or more shared global variables, and isolating those functions is a sheer time investment that made me go "Ick!" every time I thought about working on it.
I started a blank project and designed the scroll bar. By the time I was done, I had a system that very much stood on its own. I realized once I was done that this system can very easily be inserted into the existing project by adding a small layer of input handling on top of what's already there; keeping both systems intact and requiring no reorganization whatsoever.
So now I have a half-reorganized project on one folder, and the screenshot above is from the existing project but with the scroll bar system put in. It's not an ideal situation, but it's still functional and reasonably organized, so if I want to make something better, I'd have more luck just starting over and making all appropriate considerations from the get-go.
Anyways, what I have is two weeks' of free time work not even being used in the end, but that's the way the cookie crumbles. At least now I'm back on track and making visible progress in a timely fashion. (-:
The picker interface should be fully implemented by the end of the week. And I have Friday off, so that will help.
If it can edit and save levels by now, can you release an incomplete version?
The short answer is no.
Post by: Dullstar on October 18, 2009, 10:59:26 PM
Any more sample custom levels (preferably from different tribes)?
Post by: GuyPerfect on October 18, 2009, 11:24:16 PM
I advise that you don't keep this thread on auto-reload. Try as I may to ignore all the inconsequentialities of the world and only concentrate on the important things (like a Lemmings 2 level editor), my free time resists with increased ferocity and is making considerable headway towards the prospect of me having a life. The lack of progress on the editor is not due to burnout or even a change of interest; I simply haven't been able to work on it.
Though I've gotten a handle on interruptions to my schedule and am reasonably into the swing of things at work, I still got creamed right in the forhead by a curveball. On Friday, my awaited day off that I had planned to devote to this project, I woke up to a significant message in my inbox that demanded my attention moreso than Lemmings 2 (however much it pains me to report as such). The situation presented a number of opportunities that I'll be looking into, and at this point I can't even make any estimations as to how much I'll be able to spend on the level editor.
If things remain the way they are, I'll gladly be working on the project tonight and all day tomorrow. I hope to have an update or two to report by Monday night, but if you hold your breath, you may pass out long before the pixels on your screen show you anything new. When I have an update to report, I'll post it here. I won't hide things in secret until someone asks about it. (-:
Post by: GuyPerfect on October 19, 2009, 06:23:31 AM
As you can see, the picker interface is complete. It works for both presets and objects, and can easily be updated to work with individual tiles when I go down that road.
I gotta tell you: using the editor in its current setup is slick. Picking out objects to use is intuitive and easy, and it only took me some four or five hours to prepare this level in its entirety: starting with a blue void and going all the way through playtesting.
One thing I did NOT do, however, was analyze the level extensively for backroutes. I think I got all the "use the multitude of available builders to get to the exit" methods cut out, but the funny thing with backroutes is that you can't always catch them all yourself. The level file is attached to this post. If you guys could check it for backroutes, I'd appreciate it.
I just finished this level in DOSbox with 100% and had 12 seconds left on the clock, so it's certainly doable. The solution does not require any split-second timing.
Oh yeah, just to make it clear: all the clouds and the sun are background tiles, and there are no hidden traps or secrets. What you see in the picture is definitely what the level is like, so the solution requires you to think and not know the special trick.
Like I said, the level's attached to this post as LEVEL010.DAT. It will overwrite Beach 1, so backup the original before using it.
Post by: ccexplore on October 19, 2009, 10:09:12 AM
The level file is attached to this post. If you guys could check it for backroutes, I'd appreciate it.
I just finished this level in DOSbox with 100% and had 12 seconds left on the clock, so it's certainly doable. The solution does not require any split-second timing.
That was fun! I've attached screenshots for my 100% solution. Unfortunately I unpaused by accident while trying to capture the "final" screenshot, so in addition to not having that screenshot, I don't know how many seconds were left on the clock, but it was definitely a lot more than 12 seconds (I'm pretty sure at least 1 minute left if not 2). If you need additional explanations I'll PM you. Possibly a backroute since I did have a few leftover skills, but hard to tell.
Post by: GuyPerfect on October 19, 2009, 07:52:45 PM
I can tell already that I'll be making a bunch of levels now, so I'll start a new thread for those instead of cluttering up this one.
Post by: GuyPerfect on October 19, 2009, 08:33:08 PM
Post by: ccexplore on October 19, 2009, 09:10:33 PM
I've just tested Blocker on a non-Classic tribe. It didn't do anything. Just made my Lemming part of the background.
Cool! Good to see my theory confirmed, at least partially.
Even though it doesn't actually block anything, will the blocker still be freed if the ground it stands on is removed? Also, can you check whether you can assign overlapping blockers (ie. close enough together that their arms overlap, say) on a non-Classic tribe? Just want to assess the potential of blockers on non-Classic tribes.
Post by: GuyPerfect on October 19, 2009, 09:42:50 PM
Post by: ccexplore on October 19, 2009, 10:39:01 PM
The Blocker is merely a graphical change. It can be dislodged, overlapped or whatever. The only thing you could hope to achieve with it is to keep a Lemming from walking off the edge.
So basically a blocker that doesn't block but otherwise behave more or less the same. This is actually still somewhat useful and interesting as long as you don't think of it as a blocker, but instead as sort of a new skill ("waiter" or "idler" if you want). There are already existing custom levels out there, even for Lemmings 1, that don't use blockers for their blocking functionality (and I don't mean glitches either), so there's a precedence for this.
Post by: GuyPerfect on October 19, 2009, 10:56:52 PM
Post by: Mindless on October 19, 2009, 11:05:10 PM
Before you get any fancy ideas... The editor I'm making will disallow Blockers to be used on any tribe but Classic and will disallow any Classic stages from being more than one screen tall. This is not negotiable.
That's rather moot since you can't take away ccexplore's hex editor.
Post by: ccexplore on October 19, 2009, 11:47:31 PM
That's rather moot since you can't take away ccexplore's hex editor.
Yep, besides, as I said, it's not exactly an innovation to use blockers to stall individual lemmings rather than to block other lemmings. There is a rather well-known custom level (which I was alluding to in my previous post) for Cheapo (and now Custom Lemmings) that was all about this concept. It's not that unfair either if I simply put a note with my levels clearly stating that the blockers are in fact "idlers", just with their skill names "misspelled" in the game. From what you've told me so far there are no glitchy behaviors of any sort, that they are simply blockers without the blocking.
And don't forget that I can program too, so there's nothing to stop me from writing a program that let other people use blockers on non-Classic stages, I'm afraid.
Post by: GuyPerfect on October 20, 2009, 02:35:28 AM
This is a screenshot of the skill selector program I made in Visual Basic to apply whichever skill assignments I desired to the current level. This is not part of the editor, and the editor needs something with the same functionality.
As a bit of practical humor, I would love to use the picker box for selecting the level's skills. However, there still needs to be a different piece of the user interface for storing the settings and letting the user decide how many of each skill to use.
Now's your chance to suggest a feature, since I have no particular leanings as to what will be implemented!
Post by: Dullstar on October 20, 2009, 02:44:36 AM
Post by: ccexplore on October 20, 2009, 03:28:31 AM
1) Since there are like 50 different types of skills, having only a dropdown list for the combo box to select skills from may get a little tedious (though I suppose with only 8 different
2) Not a high priority, but I think I might like the idea of being able to re-order a skillset without actually changing the type and number of skills (eg. swap the ordering of "basher 5" and "swimmer 6" so that in the game, the swimmer icon is shown left of the basher). There are a number of ways this can be implemented, with drag and drop being the most natural (if your UI framework supports that).
=======================
A completely different UI would be to follow the "Practice Mode Skills Selection" screen in the actual game, but with full drag-and-drop capability. So you'll have a 10x5 grid of skill icons at the top, and below that you have a row of 8 slots resembling the skill toolbar in the game, with an edit box for number of skills at the bottom of each slot. You drag from the 10x5 grid onto a slot in the skill toolbar to add a type of skill, use the edit box and keyboard to enter the number, and maybe have a garbage bin as a drop target for deleting a type of skill from the toolbar. Rearranging skills within the toolbar would be just another drag-and-drop.
I can totally understand why you may be opposed to this idea though, since it likely takes more coding to implement and probably a little more testing effort as well. It also takes up more screen real estate, although that may be acceptable if it's a modal dialog box that must be brought up and dismissed.
=================
Yet another possibility would be sort of a hybrid: same basic interface as your VB program, but instead of a drop-down list, the chevron button, when clicked, actually pops up a floating pane showing the 10x5 grid of skill icons. You then click on the one you want, the pane goes away, and the combo box now shows the name of the skill you've just selected. You might want to change the graphic of the chevron button to something else to indicate that it's not a normal dropdown.
=================
[edit: one more idea]
[edit2: idea withdrawn]
Post by: namida on October 20, 2009, 04:13:00 AM
Yep, besides, as I said, it's not exactly an innovation to use blockers to stall individual lemmings rather than to block other lemmings. There is a rather well-known custom level (which I was alluding to in my previous post) for Cheapo (and now Custom Lemmings) that was all about this concept.
And even predating that, the idea for the level came at least partially from a well-known backroute to Mayhem 13.
Post by: ccexplore on October 20, 2009, 08:04:42 AM
[edit: one more idea]
For something totally different, you can actually just have a single multi-line edit box with text selection support. The user actually just type in the skillset into the edit box like this:<snip>
Upon further thought, that's a terrible idea. While there are keyboard shortcuts to handle text selection, cut, copy and paste operations, the keyboard shortcuts are not standardized across platforms, so what is familiar to some people might be unfamiliar to others, not to mention the likely majority of users who uses the mouse for that sort of things. And without select, cut, copy, paste operations, you might as well go back to the first idea mentioned (combo boxes with autocomplete keyboard entry allowed).
Post by: Clam on October 20, 2009, 08:51:13 AM
As a bit of practical humor, I would love to use the picker box for selecting the level's skills. However, there still needs to be a different piece of the user interface for storing the settings and letting the user decide how many of each skill to use.
Now's your chance to suggest a feature, since I have no particular leanings as to what will be implemented!
I think just an alphabetical drop-down list would be fine. With autocomplete of course. For deleting a skill, you could have a blank (or <no skill>) option in the drop-down list. And instead of dragging and dropping to swap skills, you could add buttons to move the selected skill up or down in the list.
Re blockers: if they lose their primary functionality outside the Classic tribe, then it's probably better not to have them available elsewhere. Yes, there's the hex editor again, but remember there are other ways to make a lemming sit there and do nothing, like:
- attractor (possible side effects)
- twister
- ballooner stuck in terrain
plus a whole bunch of temporary stalling methods (eg. jet pack).
Post by: geoo on October 20, 2009, 05:23:58 PM
There are some places in the level where it's just impossible to place a blocker (i.e. you cannot assign the skill to any lemming at certain positions); also trying to free the blocker, be it by removing terrain underneath, or a nearby explosion, crashes the game.
So except after testing possible positions and removing blockers in a level, I guess it isn't a good idea to use them.
Yet I'd not be in favor of preventing an editor to allow setting that skill, or making larger vertical Classic levels in that regard, if merely for allowing easier experimentation.
I think an appropriate way to handle settings that might glitch up the game would be to issue a warning to the level designer in that case.
Post by: GuyPerfect on October 20, 2009, 05:34:45 PM
I think an appropriate way to handle settings that might glitch up the game would be to issue a warning to the level designer in that case.
It's increasingly apparent that Classic levels were intended to only be one screen tall and that Blocker was only intended for Classic levels. Manipulating the game to behave otherwise can lead to a better understanding of the game's mechanics at the most, and entertain one's curiosity at the least. For the editor to say "This is a bad idea, but I'll let you do it anyway" falls into the category of "do it because you can," and that's not always a valid rationalle.
For what it's worth, though, considering that there are legitimate uses for doing things that are otherwise a bad idea, I'll toss in a switch that enables the user full access to all features available in the level format that will be activated by a command line argument.
Post by: ccexplore on October 20, 2009, 07:24:37 PM
Post by: GuyPerfect on October 20, 2009, 08:47:49 PM
This one should be challenging for at least a couple minutes before you Lemmings masters figure it out. (-: 100% is reasonably easy to pull off with time to spare, so if you're stumped, keep at it!
Cavelems: Spelunk 'n' Dunk
Time: 4:30
Skills: 4 Swimmer, 5 Glue Pourer, 20 Builder, 1 Parachuter, 3 Flamethrower
Post by: ccexplore on October 20, 2009, 11:41:37 PM
I also did some quick prototyping of the skill picker interface ideas myself in VB. I found that even with 51 skills, picking the desired skill out of the alphabetized dropdown list is not too bad at all. Keyboard entry into the combo box would be nice but I'd even say that's not absolutely necessary. I believe there's no need for anything fancier.
I think ClamSpammer's idea of having an item in the list corresponding to "remove this skill" has merit. In my prototype I put it as "(None)" at the top of the list. With that, you can even eliminate the checkbox if you want. Or you could keep it but have it only disable/enable the skill count edit box, and sync its state with the combo box's selected item (ie. uncheck the checkbox if user pick "(None)" in the combo box, and vice versa, and so forth).
In my prototype I set the dropdown list size to show about 27 items, which is enough so that more than half the list is shown at once. This makes it very easy to use the scrollbar to jump to the top half or the bottom half, although I might increase the list height a little more to ensure that it doesn't cut off in the middle of an alphabet (eg. the first half should end with for example, the last "M" skill). On a 1280x1024 screen it takes up about half the screen's height, so it should still fit in 800x600 I think, depending on font sizes.
I'd say go with the simple interface, and if enough people complain then we can do something else for version 2, but I doubt there'll be much complaints.
Post by: ccexplore on October 21, 2009, 11:41:52 AM
This one should be challenging for at least a couple minutes before you Lemmings masters figure it out. (-: 100% is reasonably easy to pull off with time to spare, so if you're stumped, keep at it!
Cavelems: Spelunk 'n' Dunk
I've attached screenshots of my solution. It was relatively easy to figure out for me, but somewhat of a pain to execute. Worst moment was when I thought I was done, and then the game reminded me right at the end that the parachuter is a permanent skill, which translates to every fall being a chance for the lemming to go off course if you don't pay attention and adjust.
Overall it's a good level and I enjoyed it, but I find myself liking the Beach level better. Still, I might revisit this level some other time and see if you really need that many builders.
Post by: GuyPerfect on October 21, 2009, 07:07:14 PM
That said, the solution I had in mind when making the level is available in this here YouTube clip!
Post by: weirdybeardy on October 21, 2009, 07:52:19 PM
Heh, I've just read that paragraph back to myself and it sounds really patronising, but it wasn't meant to be.
I admire anyone with programming skills!Oh, and the YouTube clips are great.
Post by: ccexplore on October 21, 2009, 08:16:07 PM
That said, the solution I had in mind when making the level is available in this here YouTube clip!
Interesting. One thing I still haven't quite gotten used to is the maximum safe falling distance in Lemmings 2. Some of the falls in your solution I wouldn't have dared to try.
Post by: GuyPerfect on October 22, 2009, 01:28:01 AM
It's attached as LEVEL000.DAT and will replace Classic 1.
Classic - Always the Long Route
Time: 3:30
Skills: 2 Rock Climber, 1 Bomber, 2 Platformer, 1 Slider, 2 Laser Blaster, 2 Shimmer, 1 Basher
Post by: Dullstar on October 22, 2009, 02:58:53 AM
Post by: ccexplore on October 22, 2009, 03:10:53 AM
But you know, Dullstar's got a point. If you keep on making custom levels instead of wrapping up the editor so that other people can start doing that stuff, it's going to get everyone very annoyed very soon. =========
@Dullstar: GuyPerfect can fill in the details of what's left, but one obvious missing piece is the skill selector. GuyPerfect is currently using a separate stop-gap program for that, one that only runs on Windows.
Post by: GuyPerfect on October 22, 2009, 03:42:48 AM
I would like that when the project enters beta testing, you guys won't have any bugs to report.
Some tribes need to have their graphical display adjusted a bit. Some exits are composited of multiple elements (like the flag on the Medieval exit being a separate part from the castle thing), certain objects like the cannons and chains need to be supported, and there are a few problem elements in the official levels that were put in the files incorrectly that need to be fixed on load so that the editor handles them properly.
Some user interface elements still need to be invented. These include the skills menu, the save/load/etc. functions, and object properties like the number of repeating steel blocks or the number of links in the chain. I'm still considering how to go about doing this. The picker box region can be repurposed based on context of usage, so I may be able to avoid implementing additional windows whatsoever.
There are other circumstances slowing development that do not pertain to the project, and I will not be bringing them up here.
Post by: ccexplore on October 22, 2009, 04:22:31 AM
These levels are the byproduct of testing, actually.
Figured you're going to say something like that. Of course, the argument is somewhat weaken by the fact that you're creating real levels, instead of levels targeting particular things to test for.
I think it would be more convincing if you had included a brief summary of bugs you've actually fixed (or some other sort of progress report) as a result of the time spent on creating and playtesting the levels. I'm certainly not trying to stop you from creating more levels for fun since I'm certainly having fun playing them myself, but if you're going to also claim testing effort for those, you really should clearly communicate to everyone that progress is actually being made on that front.
I would like that when the project enters beta testing, you guys won't have any bugs to report.
Well, a man can dream I guess.
(Not implying anything one way or another about your coding skills, just a general observation about programming and bugs. Then again, I suppose one can always claim something's a "feature". )
Post by: GuyPerfect on October 22, 2009, 04:42:17 AM
Post by: ccexplore on October 22, 2009, 08:27:30 AM
And if you don't want to receive any further progress updates, you could have asked more directly.
Typo?I thought I was being clear, but anyway: I personally have no complaints with you spending the rest of your life making custom levels and never actually releasing the editor, if you so choose; however, I say it's a bit of a stretch to try to pass the levels off as serious testing activity for the editor. If you're going to do that, at least provide a progress update alongside each of your levels to prove that something was fixed or completed as a result, or at least that you've covered something not previously tested with your "testing".
To put it differently, if your current levelmaking activity counts as testing, then I think you've gotten to the point where you should consider distributing the testing effort to a wider set of people then yourself. Surely having 5 (say) people
[edit: it may well be that the amount of time you spent on the levels are a miniscule fraction of the time you spent on making coding/design/bug-fixing progress with the editor, in which case it's not a big deal. But currently your publishing level after level, with no progress report on the editor itself until Dullstar asked, only re-inforces a perception, however wrong it may be, that you may be spending more time making levels than actually making the editor. Which was exactly my point.]
Post by: Simon on October 22, 2009, 08:52:03 AM
I would like that when the project enters beta testing, you guys won't have any bugs to report.
RMS is not amused.
-- Simon
Post by: ccexplore on October 22, 2009, 09:04:59 AM
Post by: Clam on October 22, 2009, 09:09:16 AM
Anyway, I doubt we'll get to the point of comparing GP to the "owners" referred to in the linked article - unless, of course, he really does plan to "Profit!" as jokingly mentioned earlier
Post by: ccexplore on October 22, 2009, 11:28:17 AM
:I wanted to see how much puzzle I could pack into a single screen of level, and the answer is... not very much. The result is a relatively easy level, though the answer might not be obvious at a glance.
Well at least I didn't find it too easy. After a number of false starts, I eventually ended up with the attached solution. This time I used up all the skills given.
[edit: tried again and finally found a 2nd solution that feels more "normal". With 1 leftover shimmier. Once again featuring a fall that looks deadly but apparently isn't. Attached]
[edit2: confirmed my 1st solution can be improved to 1 leftover rock climber, and about 1:30 left on the clock]
I haven't tested Attractor yet, but everything else seems to work just fine.
Try nuking the level......
That said, nothing harmful seems to have come of it.
Post by: Simon on October 22, 2009, 01:37:26 PM
I will continue to read about the development here as I've done all the time. So back to the topic, yup.
-- Simon
Post by: Dullstar on October 22, 2009, 08:12:21 PM
Post by: Minim on October 22, 2009, 08:42:47 PM
Anyway, I wonder how many skills GuyPerfect have got on the editor this time (Probably all, I guess
). When I was thinking of editing Lemmings 2, I would just modify the skills on every L2 level created, but what I find amazing is that you can artistically create new levels from scratch.
Post by: ccexplore on October 22, 2009, 09:52:22 PM
So yeah, that's what GuyPerfect's working towards.And since it's just an editor (ie. no playtesting or anything advanced like that for now), skill selection is just a single feature and doesn't require one to add individual support for each individual skill.
Post by: GuyPerfect on October 24, 2009, 12:48:33 AM
Well at least I didn't find it too easy. After a number of false starts, I eventually ended up with the attached solution. This time I used up all the skills given.
YouTube again
Post by: Minim on October 25, 2009, 10:31:11 AM
But is there possibility that we can play some of these levels without using DOS? My dosbox doesn't work at all.
Post by: Dullstar on October 25, 2009, 10:25:00 PM
Nice youtube clip
But is there possibility that we can play some of these levels without using DOS? My dosbox doesn't work at all.
O RLY? Start a thread in Help and maybe we can figure out, "Hey, uh, what's wrong with this?"
Post by: ccexplore on October 26, 2009, 09:31:38 PM
and there are a few problem elements in the official levels that were put in the files incorrectly that need to be fixed on load so that the editor handles them properly.
Just curious, how was it that if they were put in the files "incorrectly", that the game itself still handles them fine?
Maybe I'll understand better if I know exactly which elements in which levels you were talking about.
Post by: GuyPerfect on October 27, 2009, 12:07:09 AM
Post by: ccexplore on October 27, 2009, 12:30:27 AM
For objects, I've told the editor to just ignore them, and a few steel blocks here and there disappear from levels during load.
Weird. Is there any pattern to how invalid object IDs in L2BO gets mapped to the expected object IDs of the missing steel blocks? Although I guess it doesn't matter too much, since custom levels created from the editor won't have this problem.
Post by: weirdybeardy on October 27, 2009, 01:42:20 PM
At the moment I'm fiddling around with Mindless's old "provisional" L2 editor, just to amuse myself. I might publish the results of my half-hearted experimenting up here - if I manage to create anything worth sharing. So, umm... yeah. Sorry if that's slightly off-topic.
Post by: Mindless on October 27, 2009, 02:15:15 PM
At the moment I'm fiddling around with Mindless's old "provisional" L2 editor, just to amuse myself. I might publish the results of my half-hearted experimenting up here - if I manage to create anything worth sharing.
I think you mean geoo's PCL2ED.
Post by: weirdybeardy on October 27, 2009, 04:22:13 PM
Post by: ccexplore on October 27, 2009, 07:02:06 PM
Hi all. Glad to see this thread hasn't dried up yet.
I've actually already toyed with the idea of combining PCL2ED with supplemental programs to end up with a suite that taken together, has enough functionality for basic level editing. However, that turns out to not work mainly because PCL2ED is simply not good enough for real level editing. In fact, it keeps locking up my XP laptop (granted, it has one of the worst brand of graphics cards out there, so the display driver is probably at least partly to blame), and even on a better machine, I find that the inability to manipulate whole sprites rather than individual 16x8 tiles is a real roadblock to serious level editing.
Still, if you're desperate enough to consider using PCL2ED to edit levels, I can go about and see if I can whip up some quick UI for editing level stats (eg. skills etc.), so that taken together, you get enough basic functionality to (kind of) edit levels without resorting to a hex editor. Of course, given the little free time I have nowadays, I sincerely hope that GuyPerfect will beat me to it with his full-function editor.
Post by: weirdybeardy on October 27, 2009, 08:11:16 PM
Quote
Still, if you're desperate enough to consider using PCL2ED to edit levels, I can go about and see if I can whip up some quick UI for editing level stats (eg. skills etc.), so that taken together, you get enough basic functionality to (kind of) edit levels without resorting to a hex editor. Of course, given the little free time I have nowadays, I sincerely hope that GuyPerfect will beat me to it with his full-function editor.
I wouldn't call myself "desperate" - merely curious.
I know of PCL2ED's limitations, but it's interesting enough to mess around with until the next big thing comes along. I've got a real appetite for editing Tribes since I re-released some of my old CustLemm levels on the archive. It just feels like a natural progression. I'm a little surprised that nobody has tried to fully "Lemmix" L2 before now. 'Cos let's face it, GuyPerfect is making it look easy so far. I'm grateful to geoo and to GuyPerfect and to anyone making an effort in this area.
I salute you!Right, I'm off to shuffle some 8x16 tiles around.
Bye for now.
Post by: ccexplore on October 27, 2009, 08:24:41 PM
I'm a little surprised that nobody has tried to fully "Lemmix" L2 before now. 'Cos let's face it, GuyPerfect is making it look easy so far.
If by "Lemmix" L2 you mean work out the game mechanics, then that's a whole different animal from what GuyPerfect's doing. If you're just merely talking about an editor, then give some credit to geoo for trying.
I think the simple fact is, until recently there just hasn't been enough expressed interest in custom levels for Lemmings 2, compare with Lemmings 1. I said "expressed" because for all I know, maybe the interest is there all along, but just never talked about in the forums. I suppose it's also a bit of a chicken-and-egg thing.
=========
Oh, and one more thing: almost none of the objects are displayed correctly in PCL2ED right now, far as I can tell. So try not to lose track of where the entrances and exits are.
Good luck.
Post by: weirdybeardy on October 27, 2009, 09:46:34 PM
After a couple of hours of experimenting with PCL2ED, I feel reasonably confident that I could scrape together a custom level of some sort. Patience and precision is required, but I've got no problem with that. I can't assign skills, make a level larger or smaller, or give it a name (at least until I figure out how to use a hex-editor and all that jazz)... but being able to modify scenery and then playtest it immediately in DOSBox makes me a happy bunny indeed.
It's interesting what you say about expressed interest in custom L2, because I was always under the vague impression that because L1 and ONML are considered timeless classics (and rightly so
), the customisation thing with L2 never materialised because although people love the game itself (I certainly do!), the motivation wasn't there because poor old Tribes would exist in the original game's shadow... or something. I dunno. I'm really just talking out of my backside now. 
Now I'm itching to get back to re-jigging some Highland levels (my favourite tribe), so you'll have to excuse me.
Post by: geoo on October 27, 2009, 11:36:10 PM
However on my current computer it doesn't, and as I got a PM from weirdybeardy yesterday, I had a look into that horrible code again and found the cause. (In fact, for weirdy it seems the problem didn't just cause objects not to be displayed, but crash the entire thing).
Issue was that there were some variables that I didn't initialze, which is one of the most blatant errors possible.
Upon finding that out I quickly fixed it, fixed version can be downloaded from here: http://geoo.digibase.ca/PCL2ED/
Now objects do display again, and you can place composite tiles (however once they are set, you cannot move them around anymore).
One archive is the source, on is the standalone app (win32) and one has the app, the level and style files and a batch file for opening the first classic level.
I'm currently learning to use Qt for GUI design, and as an exercise I started writing an editor for the general level stats and skill distribution, just because it fits as exercise and even might have some practical use. I hope to release this in a few days, and gain some experience with Qt on the way.
But soon(?), when GuyPerfect releases his editor, you won't have to deal with the crappy controls of PCL2ED anymore.
@GuyPerfect: I didn't find your last level easy to figure as you feared it might be; in fact I found it to be a very nice puzzle.
Post by: ccexplore on October 27, 2009, 11:52:23 PM
However on my current computer it doesn't, and as I got a PM from weirdybeardy yesterday, I had a look into that horrible code again and found the cause. (In fact, for weirdy it seems the problem didn't just cause objects not to be displayed, but crash the entire thing).
It was pretty bad on one my XP laptop too, as I mentioned earlier. In fact it consistently locked up Windows solid on that machine (not even a bluescreen) within seconds of running, which is somewhat of an impressive feat actually.
I know I said the video driver is probably partly to blame, but I don't think that lets your program off the hook, since I hadn't had any other program screw up Windows that badly on that machine. I don't have my XP laptop with me right now, but I'll definitely try your fixed version on it ASAP, hopefully with much better results. On a Vista machine where PCL2ED was at least working, it now displays the objects for me, so it's definitely looking more promising. Thanks!
Post by: ccexplore on October 28, 2009, 11:47:19 AM
I still find though that after repeated use on my Vista machine, some graphics operations in Windows noticeably slow down, so there might still be some memory or resource leaks in your program, but on the whole it's working fine now.[edit: I spoke too soon. PCL2ED locked up my XP machine again later that night.
It was happening when I was moving the main window containing the level and it was overlapping one of the other windows while being moved, which I think might've also been the trigger for previous lock-ups in the buggy version of the PCL2ED. As I said, buggy video driver definitely, but I'm definitely curious what your program is doing that the buggy video driver is disagreeing with so violently. ]In the meanwhile, to fill in some of the void in the current state of affairs, I've quickly whipped up a program for editing level stats and skillset: PCL2STAT. Like PCL2ED, it only works on decompressed level files, and you need to specify the file to open on the command line, just like PCL2ED.
Currently it lets you change the following:
- title
- screen starting x and y positions
- time limit
- release rate
- max # of lemmings lost to still get gold
- all 8 skill slots
This should cover almost everything.
In addition, there's a button that will clear the level of all terrain and objects, perfect for getting a clean slate to start your new custom level on!
[There's also a button for changing the size of the level, but that hasn't been actually implemented yet.]
I know geoo said he's working on something similar, and of course there's GuyPerfect lurking somewhere, but now no one has to wait! I think it'd still be good though if geoo finishes his version of the stats/skills editor.
Post by: GuyPerfect on October 28, 2009, 05:57:20 PM
I know geoo said he's working on something similar, and of course there's GuyPerfect lurking somewhere, but now no one has to wait!
I'm still keeping up on the thread. I'm just not posting updates.
Post by: weirdybeardy on October 28, 2009, 06:01:08 PM
And well timed. I just spent this afternoon improvising and building a new level for the Polar tribe. It took me a couple of hours (or maybe three, I lost track of time) and a lot of fiddly tile-editing to get the edges of terrain nice and neat, but I was fairly impressed with my results. I just threw in everything and made it up as I went along, and it was easier than I thought to build a level that looks okay, puzzle aside. Some points I'll quickly mention:I saved my "custom" level by pressing F3 then immediately ran the file using L2 on DOSBox. Everything was fine, except for the exit igloo: the lemmings who reached the exit didn't exit - they just walked past it.
When I re-opened the editor after that (using my already-built level slot), some of the objects (mainly steel) had vanished, and some of the terrain tiles had also gone. It looked like it could've been a glitch, 'cos there was no apparent logic to it. I have a sneaky suspicion that I may have exceeded the max number of objects - but if that's the case, then why did the level run perfectly to start with?
I tried a little bit of everything on my level. The ice-cube trap worked fine, the swing-chain wotsit was also fine (but how do I adjust the length of the chain??), and the cannon was fine (but again, how do I adjust it?).
Heh, I'm actually slightly taken aback at how quickly all this seems to be happening.
Is the dawn of the Custom Tribes era almost upon us??? @GuyPerfect: You posted your reply while I was writing this up.
Any news or updates...?
Post by: GuyPerfect on October 28, 2009, 06:11:40 PM
I saved my "custom" level by pressing F3 then immediately ran the file using L2 on DOSBox. Everything was fine, except for the exit igloo: the lemmings who reached the exit didn't exit - they just walked past it.
When I re-opened the editor after that (using my already-built level slot), some of the objects (mainly steel) had vanished, and some of the terrain tiles had also gone. It looked like it could've been a glitch, 'cos there was no apparent logic to it. I have a sneaky suspicion that I may have exceeded the max number of objects - but if that's the case, then why did the level run perfectly to start with?
Map features like exits and traps don't seem to work if the Lemmings are walking on steel when they pass the trigger points. I plan to investigate this further.
There is memory allocated in the level file for 64 objects; regardless of type, size or location. If you exceeded this limit of quantity, they couldn't have shown up in the level when you played it.
Post by: ccexplore on October 28, 2009, 06:55:35 PM
Map features like exits and traps don't seem to work if the Lemmings are walking on steel when they pass the trigger points. I plan to investigate this further.
I browsed through the object data in style files a few days ago, and it seems like trigger areas may be stored as object subparts. (More precisely, using this document as a reference, they seem to be part of the "M subentries" of an L2OB entry, with the byte at offset 0x0C of subentry set to value 0x80.) You mentioned that objects can overwrite other overlapping objects, so if trigger areas are actually object subparts, it would stand to reason that they could be overwritten by steel (or other objects in general) in the same manner.
[edit: perhaps what I said above will make more sense if I note that in Lemmings 1, trigger areas are handled such that they are triggered if a lemmings is standing on pixels within the trigger area, and not a collision criteria of overlapping boundary rectangles. Assuming triggers are modeled the same way in L2, this is why if you look at the L2 object data for trigger areas of traps and exits, their positioning are usually immediately at and below where "ground level" is located for the object, in order to work the expected way]
I'll have to browse through the official L2 levels to see whether any of them actually have trigger areas that overlaps with steel and other such objects. I know for a fact that in Lemmings 1 you have something similar going on, except in that case, objects would overwrite the steel, so usually you just lose steel protection in some places rather than losing the object trigger.
Post by: ccexplore on October 28, 2009, 07:13:14 PM
@ccexplore: This is great, thanks!
You're very welcome. PCL2STAT took about the same amount of time to write as one of you guys making a custom level for Lemmings 2 (well okay, discounting my time spent on learning about the file formats), so I simply feel compelled to make it happen.
And if you're able to sort through the technical troubles with your custom level, I'd love for you to upload it to the thread so we can try it out.
the swing-chain wotsit was also fine (but how do I adjust the length of the chain??), and the cannon was fine (but again, how do I adjust it?).
According to existing documentation geoo posted:
Quote
WASD in Object mode extends/contracts the selected object, i.e. for some objects like steel, water or the swing chain it is possible line up replicates of an object horizontally or vertically.
I believe what it means is that if you select the chain or cannon, you can use "A" and "D" on the keyboard to contract/expand horizontally, and likewise W/S for vertical. I haven't tried it myself though.
Post by: weirdybeardy on October 28, 2009, 08:39:59 PM
It's decompressed and it replaces Highland level 1. Please could somebody give it run through to see if all the objects are in place...?It's not exactly a proper level, it's just a test-level I threw together in a short space of time. Feedback would be greatly appreciated!
Thanks!
Post by: ccexplore on October 28, 2009, 11:32:07 PM
I'll have to browse through the official L2 levels to see whether any of them actually have trigger areas that overlaps with steel and other such objects.
I've just started on my browse-through and already found something of interest. Classic 9 apparently has an exit that sits on top of steel, but on closer inspection, things were not as they seem.
I've already noticed, when I was browsing through the object sections of style data, that every style has 2 versions of exits: a regular one, and one that looks just like the regular one, but has steel graphics where the trigger area is expected to be located. At the time I didn't quite connect the dots, but when I finally saw one of these "steel exits" being used in Classic 9 (instead of the regular ones), it all connects now.
On Classic 9, in addition to using the "steel version" of exit, the surrounding steel has all been carefully placed to avoid overlapping the steel portion of the exit object! This strongly suggests my theory about trigger areas affected by the overlapping objects overwrite phenomenon GuyPerfect shown before, necessitating the use of a special "steel version" of exit objects for those occasions. Unfortunately, there are no such analogs for traps, so you might simply have to avoid placing traps on top of steel blocks (as I finish my sweep thru the levels, I can confirm whether that's the case for all official L2 levels).
Post by: Dullstar on October 29, 2009, 01:46:06 AM
I'll have to browse through the official L2 levels to see whether any of them actually have trigger areas that overlaps with steel and other such objects.
I've just started on my browse-through and already found something of interest. Classic 9 apparently has an exit that sits on top of steel, but on closer inspection, things were not as they seem.
I've already noticed, when I was browsing through the object sections of style data, that every style has 2 versions of exits: a regular one, and one that looks just like the regular one, but has steel graphics where the trigger area is expected to be located. At the time I didn't quite connect the dots, but when I finally saw one of these "steel exits" being used in Classic 9 (instead of the regular ones), it all connects now.
On Classic 9, in addition to using the "steel version" of exit, the surrounding steel has all been carefully placed to avoid overlapping the steel portion of the exit object! This strongly suggests my theory about trigger areas affected by the overlapping objects overwrite phenomenon GuyPerfect shown before, necessitating the use of a special "steel version" of exit objects for those occasions. Unfortunately, there are no such analogs for traps, so you might simply have to avoid placing traps on top of steel blocks (as I finish my sweep thru the levels, I can confirm whether that's the case for all official L2 levels).
Huh?
Post by: ccexplore on October 29, 2009, 01:49:51 AM
Post by: Dullstar on October 29, 2009, 03:17:34 AM
Post by: ccexplore on October 29, 2009, 08:03:18 AM
I've attached a custom level to this post, fresh from the editor.
Finally got around to this. Awesome! It looks like the bug is on PCL2ED's end, because all the objects are there when I played the level in the game, but just about all the objects for the left half of the level are missing in PCL2ED.
It's not exactly a proper level, it's just a test-level I threw together in a short space of time. Feedback would be greatly appreciated!
It was quite good for something you "just threw together"!
It's not hard to solve for gold, but it did end up taking up more skills than I had expected when I was done.[I've attached the compressed version of the level file here, if anyone wants to play the level w/o bothering with lem2zip.exe themselves. As weirdybeardy said, it replaces Highland 1 in the game.]
You've also proven that PCL2ED and PCL2STAT together is a workable interim solution for creating real custom levels for Lemmings 2.
When I have time later this weekend, I'll see if I can go about extending PCL2STAT to integrate better with lem2zip and PCL2ED. (For example, imagine a button in PCL2STAT that launches PCL2ED for you without making you go through the command line.) It would also be ideal if PCL2ED can look for decompressed style files in a separate directory from the Styles directory, so that the original compressed style files don't have to be moved. (That, or have PCL2ED handle the compression/decompression itself.)
Post by: geoo on October 29, 2009, 09:51:18 AM
But with Mindless having provided the lem2zip code, I could have a go at implementing this.
Ok, half of the objects not displaying was an issue when reading the file that only 32 objects were read due to the counter being incremented twice.
Fix: http://geoo.digibase.ca/PCL2ED/I'll also look into the possible memory leaks; there sure is a lot of stuff not deallocated which is not graphics related; but I'll look whether some graphics related data isn't deallocated as well. Though I thought GLut would handle that when the app is closed.
Interesting level btw, I ended up using all ropers due to some mistakes I made, and the design sure looks well put together.
And now we also know what the steel exit is for, I didn't know about the normal exit not working on top of steel.
Post by: weirdybeardy on October 29, 2009, 04:14:49 PM
I'm really getting the hang of the editor now. I'm working on a Circus level. Might release it into the wild in a couple of days.
Again, it's not what I consider a "proper" level with a "proper" puzzle. It's just a result of me having too much fun with the software. With 52 skills to play with, as well as swings and cannons and stuff, can you really blame me??
Post by: GuyPerfect on October 29, 2009, 07:59:24 PM
[...] there sure is a lot of stuff not deallocated [...]
I keep several flasks of holy water and a case of silver buckshot (had to special order it) handy for just such an occasion.
Post by: weirdybeardy on October 29, 2009, 10:03:17 PM
Please give it a playtest and let me know;
a) whether it's any good, easy, difficult, fun, boring, etc
b) if you noticed any glitches or possible problems that might effect custom level building
c) anything else that springs to mind
I'm going to try to tear myself away from PCL2ED for a while, take a break from it all and see how this thread unfolds...
Buh-bye for now!
Post by: Isu on October 29, 2009, 10:44:32 PM
I got the gold, but I think it must be a backroute, since it involves fencing through the ceiling.
Quote from: Spoiler
Fill the first hole. Turn the first lemming into a fencer just before he turns around. One this lemming has fenced far enough, turn it into a miner to end up in the chamber to the left of the exit chamber. Make a lemming jump out of the hole and fence through the wall. mine through the last wall and rope up to the exit, fill the hole the lemnings are trapped by.I found this soultion was too easy, and none of the rest of the terrain is used, which was dissappoint. But of course if this is not what's intended then that's pretty much given. I also noticed that the bottom of the two exits don't work, so I needed to get a lemming ahead to rope up to the top one.
Post by: Clam on October 29, 2009, 10:46:45 PM
Okay, here we go: my first attempt at a "real" custom level for Lemmings 2: The Tribes.
Is the lower exit supposed to be a fake? 'Cause no one likes fake exits.
Anyway, I solved the level, and I bypassed all the chains and cannons so my solution is probably a backroute. (Quite similar to Isu's - though his was even easier)
Post by: ccexplore on October 29, 2009, 11:09:00 PM
Damn, if GP keeps messing us around I'm gonna have to try this editor too...
Keep in mind that the original stated goal of GuyPerfect's project isn't just about a level editor for Lemmings 2; one could even say that the level editor is merely a side product.
So there's really no telling how much waiting you're gonna do; in the meanwhile, you might as well get your feet wet with what we have now. Right now I'm working on having my program interoperate with geoo's editor and Mindless's file decompressor. Once finished, the 3 separate programs will work together so that you won't have to deal with decompressing files yourself or type in the filename on a command line prompt.
Is the lower exit supposed to be a fake? 'Cause no one likes fake exits.
To be fair, it really might just be an honest mistake related to the recent discovery about object triggers overwritable by other overlapping objects.
Post by: GuyPerfect on October 29, 2009, 11:41:34 PM
Is the lower exit supposed to be a fake? 'Cause no one likes fake exits.
I had a simple solution getting all the Lemmings to the lower exit, but they didn't go out. I'll consider this one a "successful 100% run of a moderate difficulty puzzle" unless the exit is supposed to be a fake, in which case I'll declare it a "waste of time." (-:
Keep in mind that the original stated goal of GuyPerfect's project isn't just about a level editor for Lemmings 2; one could even say that the level editor is merely a side product.
Thank you. For this, I will forget your obnoxious skepticism from earlier and post all the updates from the last couple of weeks:
- To make sure everything was rounded out, I decided to make one level for each Tribe and fix any problems I encountered along the way.
- The Beach level was the initial test of the new picker system. I also started off testing the maximum level size (height with given width), and I found the bottom few rows of tiles didn't draw to the screen when played, but the Lemmings still interacted with the terrain. I subsequently investigated and found the logic determining how many rows of tiles will be drawn.
- The Cavelem level was a tailor-made examination of the "reveal mode" feature to ensure that all pixels were shown correctly as terrain, steel, water, traps or whatever else. The leaf hanging down on the bottom left of the entry area made me pleased with its one-pixel Glue Pourer interception capability. Additionally, I introduced a "feature" pixel type that is applied to the dinosaurs, trampolines and other objects that interact with the Lemmings.
- Although "Circus" comes between "Cavelem" and "Classic" alphabetically, the way I was handling the drawing of exit objects prevented the Circus exit specifically from being seen, placed or relocated. Just today I modified the program to handle all exits--normal as well as "on steel blocks" varieties--and Circus levels can be made now. I haven't prepared one yet, however.
- The Classic stage was just an excuse to use non-Classic skills on the Classic style. It seems I accidentally made a good puzzle out of it, but the solution was farily obvious to me when I devised it...
Next on the list is to make a sweep through all the tribes and label all the "feature" elements as well as determine the location offsets for storing certain objects in the level files.
Post by: Dullstar on October 30, 2009, 02:50:41 AM
Post by: GuyPerfect on October 30, 2009, 03:12:31 AM
Post by: weirdybeardy on October 30, 2009, 12:54:07 PM
Quote
Is the lower exit supposed to be a fake? 'Cause no one likes fake exits. Anyway, I solved the level, and I bypassed all the chains and cannons so my solution is probably a backroute. (Quite similar to Isu's - though his was even easier)
Oops.
Damn. It would appear that I suck. If the lower exit doesn't work I suppose I could switch it for an empty pit for the lemmings to get trapped in, 'cos it sounds like the top exit is the one reached by the backroute anyway. Speaking of the backroute, I could remedy that with a cheap fix involving steel and empty space and whatever. I say "could" because right now I can't be bothered and I'm happy to leave my pseudo-level as "a waste of time" (as GuyPerfect described it, and rightly so ). I am but a lowly novice. But I guess my dabblings have shown what's possible with PCL2ED, so my thanks to geoo for that.
And thanks to everyone for giving it a go. @GuyPerfect: This is supposed to be your thread, so I'm sorry if I hijacked it slightly.
Post by: GuyPerfect on October 30, 2009, 05:49:21 PM
Though I am curious... If these other programs have been around for a while, and the people who maintain them are still active and able to work on them, then why has it taken until just now for all the pieces to be put together into something useable? Though I know it's unlikely that it's out of spite, I'd like to think that it went something along the lines of "Hey, one person's doing all by himself what we could have done together all along. Let's spite him!"
Oh well. Anything to motivate productivity, I guess. (-:
Post by: Mindless on October 30, 2009, 07:14:55 PM
Though I know it's unlikely that it's out of spite, I'd like to think that it went something along the lines of "Hey, one person's doing all by himself what we could have done together all along. Let's spite him!"
Ah, that's your own fault though. You're taunting us with an editor only you have access to. Other people want to play with your toys too, and if you won't share... really, what did you expect?
Post by: ccexplore on October 30, 2009, 08:59:50 PM
Though I am curious... If these other programs have been around for a while, and the people who maintain them are still active and able to work on them, then why has it taken until just now for all the pieces to be put together into something useable? Though I know it's unlikely that it's out of spite, I'd like to think that it went something along the lines of "Hey, one person's doing all by himself what we could have done together all along. Let's spite him!"
OMG you're so full of yourself. I have nothing more to say to you......ever
=============================
Anyway, as I alluded to earlier, it might be a bit of a chicken-and-egg thing, where because we have LemEdit and the like, but nothing for Lemmings 2, the majority of expressed interest is on Lemmings 1, which in turn lessens motivation for things like Lemmings 2 editor and such ("why spend time on that when there're so many exciting things going on already in L1-world?"). The fact that the forums had historically frequently gone dark doesn't help...I for one haven't heard of PCL2ED (nor the fact that much of the file formats for L2 have actually be deciphered already) until like maybe last month or so. And first experiences with PCL2ED was less than encouraging, though it's a bit surprising now that we see how a few bugfixes make such a huge difference.
And yes, you starting this project has obviously drummed up lots of expressed public interest on Lemmings 2 custom levels, and then naturally, the longer your editor remains unreleased, the more likely people will start looking further into existing tools to see what they can do in the meanwhile. I mean, what else would one expect? Your releasing various custom levels for Lemmings 2 only puts further motiviation and drive in that direction. I feel rather sorry that you'd actually think this is some sort of conspiracy to annoy you.
Post by: geoo on October 30, 2009, 09:21:38 PM
To fill you in on the chain of events, back when I released PCL2ED, it drew little attention and quickly sank into oblivion. Being aware of how crappy it is, I didn't really promote it either.
It was only weirdy sending me a PM few days ago that made me realize that the thing didn't even work on pretty much every PC except the one I initially wrote this on. I estimate I changed 10 lines of code thereafter to get it into the state is it right now (If you don't believe me, the original sources are still up at the old address
).Even if redundand, I still intend to continue on the stats editor though, for the main purpose of getting myself to learn Qt.
In the end, I'm pretty certain once you release your editor, PCL2ED will sink into the then well-deserved oblivion again, just like LemEdit did.
Oh, and on the note keyboard commands/shortcut keys: I'd appreciate if you keep keyboard driven controls in, as I find mouse navigation to be somewhat slow for certain uses, especially e.g. menus.
Post by: Dullstar on October 30, 2009, 10:04:28 PM
Post by: GuyPerfect on October 30, 2009, 11:18:32 PM
OMG you're so full of yourself. I have nothing more to say to you......ever
\o/
I feel rather sorry that you'd actually think this is some sort of conspiracy to annoy you.
I know exactly how you feel. One time, there was this guy who was ludicrously incapable of seeing the humor in any of my posts. Must be a sorry life to lead indeed. (-:
Post by: ccexplore on October 30, 2009, 11:51:24 PM
Post by: Dullstar on October 31, 2009, 12:00:47 AM
Post by: GuyPerfect on October 31, 2009, 12:09:50 AM
You know GuyPerfect, your editor doesn't have to be perfect - why, just look at PCL2ED: It's not great, but is that stopping anyone? Nope.
I actually haven't revised anything yet to clear out any bugs or unintended behaviors. Off the top of my head, I can only think of one unintended behavior, and it's an easy fix just reworking the input logic (dragging the level boundary into the picker box cancels the drag). It's not a matter of making the editor perfect at this point; the editor simply isn't finished yet.
On the other hand, I have been considering releasing the work-in-progress build with all its not-user-friendliness since people have shown a remarkable willingness to make due with what's available to them. I've just got to finish up making the objects draw correctly in the editor and I'll be able to put it up as a "use at your own risk" public build. It's not what I would have wanted, but I'm aware that coding the remainder of the user interface will probably take more planning than I originally estimated.
I was simply going to be completely silent on it until your latest post got me just over the edge.
You weren't supposed to pop so soon. I still have another antagonism in mind and I'm not sure if I'll get a chance to use it. )-:
Post by: ccexplore on October 31, 2009, 12:10:24 AM
<back to silence>
Post by: ccexplore on October 31, 2009, 12:18:31 AM
You weren't supposed to pop so soon. I still have another antagonism in mind and I'm not sure if I'll get a chance to use it. )-:
Oh go ahead.
Ideally when I give the silent treatment it really means that. Just like how I refrained from posting any responses to Giga's posts if it's not going to add anything of value to anyone. I suppose I'm already off to a bad start here in that regard. Anyway, my focus now is not so much on your work (which I still immensely look forward to, nonwithstanding any ill feelings) as what can be done by the rest of us in the meanwhile.
Post by: Dullstar on October 31, 2009, 12:51:00 AM
On the other hand, I have been considering releasing the work-in-progress build with all its not-user-friendliness since people have shown a remarkable willingness to make due with what's available to them. I've just got to finish up making the objects draw correctly in the editor and I'll be able to put it up as a "use at your own risk" public build. It's not what I would have wanted, but I'm aware that coding the remainder of the user interface will probably take more planning than I originally estimated.
That'll be nice.
Post by: GuyPerfect on October 31, 2009, 02:12:40 AM
I've sent PMs to the following people based solely on participation in this topic. If you think you should receive a copy and are not on this list, lemme know in a PM.
In alphabetical order:
- ccexplore
- Clam Spammer
- Dullstar
- geoo
- Mindless
- weirdybeardy
The ZIP file contains all the STYLES and LEVELS from the game as well as the editor and skill selector.
Editor:
- Left and Right keys load different stages.
- Up and Down keys specify the zoom factor.
- Hold Spacebar to display and move the default screen position.
- 1 and 2 keys select if Objects or Presets are displayed in the picker.
- Backspace toggles Reveal mode.
- 3, when Tile and Preset elements are selected, toggles background status. This can be determined with Reveal mode.
- Delete deletes the selected elements.
- Left-click and drag will either move an element or draw a selection box.
- Right-click and drag will pan the display.
- Shift forces an all-inclusive selection box. Ctrl forces an inversion selection box.
- Click and drag the dotted lines to resize the stage.
- Scroll Up and Scroll Down on the mouse specify the zoom factor.
- Chains, cannons, catapults and steam jets aren't implemented yet.
- The S key will save the current stage to a file called LEVEL___.DAT.
- Some objects in levels (namely many steel blocks on the Polar tribe) will not load.
- Clicking an element in the picker box will let you place one in the level.
- Click-and-drag when placing steel blocks, water or presets to insert multiples into the level.
- Esc will deselect selected objects and picked elements.
The resulting LEVEL___.DAT file is required for the skill selector to work. The skill selector can modify the following:
- Level name
- Time limit (minutes and seconds)
- Release rate (up to 20, and negative values possible. Needs investigation)
- All 8 skills and their quantities
Post by: Clam on October 31, 2009, 02:56:06 AM
Post by: ccexplore on October 31, 2009, 04:19:04 AM
But hey, at least I made a Classic level with non-Classic skills, right? I haven't tested Attractor yet, but everything else seems to work just fine.
Without even thinking, I wound up putting an attractor in my test level in classic style. The result? Well...not quite what you expected, though it still sorta works......
I've attached the level for anyone who wants to see what happens. This level (not my original test level, which I might release later once I sort thru what skills to use) is basically just Classic 1 with the climber replaced by attractor. Just in case number of skills is at issue, I also reduced the number of each skill down to 1, so the level is most probably not solvable. It was only intended for testing Attractor in classic tribe.
Post by: Dullstar on October 31, 2009, 05:10:39 AM
Post by: Dullstar on October 31, 2009, 05:40:08 AM
Post by: weirdybeardy on October 31, 2009, 03:15:21 PM
Also looking forward to witnessing the spectacle of a Classic attractor first-hand... Oh well. Maybe tonight. Can't wait!
Post by: Dullstar on October 31, 2009, 05:10:52 PM
Ah, how often something goes wrong because I overlook something...
btw, this has nothing to do with the editor, but which files go with which tribe?
Post by: GuyPerfect on October 31, 2009, 05:34:43 PM
010 to 019 = Beach
020 to 029 = Cavelem
030 to 039 = Circus
040 to 049 = Egyptian
050 to 059 = Highland
060 to 069 = Medieval
070 to 079 = Outdoor
080 to 089 = Polar
090 to 099 = Shadow
100 to 109 = Space
110 to 119 = Sports
Post by: Dullstar on October 31, 2009, 05:58:32 PM
Post by: geoo on November 01, 2009, 12:03:06 PM
I'll try not to go into things that are obviously still provisional, as they are subject to change anyway.
For most part, the controls felt simple and very intuitive, making the editor very pleasant to use. The way you implemented area selection is very powerful for quickly selecting whatever you want.
I also liked the easy way to change the viewport by just dragging with the right mouse button.
Initially I had the same problem as ClamSpammer, namely pressing UDLR when I wanted to move a piece, and thought that having these keys for moving a selected piece or area in addition to dragging would be essential for me. I ended up covering these keys with a piece of paper, and got used to the mouse driven interface there; due to the 16x8 grid the mouse still gives sufficient precision easily, having UDLR for that functionality might still be a nice addition though.
The picker interface has the slight disadvantage that you don't see all pieces at once, and have to use the mouse to scroll, but I'm sure that once one gets used to the tilesets this will be less of an issue. I found a few oddities with it though:
You cannot scroll or directly select another tile/object when a tile/object is currently selected in the picker; and for placing multiple tiles/objects that do not connect you'll always have to re-select them instead of the piece staying selected.
On a different note, did you manage to find out about the precise positioning of trigger areas? I think in reveal mode these could be very useful.
I really liked ClamSpammer's level, requiring to set up some sort of roper web to get up. Due to making a few mistakes every now and then, I ended up having exactly no ropers left when I solved the level.
Post by: weirdybeardy on November 01, 2009, 01:46:27 PM
Quote
Now remember... Be careful not to force them.
Sorry. I'll try to rein in my enthusiasm.
Quote
Ok, I guess the best way to test this editor is to go through the entire design process of making one level (which is attached, btw, Medieval tribe).
I've given it a go. It's a nice little puzzle, and the 99 release rate makes it an interesting challenge for a L2 level.
When I can find the time I'll try to put together some more custom levels. I'd quite like to build a whole Tribe's worth (ie. 10) in a chosen style, once I can figure out which tileset is the most versatile for making a decent puzzle. After all, as I discovered with my original CustLemm packs, fashioning a worth-while puzzle is a puzzle in itself (and definitely something I'm only average at, unlike some of the supremos around here).
At the moment I've been messing about with Space teleports, seeing how they are implemented in the level itself. Seems as though they correspond directly to the order in which they're placed in the level, eg. teleport #1 beams to teleport #2, #3 to #4, and so on...
Post by: GuyPerfect on November 01, 2009, 05:55:18 PM
You seem to have a knack for building levels that look well-put together, with just the right balance of style and functionality.
What about me? )-: (-:
I make a particular effort to be artistic while making puzzles that hopefully require a little thought. I know! Maybe you just missed the levels I posted earlier! (-:
Beach - The Clam Spammer
Cavelem - Spelunk 'n' Dunk
Classic - Always the Long Route
You cannot scroll or directly select another tile/object when a tile/object is currently selected in the picker [...]
This is my fault. When I modified the input logic to allow the level boundary to be dragged into the picker box without canceling the drag, I inadvertantly made it impossible to use the picker interface while an element is already selected for insertion. The result is that when you attempt to use it, you're actually placing the element in the level but behind the picker box.
On a different note, did you manage to find out about the precise positioning of trigger areas? I think in reveal mode these could be very useful.
I haven't looked into it. It's not on my priority list. In fact, it's on that other list of things I've only briefly considered. I honestly don't see a need for it; the objects always behave the same, so it just requires a little trial and error at most to find out what makes each element function.
Seems as though they correspond directly to the order in which they're placed in the level, eg. teleport #1 beams to teleport #2, #3 to #4, and so on...
Very good to know. I haven't investigated this yet, but it's good to see it's a rather simple approach.
Post by: GuyPerfect on November 01, 2009, 06:03:30 PM
The current setup for the editor uses two input systems kinda layered onto each other. The main editor interface was made to interact with the window surface directly, and when it came time to implement the picker interface, I noticed that it wasn't going to work out very well. I started a new project and designed a well-thought-out, intuitive, dynamic user control system and was quite happy with the result. However, the way I coded the editor interface in the first place would basically require a total rewrite to make it conform to the superior user control setup, so I just left it as it was and plastered the picker interface on top of it. The result has a lot of "if" statements.
Needless to say, I'm not exactly satisfied with the way the program is set up, and I really want to start all over using everything I've learned along the way. It's the first time I actually had to implement a user interface of this type, and what I learned now will be especially useful in all my future projects, so this is by no means a loss.
Bearing in mind the needs of the program and the people using it, I'm strongly considering doing the project over in Java. I'd like to hear what's on you guys' minds. Oh yeah, and don't try the whole "But you're almost done with this one!" argument. There's only a sliver of a chance that the project in its current iteration will ever see another build. (-:
Post by: Mindless on November 01, 2009, 07:23:39 PM
Bearing in mind the needs of the program and the people using it, I'm strongly considering doing the project over in Java. I'd like to hear what's on you guys' minds.
Considering that you've given people a working build of the current editor to play around with, I don't think they'll mind if you want to rebuild from the ground up.
Post by: GuyPerfect on November 02, 2009, 12:30:10 AM
Post by: Dullstar on November 28, 2009, 10:00:12 PM
Post by: ccexplore on November 28, 2009, 10:17:48 PM
I mean, the topic was dead for like more than 2 weeks until I posted a new level 2 days ago. And you can't blame me for the general lull in the forums right now --I wouldn't have expected this topic to be on top even as recently as maybe 2 weeks ago before the lull.
Post by: chaos_defrost on November 29, 2009, 04:29:15 AM
If GP doesn't want me having it, though, never mind.
Post by: Dullstar on November 29, 2009, 07:59:32 AM
Can anyone get this level to work? My DOSBOX locked up when I ran it.
Did your copy of L2 ever work before (if not, you might have a bad copy). Also, did you remember to run L2-fix instead of just L2?
Anyway, the level works fine for me, and I enjoyed it. It wasn't too hard but it does require a little thought, and there are no horrible precision or tedium involved, which I greatly appreciate after certain other levels......
But I should note that I left some skills unused (see spoiler). Maybe that's expected but just in case there's some sort of backroute?Quote from: Spoilerleftover: 1 roper, 1 floater
I actually need to test that. I'm probably going to finish The Lemmings Strike Back! first, though.
Sometime I will get that level tested for the remaining skills at the end... it's been so long since I created it I don't remember what my intended solution was - although I'll probably remember when I load up the level.
Anyways, I guess I should get to redownloading the editor (stupid... buggy... computer... that... doesn't... work... on... any... given... operating system).
Post by: Nagnazul on October 23, 2010, 04:47:51 AM
Post by: ccexplore on October 23, 2010, 05:48:50 AM
That's where I originally got it anyway, not sure if link is still working but give it a try. Stick the programs inside the zip file into the folder where the Lemmings 2 program (L2.exe) is located on your computer. If you don't have Lemmings 2, get it from abandonia.com.
Post by: Nagnazul on October 23, 2010, 02:39:46 PM
http://perfectkiosk.net/lemmings/lgl2_10302009.zip
That's where I originally got it anyway, not sure if link is still working but give it a try. Stick the programs inside the zip file into the folder where the Lemmings 2 program (L2.exe) is located on your computer. If you don't have Lemmings 2, get it from abandonia.com.
That link is broken - do you still have it on your computer? If that's the case, could you please upload it to megaupload?
Thanks
Post by: ccexplore on October 25, 2010, 09:44:00 AM
http://www.fileden.com/files/2010/7/15/2915232/lgl2_10302009.zip
"lgl2_10302009.exe" is the main level editor program. "skills.exe" is a program used to edit the skills information for a level. As a freebie, I also threw in my own "PCL2Stat.exe" program which also supports editing the skills information etc, so you can pick whichever one you like best for that purpose. The zip file also contains the LEVELS and STYLES folders, but you don't need to extract those, they should already exist inside Lemmings 2's folder.
Buried somewhere in this "Here I Go Again!" thread are the instructions on how to use the editor. Try and see if you can dig out that information yourself. Enjoy!