Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Simon

Pages: [1] 2 3 ... 16
Lix Main / Basher Walks into Terrain
« on: February 06, 2023, 06:00:41 AM »
A basher oddity found by Icho during multiplayer in Lix 0.10.5. Thanks! Here's a reduced example level.

Rule 1: Bashers walk forward during some frames in their cycle. This forward movement is allowed to enter terrain, i.e., the basher's foot is allowed to move into and through terrain.

Reasoning behind rule 1: Either the basher's swing removed all terrain here, therefore we won't walk into earth anyway. Or the basher hit steel, immediately stopped bashing, and won't walk forward.

Rule 2: During the walk forward, bashers lower themselves into holes. Bashers never gain height.

Reasoning behind rule 2: We removed all terrain onto which we might step upwards, or cancelled on steel in the way. Either way, there is no need for the basher to ever rise. But the basher may try to walk over holes, and the basher should certainly fall into such holes if they're deep enough. If the holes are shallow, it's okay for the basher to continue; shallow holes shouldn't break mental pathfinding.

As a result of rules 1 and 2 combined, the attached level Basher Walks into Terrain is solvable (saves 1 of 2, using 1 cuber, 1 basher, and a few jumpers to position the cuber and basher). The thin white line is steel.

The most noticeable effect here is that we can clip through a particular arrangement of steel.

The second effect is that a basher falls through an arrangement through which a following crowd would not fall. The non-falling crowd alerted Icho in the first place.

I don't have a good solution.
-- Simon

NL 12.12.5

The land are the physics pixels, i.e., the pixels where Lemmings physics apply. Zooming into the map will draw the land bigger, and we will see less of the land.

The canvas is the bitmap where we paint the land, then paint the lemmings, then paint the mouse cursor, ..., and finally paint the entire bitmap to the screen. After zooming in, we'll draw a land pixel as a square across several canvas pixels. The mouse position on the canvas stays the same throughout zooming in, that is good.

The mouse position on land will ideally remain the same before and after zooming in. When we're in small zoom levels and the land doesn't fill all of the canvas, preserving mouse-on-land won't always be possible. NL wants to fill the canvas with as much land as possible, and that's good.

The bug is now:
  • Zoom in until the land fills all of the canvas. Don't zoom in further yet, i.e., keep available at least one deeper zoom level for later.
  • Scroll to a position at but not directly touching, the boundary of the land. As a result, one edge of the canvas will show pixels from near, but not at, the edge of the land.
  • Look at where the mouse points on the land.
  • Zoom in.
  • Look again at where the mouse points on the land. Now, it's a different pixel than where the mouse pointed on the land during step 3, before you zoomed in during step 4.
Expected instead: In step 5, mouse-on-land agrees with step 3's mouse-on-land.

Surprisingly, the bug doesn't happen when you're near the center of the map. There, NL computes and preserves mouse-on-land correctly when zooming in.

I haven't tested zooming out. That should ideally use the same code to preserve mouse-on-land, and fixing the bug for zooming in should ideally also apply to zooming out.

-- Simon

NL 12.5.5.

Have a lemming near the top of the level, almost at the ceiling. Have space in front of the lemming. Select jumper in the panel. Hover over the lemming.

Game draws an arc that goes out of bounds (where nothing is drawn, and this is correct), then returns downwards from the ceiling. But if we assign jumper, the jumper does not follow this arc. Instead, the jumper dies beyond the ceiling and never returns. The arc and the path do not match even though there is no interaction with other lemmings.

Expected: The arc comes back from the ceiling if and only if the jumper survives.

-- Simon


In 2022, naymapl and cameo69 reported:
github #431: Magic pink won't become transparent on macOS (both Intel and ARM64)
I'd like to debug this, but I don't have a Mac. Thus:

Who has a Mac? Would you like to compile and run Lix on it, and are you up for some testing?

I'll walk you through everything. I'll answer all of your questions. No need to hurry: It's okay if you can spare a few hours here and there. It's okay if you take several days off before you can test a new theory that I'll get.

Let's see if the bug still manifests in 2023. Since naymapl's and cameo69's reportings, has been at least one new release of Allegro 5, Lix's graphics library, and it's possible that the bug is already gone. And if the bug reproduces on your Mac, I'll create some minimal example programs for you to try, to see if the bug is in Lix or in Allegro 5.

-- Simon


This arose from Lix's Replay Insert Mode discussion. Independently, I discussed the NeoLemmix behavior shortly on my twitch livestream a week ago.

nin10doadict describes the problem well:

Consider the example:
Phyu 59: Lem 5 gets a basher.
Phyu 60: Lem 6 gets a builder.

If you go back and insert at phyu 59: Lem 6 gets a builder, then depending on whether we're using Lix or Neolemmix we get different behaviors.

In NeoLemmix the previous assignment to Lem 5 at frame 59 is silently overwritten and won't happen anymore. Could have disastrous effects on the rest of the replay; now any other assignments that were dependent on that one will be in unhelpful locations or fail for one reason or another. I find myself manually shuffling through the frames when using replay-insert to ensure I don't accidentally overwrite something, which seems annoying.

NeoLemmix's insert mode ("blue R") is reasonably hard to access: You'll have to map a hotkey to it, remember the hotkey, and conciously decide to use this mode. Thus, the problem won't hit everybody.

But if you use it, sooner or later, you'll accidentally assign on a same frame and thus ditch a seemingly-random assignment from the middle of your replay. It's a small data loss bug. Granted, it's softened by the ease of recreating the overwritten replay. But it's insidious because you won't notice right away that you overwrote an assignment.

Solution ideas:

Should the player have to manage this?

Can the game notify the player that an overwrite has occurred with a sound or visual cue?

Should the game prevent the overwrite altogether? If so, can the player force the overwrite anyway with repeated attempts?

I think that the accidental overwrites should be hard or impossible. A dumb, but robust and easy way is: Flat-out disallow the new assignment and keep the old. If we want to be cheap, then give no feedback besides the obvious failure to insert.

namida, how much energy would you want to invest here? I'd happily chew through some UI suggestions if others pipe up here, and maybe I'll have more insights on my own, too.

-- Simon

Lix Main / Tweaker with small skill icons
« on: January 18, 2023, 10:38:59 PM »

I've attached an image of how the tweaker will look in Lix 0.10.5.

(Introduction: The Lix tweaker is similar to the replay editor of NeoLemmix. It's an optional feature, you never have to use it. You can tweak your skill assignments here: Shift single assignments forward/backward in time. For your smaller mistakes, such tweaking can be faster than going back in time and re-record a part of your solution. To access the tweaker, click the filmstrip icon in Lix's skill planel.)

The tweaker will show small skill icons in 0.10.5. There are two versions of each icon, one for a left-forced assignment and one for a right-forced assignment. Unforced assignments use the right-facing skill icon by default.

There is a second image attached with all the small skill icons. The two rows are identical.

It's even conceivable to write all assignments whatsoever like a forced assignment into the replay. Then your directional-force keys will merely be for filtering correct-facing lix while you hover over lix, not for the decision of whether you generate a forcing assignment or an unforced one.

Lix 0.10.4 wrote the first three letters of the skill, e.g., Bui or Jum. That made the tweaker look like a software debugger. :8:()[: And I had to put a little arrow next to the three letters to show left/right-forcing assignments.

-- Simon

Lix Main / Replay Insert Mode for Lix (like NeoLemmix's "blue R")
« on: December 28, 2022, 04:03:15 PM »

this thread assumes that you've kept checked the option Keep replay after ◀▮ at all times. If you uncheck it permanently or temporarily, also look at topic: Rewind as Undo: Still Preserve a Loaded Replay.

Quote from: That thread
Rewind is browsing. You keep "Keep Replay After ◀▮" checked at all times. This is the default. You treat the replay functionality like a book, and use framestepping to browse through this book. Only when you're really sure, you cut content by clicking air or by assigning. You accept that Lix occasionally surprises you with unwanted assignments when you forget to cut the replay.

Let's try to improve this style even more. The behavior of Lix 0.10.3 is:
  • While you're viewing a replay (a loaded one, or your current attempt after rewinding), Lix will assign by itself the remaining future assignments from that replay.
  • Click air (really, click anywhere in the game map where no lix is) to cut the replay. Cutting discards all future assignments from the replay. Because you're now at the end of the replay, the floating R disappears.
  • Or assign to a lix. This first cuts the replay as if you clicked air, then adds your now assignment to the replay. It also advances physics once, therefore the assignment is already in the past. Again, you're now at the end of the replay, and the floating R disappears.
  • The tweaker (filmstrip icon) allows you to discard assignments (past or future), or to move assignments by single physics updates. Tweaking preserves the remaining future assignments, and this is deliberate -- it's really a tool to edit history and see what future results from that single change only. To discard all future assignments, click air as usual, or discard all future assignments manually in the tweaker.
Design hole: In Lix 0.10.3, there is no way to insert new assignments into the replay without cutting the replay.

I'd like to offer replay insert mode. Let's design it. Insert might become a user option (that you toggle from the options menu only, and never during play), it might become a mode during play, or it might even become a default.

In my recent livestream, I've experimented with a hacked Lix version that inserted all assignments instead of cutting the replay before appending the assignment. This was very useful when many lix had to work together in a tough singleplayer puzzle. But it was annoying on ccx's 100% Built By Lixes: Here, many builder assignments go to a single lix, and each assignment desynchs future assignments to that lix. I got surprised and annoyed from Lix constantly replaying future assignments because I failed to cut them. As a result, I'm considering:

Idea (*): Click air to cut all future. Assign to discard only that lix's future.

In phyu 100, lix #0 builds.
In phyu 200, lix #1 mines.
   Phyu 300 is now.
In phyu 400, lix #0 digs.
In phyu 500, lix #1 climbs.
In phyu 600, we nuke.

 (Phyu means physics update, a.k.a. physics frame.)

In Lix 0.10.3, when you click air here, Lix cuts the two future assignments and the nuke. Likewise, when you assign to either lix #0, lix #1, or an entirely different lix, Lix cuts the two future assignments and the nuke, then inserts your new assignment for phyu 301. Even with idea (*), when we click air here, Lix cuts the two future assignments and the nuke.

The difference of idea (*) is when we assign. If we assign to lix #0, we discard the assignment in phyu 400 and the nuke, then add an assignment to lix #0 at phyu 301. If, instead, we assign to lix #1, we discard the assignment in phyu 500 and the nuke, then add an assignment to lix #1 at pyhu 301. If, instead, we assign to lix #29, we discard only the nuke.

Is (*) sensible? Or do you see a different way to improve Lix in this direction?

Should we offer (*) as an option, in addition to offering how 0.10.3 always cuts all future actions on assignment? Should it be a user option in the options menu, or should it be a button during play? Either way, should (*) be the default or should 0.10.3's cutting be the default?

-- Simon

Lix Main / Rewind as Undo: Still Preserve a Loaded Replay
« on: December 26, 2022, 05:29:07 AM »

Lix has a single binary option for how Lix's replay rewinding works: Keep replay after ◀▮. In the options menu, if you hover over this option, you'll see this description: "On framestepping back (◀▮), keep future replay actions until you click air. If not checked, replay actions are removed when you undo them by framestepping."

There are at least two styles of play here:
  • Rewind is browsing. You keep "Keep Replay After ◀▮" checked at all times. This is the default. You treat the replay functionality like a book, and use framestepping to browse through this book. Only when you're really sure, you cut content by clicking air or by assigning. You accept that Lix occasionally surprises you with unwanted assignments when you forget to cut the replay.
  • Rewind is undo. You've unchecked "Keep Replay After ◀▮", never re-check it, and treat rewinding as undo. Lix won't ever magically assign anything by itself when you continue after rewinding. You won't ever be surprised. At any time, what you see is exactly what's in the replay. Unless you've loaded a saved replay, you won't ever be replaying during your attempt. You like this consistency, and you accept extra work from re-assigning.
  • Undo your play, but browse replays. During your own play, you uncheck "Keep Replay After ◀▮", but you check it before watching saved replays. This offers the best of both worlds: You won't get surprived by maverick assignments after rewinding, and you can still browse existing replays backwards and forwards without dropping their content explicitly. To continue playing from a loaded replay, you click air.
Most players appear to prefer style 1. mobius prefers style 2, or possibly style 3. Forestidia prefers style 3. From a user-experience standpoint, I glean:

Support undo play, browse replay: Allowing style 2 (Rewind is always undo) as an option is really a misdesign, and it should have been style 3 all along (undo your play, browse replays). If Lix has a single binary option for these playstyles, it should be an option to toggle between styles 1 and 3.
  • The current option toggles between 1 and 2. I'm considering to change it so that it toggles between 1 and 3.
  • When you choose this (undo your play, but browse loaded replays), Lix won't cut anything from the loaded replay when you framestep back. When you play yourself, Lix will discard all rewound actions from the replay immediately.
  • You can still interrupt a loaded replay by clicking air. You can continue your own attempt at the level from there. New: From this point on, Lix will discard rewound actions from the replay. This is new and exciting because in existing Lix, when you use style 2 or style 3, even style 3 doesn't offer you this sudden switching into rewind-is-undo.
This looks to me like a much improved merge of the styles 2 and 3.

Would anybody be annoyed over losing style 2 in favor of this?

mobius: How do you feel about this proposed change? Undo your play, but browse loaded replays. When you click air during a loaded replay, Lix shall switch from rewind-is-browse to rewind-is-undo.

We can also improve style 1 (rewind is browsing), or possibly we can split it into several styles and support them all, by turning the single binary option into something multi-way. But that's meaty discussion for a separate next topic: Replay Insert Mode for Lix. :lix-grin:

-- Simon


while I composed today's main issue about about negatively-worded binary options, I thought about how namida and Nepster worded those options in the config file. Then I stumbled onto this bug on the side:

NeoLemmix 12.12.5.

The user options file settings/settings.ini does not persist the option "Don't Replay After Backwards Frameskips". If you check that option during your session, it will be forgotten after the end. settings/settings.ini contains no line for that option. When you run NL for the next time, the checkmark will be gone. During play, then, NL will replay your actions after you've rewound them.

Expected instead: NL writes that option to settings/settings.ini. NL restores this on next session.

(Other options save properly to settings/settings.ini and restore properly.)

Who needs the option to ditch actions from the replay on rewind? I haven't seen anybody ranting about this bug before. It looks like I'm the first to run into it, and I only ran into it during the naming research, not because I wanted to toggle that option. Lix offers a similar option ("Keep replay after rewind") and Forestidia and mobius prefer in Lix the rewind to be an undo. Forestidia feels strongly about this in Lix. Thus, it feels like it makes sense to keep the option. But stay tuned over Christmas for the popcorn on insert-into-replay in Lix. :lix-evil:

-- Simon


NeoLemmix player version 12.12.5. Here is a screenshot from the interface options. You reach these options from NL's main menu, click the gear icon, then click the interface tab at top of dialog.

I recommend the following rewordings:

Don't Replay After Backwards Frameskip -> Replay after Rewind or Preserve Replay after Rewind. Invert the meaning of the checkmark. Maybe "Keep" instead of "Preserve". Another wording: Cut Replay after Rewind and keep the meaning of the checkmark, but I feel this isn't as clear. I'm not 100 % sure if "rewind" is clear enough if the program calls it "backwards frameskip" elsewhere, but "rewind" is at least popular and short.

Disable Background Images -> Show backgrounds and invert the meaning of the checkmark. Maybe "display" instead of "show"?

Hide Skill Shadows -> Skill Shadows and invert the meaning of the checkmark. A verb doesn't feel as necessary as with "show backgrounds" because the skill shadows feel exactly in the middle between a tool and a graphics option.

Use Spawn Interval -> Show Spawn Interval Instead of Release Rate and keep the meanig of the checkmark as it is now. Or "Spawn rate" if NL prefers that term. I don't have a good short wording. The setting is really only for visuals and has no bearing on physics. Even better: Convert the box into a radio-button option. Reason: It's a choice between two meaningful different things, not a togging of a single thing.

Hide Advanced Options in Level Select -> Show Advanced Options in Level Select and invert the meaning of the checkmark.

This report is more about the UI than about what really ends in the config files. You can remove negative wording in the config files, too, and invert the setting under the hood, or you can merely invert the meaning of the checkbox.

-- Simon

Lix Levels / Simon streamed lemforum/Hopeless, 2023-01-22
« on: December 21, 2022, 05:56:52 PM »
Recording will remain for 14 days at:

-- Simon

Lix Levels / Rumble to the Bottom, 2nd Intended Route
« on: December 11, 2022, 02:26:37 AM »
Hi Proxima,

while streaming lemforum on twitch, Ramond found this backroute 2nd intended route in Rumble to the Bottom.

Spoiler (click to show/hide)

Idea how to change (click to show/hide)

-- Simon

Lix Main / Proxima lays down lemforum maintainership
« on: December 09, 2022, 03:26:25 AM »

Proxima has laid down maintainership of Lix's lemforum level pack.

As long as we don't have a designated maintainer, we'll still work together on the levels, but nobody's word trumps others. I'll glean from the discussions what might be best, and implement that in Lix. Everybody, please speak up if I make odd decisions, and I'll happily do something else in the next version of Lix. Also, if you know lemforum well, you can step up to be maintainer and call the shots!

Lix lemforum is the flagship pack. One possibility is to stabilize lemforum, which means that we'll mostly fix backroutes, but avoid larger level swaps. This is best for speedruns, and it preserves the spirit of the contributions. If Lix gets fancy new features or new levels, we can put those separately from lemforum.

The alternative is to keep cutting weaker levels every now and then, and let lemforum slowly adapt to Lix when Lix gets new features like neutral lix, or new tilesets. This allows us to recommend lemforum to new players as a sample of the state of the art, and still have the vast majority of the content from 2010 to 2012, although not necessarily all of it.

You can mix the two ways to a degree, but they're fundamentally incompatible. I'd like to recommend to new players at least some cross-section of Lix's features and level designers' work. Proxima prefers a stable lemforum that we still recommend to new players as first pack, as we've always envisioned.

It's an amicable parting. I'm sure geoo's and Proxima's handwriting will stay visible on lemforum. Thanks for your contributions! Proxima, you're busy in life, about to get a foot into the door of the software industry. And in Deadly Rooms of Death, you've got a big project on the brink of release. I wish you the best of luck with both projects!

And barge in if we ever screw it up. :lix-grin:

-- Simon

Lix Levels / Ramond streams lemforum, 2022-12
« on: December 08, 2022, 07:53:16 PM »
Ramond's list of episodes down here in this thread.

All video are preserved for 14 days on his main stream page:

-- Simon

Lix Main / UI feedback from darkshoxx's Lix stream, 2022-11-26
« on: December 05, 2022, 03:18:38 AM »

darkshoxx joind our recent Lix session on Saturday, November 26th. I streamed the session to twitch, and darkshoxx also streamed the session to twitch. To familiarize himself with Lix, darkshoxx played Lix singleplayer for an hour before the multiplayer session.

darkshoxx's Lix stream from 2022-11-26
(twitch will delete this on Dec ~10th)

Thanks for the stream! Here's my feedback:

Button caption: darkshoxx played the first level Any Way You Want and reached the end-of-singleplayer screen. The button at the bottom says "Back to the browser". darkshoxx reads the button, and says: "What? It's not a browser. Whatever."

Indeed, the level browser is a level selection first and foremost, and it only happens to be also implemented as a file browser that can browse to every level. I'll recaption the button to "Back to Level Browser" or maybe "Back to Level Selection".

Feedback on winning/losing: darkshoxx played Let's Block and Blow?, which has a save requirement of 19/20. First attempt, he flings several lix to death. Obviously this is wrong, and he resets.

Second attempt, he carefully assigns the exploder to not fling any lix to death. And he succeeds in this goal. This second attempt saves 18/20, it doesn't save the exploder and the blocker. This comes short of the save requirement of 19/20. Since he didn't fling anybody to death, he believes that he's won, nukes the blocker, reaches the end-of-singleplayer screen, and happily moves to the next level.

The end-of-singleplayer screen always presents the next level, even if you've lost. I like this, but it makes winning and loosing look nearly alike on that screen. The only difference are the small numbers at the top left, and the caption "Congratulations! You solved:" vs. "Try again:" over the solved level in the top right. We're all conditioned to not look much at the solved level in the top right.

During play, I'd still like the nuke to exit regardless of winning/losing. I think it would be awkward to pause after nuking a losing attempt.

As annoying as it is to admit: Winning and losing is central to every game, and Lix fails to present it properly. We need better feedback about winning/losing, both during play and during the end-of-singleplayer screen. I have loose ideas, but nothing ready to discuss yet.

This third finding is feedback for darkshoxx, it's not for Lix.

You had us in Mumble. At first, your viewers considered us too quiet. You raised the audio output in Mumble, but that didn't affect the loudness of Mumble in your stream. I think you should lower the Mumble audio output back to 100 %, to reduce the chance of audio clipping.

Then you put gain on the Mumble output. We were pretty loud already then, at least as loud as yourself. Then you put gain on the Mumble output a second time. Now, we were very loud, far louder than yourself. When I spoke, we got audio clipping in your stream. Maybe it's the mix of more than 100 % on the audio output, maybe it was from my side, but it ended loud in the stream.

I think a good amount of gain was how much you put on us the first time, before you raised it for the second time, together with Mumble at 100 %.

Or perhaps even slightly less gain than the first time (but still more than nothing)? Then you're at least as loud as anybody on Mumble, and your viewers want to hear you after all. :thumbsup:

-- Simon

Pages: [1] 2 3 ... 16