Here are my resolves again.

You'll need something to edit and compile the Java code in. I recommend Eclipse, but I'm sure there are others.

I can provide another alternative here: IntelliJ

https://www.jetbrains.com/idea/

I use this at my workplace and was positively suprised by it.

I just solved the pack and attached my replays. I think there might still be a few backroutes left.

Bigger update!

- All recently submitted levels from tan x dx and 92Dexter11 included.

- Rank amount increased from 5 to 7. (Old rank 1+2 formed a new rank in between, Old rank 3+4 formed a new rank in between)

- Some slight position switches to smoothen the new rank transitions.

The tileset looks amazing as always! Great job!

If you notice any issues, feel free to post below!

I have 3 little remarks:

- The trigger area of the water should go 1 pixel lower than the graphic. If you would put the water exactly on ground level and let lemmings walk on said ground level they would be able to walk right through it. Consider extending it 1 pixel lower.

- Consider adding a little "IN" and "OUT" sign on the teleporter/receiver graphic. I noticed the animation hints at which being which, but it is not crystal clear.

- I would mabye add another yellow row to the zapper trap (towards the trap middle) just as a little extra indication (maybe even 2 rows). 1 pixel can be a bit thin expecially if uneven terrain covers up parts of it. Maybe the 2nd row can also be slightly shorter than the first to create a little pedestal, but I would choose what looks best here.

Are you sure that 69 air pixels between floor and ceiling should already be deadly? That would mean that the falling lemming is only 5 or 6 pixels tall (69 - 64 ± 1 for nasty off-by-one). Normal lemmings are 8-10 pixels high, therefore (69 pixels are correctly deadly) would mean that the lemming starts falling with its entire head in the ceiling.

I think the core question here is not if 69 air pixels between floor and ceiling should already be deadly as that train has already departed long ago, but rather why this inconsisteny triggers.

My bet is on the animation cycle:

Normally situation is that all climbers start on the same floor so no inconsistancy can happen there.

Here the 2 climbers start on different levels --> they are in different states in the animation cycle.

The height gain in the cycle is not constant as the lemming crawls up in little "bursts" -- there are frames in the cycle where he does not gain height.

So the bug only comes to shine when we have a floor change to a level which is exactly splat height + climbers in different anymation cycles (started on different levels). -- This is extremely rare! So I am not surprised it only surfaced now.

--------------------------------------------------------------------------------------------------------

What scratches my head is though is that even if the height gain is not constant all the time the head check of the climber should always trigger the "hit head" scenario at the same time.
At some point the height of the climber head check simply reaches the ceiling point.

The only ways I can think of a difference here:

- Somehow the bobbing back and fourth of the climber head is taken into account! Then the cycle would matter and different cycles can result in an extra pixel of survival.

- At some point the climber gains 2 pixels of height in 1 frame of the cycle. (I do not think this is the case)

Either that or some weird extra check reveals its head.

Otherwise I just imagine a static point inside the climber slowly reaching the critical ceiling point and for that the cycle should not matter if there are no 2 pixel height gains and it should always result in the same fall distance.

One more thought:

Maybe at some point the advancement of the animation cycle comes before the check so that the climber gains an extra pixel. Basically the order of checks is being mixed up.


A fix for this most likely calls for a RC version to assess impact as I can imagine this could have some serious consequences for levels/replays due to the basic hitting head situation is quite common.
Even 2 climbers in different cycle states is much more common now due to the existence of jumpers!

So I would advice for a deeper assessment of the impact of the fix here just to be on the safe side.

I slightly modified a contest guideline (no panic this won't negatively affect anybody ). It was more of an afterthought:

Pre contest testing: You can choose 1-2 persons who do a bit of pre-testing for you, so that the biggest backroutes and screw-ups of your levels can be detected before the playing phase. I cannot control this so it's only a guideline, but still I would prefer not everyone knows every level before the playing phase starts.

I have thought about a few scenarios where you might want to involve a second person and I don't want to be very strict here as again it is more of a guideline than a rule:

- Your initial tester becomes quite busy and cannot test in time.
- Your initial tester does not respond anymore.
- Your initial tester cannot solve the level and you might want to contact an additional person.
- You want to have different entries be tested by different people.

As my only concern with pre-contest testing is that everybody should not know every level before the contest starts I think it should still be fine overall.