L3 level editor by kieranmillar, continued from Mindless

Class Style in src/style.* loads terrain and gadgets from files. Style::load() first sorts the binary data from files into object and block, then draws them. I haven't understood the drawing from first glance.

NL has L3 styles, right. They might be only 99 % accurate. Reason: I remember how I manually painted correct shading on some of NL's L3 tiles that were merely horizontal flips of other tiles.

Maybe 99 % accuracy is good enough. What are you trying to do?

Lemming sprites, I don't believe anybody has extracted those. Spriters Resource has nothing on Lemmings 3.

-- Simon

Thanks for hosting!

Only today, I find time to adequately reply. I'm about to watch the solutions in Lix.

Geoo's txt file I found harder to read than the others probably because he was using a considerably older version of Lix

geoo directionally forced some assignments. For example, the middle two lines here are directionally forced assignments; the first and last lines here are unforced:

! 969 0 ASSIGN=BATTER 8
! 1056 0 ASSIGN_RIGHT=BASHER 21
! 1062 0 ASSIGN_LEFT=MINER 10
! 1305 0 ASSIGN=DIGGER 10

In singleplayer with heavy framestepping, it has become less common to force direction.

I made directional force part of the replay format for networking games about 5 years ago. This was to combat latency between several players on the same team. E.g., you have a lix walking towards an abyss, and want to assign walker to turn her. If your teammate also assigns walker to turn her away, and both of you directionally force your walker assignments, the lix will only turn once, away from the abyss, and the second assignment becomes illegal as desired.

I've even considered to write every single assignment into the replay with directional force, not merely those where the player actively forces. I.e., for an unforced assignment, I would look at the highlighted lix's direction, and write the assignment forced with that direction. I don't know if that would be helpful or a hindrance, in any of the three interesting scenarios: a level's terrain changes, the physics change, and networking lag.

Anyway, that's rambling and getting technical; if anybody has strong feelings on this, we can happily make a thread from this idea. On to watching replays.

-- Simon

Yes, it's an overflow bug in Lix. Good find, yes, Forestidia had the idea before, too.

It should be patched for 0.10.0, whenever that comes, as namida suggests, fallers that have achieved splat fall distance should remain splat-prone until the end of the fall.

In D, signed ints are defined to overflow by two's complement like an unsigned int, and only during interpretation treat the most significant bit as a sign bit. (In C and C++, signed int overflow would be undefined, even though implementations on contemporary machines often treat them like D has to.)

-- Simon

Yes, any 0.9.x is good for multiplayer, in particular 0.9.29 and 0.9.30.

-- Simon

Magnificent resourceful post!

Press U to save a replay during play. (I forgot whether this opens a dialog or merely saves a file without any feedback.)

-- Simon

I'm most surprised about the horizontally-narrow area. The frog is so wide and yet it has the most narrow trigger. Widening the trigger would suit the frog, but that's more intrusive than the downwards trigger extension. I'd have to test replays.

-- Simon

Frog y-3 is friendly to walkers. The other frogs (y-2, y-1, normal) are all deadly. Do you find this strange, too?

In particlar, y-2 has a a one-pixel air gap between belly and floor, yet is deadly. >_>;;



This image is from your replay, with a hack of Lix that shows trigger areas during play (important missing feature). The miners produce a gap, and the walking lix survives the upwards slope. In this light, do you think that the trigger is too short vertically? Too narrow? Or both? Or fine after seeing this?

-- Simon