Many Lix users probably also use NL, so its behavior and defaults may be a good starting point since presumably users will expect it to behave similarly. That said, we also shouldn't chain ourselves to that: if we think we can do better, we should go for it.
I think if you want to default to on, it's *extremely* important to have an easy way to cancel the replay, and I'm not sure clicking the air is the best solution here, as it seems like a very easy misclick. I think a hotkey would be better: still possible to mispress, but I would suspect it to be less likely than accidentally clicking the air next to a Lix.
I also think that there's some promise to cutting some assignments, though I think we can do better. Replay insert mode as implemented in NL is very prone to causing assignment desyncs, as NL has no way to detect that this happened. In many cases when you're using replay insert mode, the assignments are independent enough that they don't interfere, but if there is any amount of interaction between the inserted assignment and lemmings queued to perform assignments in the future, then while sometimes it'll still work out by chance, most of the time those future assignments just become nonsense. I think a simple solution to this in Lix would be to design it such that the replay additionally stores the position and direction of the Lix: if the Lix is not where we expect it to be when it's time to make the assignment, the assignment has become desynced, and should be cut. I think this generalizes better than simply cutting all future assignments to a particular Lix: some might cause few if any problems (e.g. assigning a climber or floater to a Lix that is busy doing multiple queued tasks with no climbing/floating in between), while others (anything that alters the terrain, really) can easily affect the queued assignments of other Lix.
We could easily be consistent and just cut any desynced assignment and I wouldn't expect it to cause any problems but there may be a few cases that could be convenient to the user to fudge a little:
- What if the Lix is within a certain, potentially configurable margin of error from its intended assignment location, e.g. only one or two pixels off and still facing the correct direction?
- What if the Lix originally queued to perform the skill is in the wrong position, but there is a different Lix in that location that the assignment could be reasssigned to?
- If we allow automatic reassignments, should permanent skill loadouts be considered, e.g. should we assign a floater to a walker if the floater was originally assigned to a climber? What if we were assigning a builder instead of a floater?
IIRC, the replay system is also closely related to the networking code, specifically, distributing assignments to other players, so this may also help detect desyncs (which I don't think would generally come up except maaaaaaybe with some latency edge cases that ultimately end up getting resolved successfully, but there have been desync bugs in the past, e.g. when there was a hatch assignment bug, though I'm not sure if any of them survived long enough to actually affect a planned multiplayer session). Of course, this doesn't help FIX the desync but it could be helpful diagnostic information (and possibly maybe for automated testing?).