Hi,

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:

The bug is:

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

Hi,

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.

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.

Example:
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

Hi,

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.

-- Simon

Now live with geoo's levelpack:
https://www.twitch.tv/simonnaar

-- Simon

Hi,

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.

-- Simon

Hi,

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.

-- Simon

Hi,

everybody is busy near the end of the year, therefore I don't want to plan a big multiplayer session on short notice. Instead, let's meet in Mumble for loose discussion ("campfire" or "fireside chat") this Saturday, December 3rd, starting 17:00 UTC. Who's up?



Ideas for the discussion:

• I'm working on writing handicaps into replays, and playing back multiplayer games from replays with the correct handicap. We can test this together before I'll release 0.10.2.
  
• Level reorderings in our flagship pack, lemforum.
  
• Game modes involving neutral lix. Which good ideas can we copy from NeoLemmix? What should be a level option, what should be a property of the goals/exits? At the September 2022 campfire, I discussed this with geoo, but haven't written anything on the forums about it.
  
• Solving levels together on livestream is fun. I had a great time with Flopsy, mobius, and Ramond this past Sunday. Let's do it more often?
  
• Anything you like. Bring your own topics!
  

If you don't have time, no worries: I'd like to have campfire every couple weeks/months. We don't set in stone any plans for development. Important things should go through the forum in any case, giving everybody a chance to comment on plans.

See you in Mumble!

-- Simon

Hi,

Consider the following two-player map.

This isn't an exact map from Lix, but the rough shape is common enough in two-player Lix: Player A goes from top-left to bottom-right, and player B goes from top-right to bottom-left.



Let's assume:

• You start at the red hatch, and you're planning a route to the red exit.
  
• You have reasonably many builders, platformers, bashers, miners, and diggers.
  
• Both hatches have steel. You can still attack the opponent's hatch, but that won't decide the match at once.
  
• Your route will cross the opponent's route somewhere.
  

What will be the shape of your route?


You can mine straight from the hatch to the exit. This produces a linear path.

The problem is that your opponent can sabotage this path: He can send lone saboteurs to the !-marked area, destroy the terrain, and drown your lix. It's always easier to destroy terrain than to rebuild it, and you'll lose several lix here. You'll have to invest a lot of attention to the defense of this single area.

It would be even worse to dig near your hatch, then bash across near the water. Your crowd would have to pass close by the opponent's exit, that's a risk in itself, and the sabotagable area over the water will be even wider than in the direct straight line.


A better approach is this arc-shaped route. You start to go across horizontally. For even more resilience, you can try to get your crowd on top of the trees.

High routes are strong routes: Your opponent has a harder time getting to you. But you yourself can still get down easily enough. If your opponent bashes through your stairs, you fall back to the grassy surface. Even the grassy surface is still higher and safer than the linear diagonal route from the previous example.

Near the exit, the arc bends downward. You approach the exit in a steep slope -- considerably steeper than a miner's slope. This steep slope is resilient:

• You won't splat anywhere.
  
• When your opponent removes some terrain around you, it's okay.
  
• He can't bat you into oblivion, you're well away from the edge of the map.
  

Don't approach your exit perfectly vertically, that will risk splatting. High arcs are good, but if your arc is too high and stretches too far rightward, you'll risk overshooting the exit, and must turn your lix. Whenever your crowd must turn -- be it at a blocker, at a cuber's cube, or at other diggable terrain -- you're vulnerable to sabotage.

As a bonus, the arc allows good access to the opponent's hatch for your saboteurs, but you don't have to send your entire crowd to his hatch.

Most of our custom maps are more complicated than this example. You'll find steel or hazards in the way of your ideal arc, or the level offers only a reduced skillset. You'll have to be flexible, accept some risks, choose tradeoffs -- and that's what multiplayer Lix is all about.

-- Simon