Lemmini - Lemmings for Java - public Alpha

Started by 0xdeadbeef, February 21, 2006, 06:37:50 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

0xdeadbeef

Quote from: Mindless link=1140547071/165#176 date=1142376106I really don't see the big deal about the level codes anyway.  You'd have to use a some type of hash to avoid having multiple levels in different level sets having the same password.  And if the password is hard-coded into the level files, what will happen if two designers choose the same password?
The situation is even worde for algorithmic levelcodes, so I don't see the problem here. If two levelpacks use the same password, then  the levelpack has to be known. For algorithmic levelcodes, the levelpack has ALWAYS to be known to have the seed. Also it's obvious that different seeds might create the same password. The situation is FAR easier to control with fixed codes.

Quote
Edit: I can ccexplore's point about having seeded passwords, but IMHO it's a lot of work that won't be extremely useful.  Perhaps when the game is nearly finished this could be added, but it doesn't seem important right now.
The implementation itself won't be much work. The trouble created from it will however.

Mr. K

Just a question.... why the heck are we whining about PASSWORDS!?  It's not like it's a huge deal, is it?

ccexplore

No one's "whining" about anything. &#A0;The discussion about levelcodes is merely expanding through natural discussion. &#A0;First I mentioned my experience with it and some opinions and criticisms. &#A0;0xdeadbeef mentioned his views. &#A0;Mindless introduced the concern about levelcode collisions. &#A0;I threw in the idea about unlocking conditions.  etc.

Also keep in mind that having much discussion is often better than no discussion. &#A0;After all, if Lemmini doesn't interest me I would not be testing it at all.

ccexplore

Quote from: 0xdeadbeef link=1140547071/180#180 date=1142378976The situation is even worde for algorithmic levelcodes, so I don't see the problem here. If two levelpacks use the same password, then &#A0;the levelpack has to be known. For algorithmic levelcodes, the levelpack has ALWAYS to be known to have the seed. Also it's obvious that different seeds might create the same password. The situation is FAR easier to control with fixed codes.
I'm afraid I could only understand unambiguously the last two sentences.

About different seeds creating the same password, that of course can happen, although from what I understand about how the levelcodes are generated with the algorithm used in Lemmings, much of the levelcode's form comes from the seed string itself (indeed, the majority of the levelcode is just a cycling of various parts of the seed string, explaining the similarity of one level and the next level's levelcode), so it's actually relatively predictable. &#A0;Thus collisions and fixing thereof is not necessarily any harder than that for fixed, specified levelcodes.

Anyway, I was never advocating extending the algorithm to custom levels, or even necessarily using them in the official levels in Lemmini. &#A0;It was just threw in merely to show that it can be done, for better or worse.

The main thing to actually consider at this point is whether Lemmini should be using specified levelcodes that would nevertheless work in the real game, instead of having its own, separate set of levelcodes. &#A0;After all, many console ports of Lemmings already have their own separate levelcodes anyway (generally of shorter lengths in fact, due obviously to the cumbersomeness of entering levelcodes with the typical d-pad).

Mr. K

...hehe... sorry, it seemed to me that some people were complaining that Lemmini didn't have its own passwords or something.

And a Q:  I hadn't played Lemmini for a while, so the Java Webstart upgraded me from 0.51 to 0.61.  This caused me to lose my saved progress, so I had to start all over.  Is is possible to prevent this frustration?

ccexplore

Ok, continuing on buglist after upgrade to v0.61:

...is it even v0.61? &#A0;When I downloaded the jar file locally (as I've been doing all the time) and run it, it didn't trigger a resource update, and the INI file still has 0.60. &#A0;So the bug about trailing spaces in the edited Fun 25 title ("Lemmings Lemmings everywhere") isn't fixed.

But at least the two other embarassing bugs were gone. &#A0;I made a run through that tried to cover many of the traps and haven't found any issues with traps.

Anyway, other bugs:

56) walkers/jumpers, or indeed anyone who can move up, should turn around when they get too high. &#A0;Builders in the real game (perhaps not WinLemm but certainly Amiga) in fact will stop building when they get too high (you can basically define "too high" by pretending there's actual terrain at the row of pixels just off the top of the screen; it's not exactly the same as the real game but close enough). &#A0;They certainly should not be able to walk up above the level's top boundary, as they currently could in various levels. &#A0;This in turn could lead to behaviors not possible in the real game like digging down the pole near the left entrance in Havoc 7, and also subtly alter the lemming's movement in Mayhem 23 (although not enough to affect solving the level too much).

57) The builder is currently not detecting the ceiling overhead soon enough. &#A0;As a guide, in Amiga lemmings, when a lemming is in the middle of a horizontal tunnel created by a basher, if you make him build, he will stop building after one brick. &#A0;If you instead make him dig down just once before building, he will build two bricks before stopping. &#A0;Lemmini currently allows 5 build bricks before stopping when building inside a bash tunnel.

Feel free to hold off on fixing this though; I can provide you later with the exact conditions (for lo-res anyway) the game uses to check for walls and ceilings when building.

58) On Taxing 28, the trap near the exit should be in front of the terrain rather than behind, at least according to the Amiga version. &#A0;Might conceivably be an error in WinLemm's data.

59) On Mayhem 14, the "peas" in the pea soup should be behind rather than in front of the "soup". &#A0;(if what I said isn't clear, see this pic)

60) On Wild 15, the water closest to the exit is incorrectly being covered by brick terrain. &#A0;See this pic for the correct look.
 All fixed! [smiley=thumbsup.gif]

Proxima

Quote from: Mr. Ksoft / Timmy the Geek link=1140547071/180#184 date=1142394318And a Q:  I hadn't played Lemmini for a while, so the Java Webstart upgraded me from 0.51 to 0.61.  This caused me to lose my saved progress, so I had to start all over.  Is is possible to prevent this frustration?
That's a flaw that I already pointed out and has been fixed in between those two versions. So now you've got 0.61 it won't happen again.

0xdeadbeef

The usual nightly update...

Fixes/changes 0.61 -> 0.62
#  Forced resource extraction (needed for the fun 25 title change fixed in 0.61)
#  Fixed drawing order: animated objects that don't have the "no overdraw" flag set
   will not be drawn behind the terrain any more.
   Should fix ccexplore's #58-#60
#  Drawing order also fixed in minimap (all objects were drawn behind the terrain)
#  Walkers, Jumpers and Builders can't leave the level to the top any more
#  Increased number of pixels that have to be free above a builder to continue building.
#  Reworked jumper animation. Looks a little less silly in my eyes. Yet maybe not in yours.

Proxima

Just one small point..... version numbers don't carry, so what you've called 0.60, 0.61 and 0.62 should really be 0.5.10, 0.5.11 and 0.5.12. I mention this because with all these little updates, and with ccexplore finding so many bugs, you might run yourself out of available version numbers very soon.....

ccexplore

This v0.62 is looking pretty good! 8-) I think we might've reached a point where 0xdeadbeef can go back to concentrating on new features (action replay please?), and let the bugs piled up a little (it should hopefully be coming in a little more slowly now).

Then again, lately too much of the testing has been done by only one person. &#A0;I'd love to cover every single Lemmings and ONML levels in Lemmini to make sure they all held no surprises, but that's just too much for a single person. &#A0;I urge more people to play with Lemmini more often! &#A0;Pick one or two random levels a day and play it on Lemmini, make sure everything looks and works ok. &#A0;Besides, the more people, the more machines Lemmini gets run on. &#A0;Testing on different machine/OS configurations is definitely not something I can do myself even with total free time, and yet they can sometimes be the source of unexpected crashes and freezes. &#A0;Just ask Ahribar about it. ;)

Ok, buglist:

61) My fault actually. &#A0;Regarding the jumper, you should still be able to assign climbers, floaters and exploders to them, just not the other five skills.

62) I'm seeing lemmings surviving a nuking, but I'm not sure why. &#A0;Go to Taxing 16. &#A0;Set a blocker somewhere to the right. &#A0;Have a lemming build 3 bricks to the left so that the lemmings can jump up to the chain. &#A0;Increase RR to 99 and wait until all 80 lemmings are out. &#A0;Now nuke. &#A0;Most of the time, towards the end I'm seeing one or two lemmings falling down with neither an explosion countdown nor ever exploding (and the fall is long enough that they should've exploded before going off the level's bottom).

I have a suspicion this is somehow jumper-related but I could be totally wrong. &#A0;My suspicion arises because it seems if I alter the setup above so that there are no jumper lemmings before nuking, the bug doesn't seem to repro. &#A0;Yet I haven't quite work out how to repro it on isolated lemmings. &#A0;Good luck.
 All fixed. [smiley=thumbsup.gif]

Proxima

Does that mean you'll be getting on with the MIDIs now?  ;)

As for me, I should have my essay finished by tomorrow -- then a break at last, and I will certainly use at least some of the time to keep playing Lemmini and see what happens!

[EDIT: ooh, my 1111th post! Nice!]

EricLang

Not bug but wish:
I always played DOS lemmings and used to its function keys.
F1 = RR-, F2 = RR+, F3 = Climber... F10 = Digger, F11 = Pause, F12 = Nuke
Yet in WinLemmings the keys are different (I can't get used to them)
So I badly need keyboard input. And there would be at least one happy user if these were configurable.

0xdeadbeef

Fixes/changes 0.62 -> 0.63
#  Jumpers can now be assigned at least "additional" skills like Floater and Climber
#  Fixed a bug that would let Jumpers survive a nuke. Now also splatters, drowners etc.
   can be nuked - I thought they could, but there was a bug obscured by the fact that
   these types die anyway.
#  Keys F1-F8 can be used in addition to 1..8 for skill assignment.

ccexplore

Quote from: 0xdeadbeef link=1140547071/180#192 date=1142551497# &#A0;Keys F1-F8 can be used in addition to 1..8 for skill assignment.
Reread Eric Lang's post more carefully.  The keys should be assigned as follows:

F1 to decrease RR, F2 to increase RR.
F3 - F10 for the skill assignments.
F11 to pause, and F12 to nuke.

0xdeadbeef

I noticed it myself. I should really get some sleep, but at least the weekend is near.
Will be in the next release I guess.

BTW: are you sure about the Jumper behaviour? In Mary Poppins's land it's now pretty hard to set a blocker on that steep ramp. It's not in the windows version since it has no jumpers. But also in the Amiga version, the stoppers can be easily placed on the ramp.
Lemmini now definitely behaves differently from the Amiga version due to the jumpers and their limited skill assignment.