2014-04-04 released

[Simon]

Here's the preview of bugfixes for the next version:

    Chat between lobby and game isn't erased
    Transmit directional force over network
    Jumping through platformer bridge from below
    Reimburse too many builders
    Don't display hotkeys on esoteric skills
    Editor jumbles grid alignment on dragging selection
    Cancelling digger by assigning miner/blocker during mid-stroke
    Remove the anti-blocker field
    Bracketed checkmark doesn't vanish

Information about unclear summaries is in the Lix bug tracker on my site.

-- Simon

[RubiX]

Very nice to see 

[NaOH]

Yep, these are basically all the bugs I've ever noticed, other than alt-tab.

[ccexplore]

This feature may have been around long before the 4/4 release, but I'm not a fan of having the hotkey text displayed (overtaking the usual display of time, number of lemmings, etc.) when mouse is over one of the non-skill buttons.  Would like an option to turn off that text.  A better default may be have that text only display for a second or two, and then go back to normal display until the mouse have left the current button to some other one.  But I understand it's kinda a bit of work to do all that (and even then I'd rather not have the text at all anyway), so just an option to turn it off altogether would be fine.

I understand that the workaround is using hotkeys instead of mouse and maybe that's part of why those hotkey texts are so in-your-face, but that's not good enough an argument for me.  As a primarily singleplayer-mode player, the case I'm frequently running into where the hotkey text is actively being a jerk is using the fast-forward and pause buttons.  Using the mouse to invoke those buttons shouldn't penalize me from not being able to see the far more pertinent information like number of lemmings in the level, or force me to have to move the mouse cursor away from the buttons just to see those information (and then have to move the mouse back onto the buttons when I want to unpause or un-FF).

[geoo]

Yeah, me, Proxima and mobius have complained about that too in the past. Right now there's an option in the menu that turns off these hints, but it also turns off the hotkey display for the 12 skills. Even worse, right now there's a bug so that the game doesn't remember that you want them turned off upon quitting, so you'd have to do this at the beginning of each playing session. I suppose the latter bug will likely be fixed by the next release.

Needs discussion how to solve the main issue at hand.
I simply suggested separating the option for skill hotkey display from hint text display.
Though maybe there could be yet another option for hotkey display for the non-skill buttons, or just one single option that pertains to both skill and non-skill hotkeys.

[ccexplore]

Quick update:  I found the option (it was actually a few days ago) but it wasn't exactly intuitive to find either, it is under "graphics" which I thought was only stuff like screen resolution and fullscreen/window.  I think I first tried looking in "hotkeys" and "general".

Separating the option makes sense to me.  The skill hotkey display works since it's never blocking you from viewing other information, unlike the hint text display.  Both may serve effectively the same purpose but they look different enough that people may not realize one setting controls both.  I can understand a desire for consistency so that by default we can automatically teach the user about hotkey assignments for all the buttons, but in practice this has proven more trouble than it's worth I think, and the skill hotkey display is arguably the more important of the two anyhow.  (Though I'd say pause button also deserves a skill hotkey display and can readily accommodate one.)

========

I heard "burner" being mentioned multiple times in recent IRC, what is that?  A new hazard object?

[geoo]

Lix can be in other states than in the process of performing one of the 15 main skills. E.g. they can exit the level though the goal (exiter), burn in a sawblade (burner), shrug after done building (shrugger), fall on their nose (stunner)... Lix is coded in such a way that all of these are actually assignable skills that you can put in the skill panel by editing the level file manually.

[ccexplore]

Hmm, so you mean someone came up with a level (or backroute) that actually requires intentionally "burning" a lemming?   That is indeed a little surprising.

How are such skills displayed in the panel?  Or maybe you can just share out the level and/or solution in question.

[geoo]

Some of those esoteric skills have an image in the skill panel, like the burner, but for most of them it is blank. You can see data/images/lix.I.png for the preview images of each skill.

The level in question is attached. It's solvable without the burner.

Mod Edit: Restored attachments.

[ccexplore]

My solution/backroute(?) attached.  Nice level, is it for inclusion in community set?

And even though it's left unused, I do get the idea now of a burner, you can use it for example to do skill-interruption moves without any unwanted side effect (besides the death of the lemming) from the skill assignment.

Mod Edit: Restored attachments.

[ccexplore]

I might have whine about this before, and this is admittedly a lower-priority quibble, but I'm recently reminded of this again:

Cuber is the only skill in the game where the graphics don't make it clear which terrain pixels get modified throughout the motions of the skill.  Compare to other skills:

- Skills like builders, platformers and exploders add/subtract terrain pixels all at once, so the final result you see is exactly what you get.
- Skills like bashers, miners and diggers take multiple frames to remove terrain pixels.  In theory (ie. ignoring the graphics of the Lix itself somewhat obscuring what you see), at all times during the motion, which pixels you see gone are exactly the ones that are removed during that frame.  Moreover, because those skills are interruptible, you can alternatively do that to learn exactly which pixels get removed when, eliminating the issue with the Lix obscuring what you see.

In comparison, even watching in zzz motion, I'm not convinced at all that I can confidently discern which pixels are added when during the motions of a cuber.  Perhaps you can say in that case, the animation graphics is too effectively obscuring the actual changes of the terrain, certainly more so than the case with bashers/miners/diggers.  At least to my eyes, it feels like throughout the animation (except the final frame of course) there are more yellow pixels displayed than are actually terrain--it looks like that to me while watching in zzz mode another Lix ascending up an in-progress cube for example.  Moreover the cuber is not interruptible, so you can't do that either to learn exactly how terrain pixels are added.

Is what I'm seeing correct, or is there some sort of optical illusion at play?  If former, then seems like it should be possible to remedy by slightly highlighting the pixels (or equivalently, dimming the other pixels) within each animation frame of the cuber that corresponds to added terrain pixels during the frame.  This should make it more possible to observe the exact terrain changes in zzz mode, hopefully without affecting the graphical quality of the animation by much.  That also seems like a simpler change than redoing the graphics to actually make it more accurately reflect the terrain pixels being added in each frame.

I suppose failing all that, I can also settle with guideline pieces depicting all the intermediate cubing stages.  Of course I have no means of actually making such pieces right now other than reading the actual source code to find out which pixels they are.

[geoo]

In all frames except for the final frame, we have int height = 2*l.get_frame()-2. Here 5 is the final frame (containing the full block), see data/images/lix.I.png for the actual frames. In a table linking frame number and height it should look like this:

0	0
1	0
2	2
3	4
4	6
5	16

In the animation, the cube grows diagonally so obviously it doesn't correspond to what's really happening. Mostly I just drew it like that so it looks decent and somewhat smooth. The issue with your suggestion of dimming/highlighting the respective pixels is that the lix animations are paletted (so they can be recoloured for multiplayer), and there are only three shades of yellow. Though you're welcome to draw a replacement animation the conveys more closely what happens (e.g. cube growing from inside to outside shaped like a hill, with the parts of the cube at the left and right border having the same height as the terrain that is created internally. You could e.g. use the next animation from data/images/lix.I.png as template and overlay the cube in some fashion to get the individual frames.

[ccexplore]

Thanks for the information.  It's nice to know that the terrain changes are far simpler than the animation would suggest.

I think for now I'd just look at maybe creating guideline pieces to depict the in-between states, now that I know how simple they actually are.  If I feel particular ambitious I might try updating the animation graphics some day.

[ccexplore]

I've seen multiple recent mentions on IRC of "digger can be cancelled with miner due to its pixel removing pattern" issue.  But I don't understand why it's made out to be so hard to fix somehow (at least it sounds like that on IRC, maybe I'm just reading too much into things?).

I've attached a replay (level contained) which I believe illustrates the problem(s) at hand and my suggested solution, which is simply to tweak the pixel removing pattern by 1 pixel (sorry, 2x2 hi-res pixels more accurately, but you know what I mean).  It's best to view the replay zoomed in.  The left entrance illustrates the problem.  The right entrance, the reddish square block is replaced by steel so that one of the key pixels do not get removed by the digger.  The result is that the miner can continue on mining at the right entrance (ie. issue fixed), unlike the left entrance (original issue, if I understand correctly).  I jumped the diggers merely to allow the removed terrain pixels to be more easily viewable, obviously (or just verify within the level) the results are the same if you assign the miner directly to the digger on that specific frame.  You can compare side-by-side and see that with the steel, all I really did is to kept a single 2x2 hi-res pixel-block from getting removed by the digger, and that tweak is enough to allow the miner to not stop.

There is also a second problem which is illustrated at a later point in the replay.  When the digger has removed exactly half the full-width worth of terrain, assigning most skills (not just miners, but also blocker, batter, and maybe a few more I forgot) will immediately trigger a fall and revert to walker.  This doesn't happen if the assignment is made one frame after instead.  So I think what must be happening is that the lix should be positioned one pixel (ie. 2 hi-res pixels I guess) lower already at halfway, rather than doing so on the frame after like it is now.

Is that all, or are there some other aspects to this problem that I'm not seeing or understanding?

Mod Edit: Restored attachments.

[Simon]

The second problem (assignment in the exact halfway frame) is fixed in my local code and on github, but I haven't released since, because the first problem remains.

I will look into the replay, thanks! Maybe a small sprite amendment is enough instead of a full redraw to match a different digging pattern.

-- Simon