Multiple skill assignments per frame

[namida]

Alright, this has been discussed before, and I don't remember a clear final answer so let's bring it up again.

I'd like to decide on a final answer now, as some code I'm working on at the moment needs the decision to be made in order to write it optimally.


Currently, NL has a restriction of only allowing a single skill assignment to a lemming per frame. It has in some cases been possible to have more than one assignment via glitches in the past, but never as an intentional legal move. On the other hand, I believe it's considered perfectly valid in Lix.

What are your thoughts on this - should NL continue to enforce a one assignment per frame restriction, or should that be lifted and unlimited assignments in the same frame be allowed?

[Minim]

I see what you mean when you encounter a level that looks like the one in the attachment below: A level that you can solve but is impossible to execute under the current mechanics.

However, it's extremely rare to find a level that cannot be solved without assigning skills to multiple lemmings in the same frame. I think it's better to leave as is until we happen to find a few levels that involve this particular problem.

[IchoTolot]

I think we need to discover the consequences of a change first.

Currently, I have no problem with the current system and as Minim said tt's EXTREMELY rare that this will hinder your progress in a big way. Also this prevents a total skill overload with assigning 100 skills or so in a single frame

[Gronkling]

I think multiple skill assignments would be interesting, I like the idea personally.

[bulletride]

What would happen if you assigned 2 skills to the same lemming on the same frame?

[Proxima]

I see what you mean when you encounter a level that looks like the one in the attachment below: A level that you can solve but is impossible to execute under the current mechanics.

Let's not forget, if there is a level that's only possible to solve with multiple assignments in one frame, the only way to actually do this is using NeoLemmix's framestepping features. I feel these are conveniences to make solutions easier to execute -- they lie outside the "solution space", and it's not fair for a level to require them to do something that would be literally impossible without.

Framestepping is really the big issue here. The question is: if you assign a skill, then step back and assign a skill to a different lemming, what do you expect to happen / what would be more convenient to have happen -- for it to override the first assignment or for both to be carried out? I don't have a very strong intuition about this, but I feel the game is a bit cleaner and simpler without multiple assignments. If you go back more than one frame and assign a different skill, it cancels the replay and the first assignment never happens, so it feels consistent if going back exactly one frame does the same thing.

[IchoTolot]

The more I think about this and reading the posts from Proxima and Bulletride, I am more and more against multiple assignment. Currently the system is easy and clear: assign --- one frame passes --- another assign. Step by Step.

With multiple assigns you get problems mentioned in the 2 posts above me and it just gets messier. Why do we need to assign a ton of skills in one frame? A level that needs this is often not very good either

[Simon]

Yeah, multiple assignment is messy.

Lix has multiple assignments because of the networking model. At click time, I don't know whether my team partner has assigned something.

With multiple assignments, you must handle user input of 20 basher assignments, then 50 builder assignments, then 10 floater assignment to same lem, in same frame. Do you want to let exactly 1 basher and 1 floater assignment go through? Write this extra handling. If you pause the game and don't advance, what should the panel show? After the basher assignment, should the UI prevent the builder assignment, but not the floater assignment?

Builders queue in lix. If we hadn't assigned basher, the 50 builder assignment should all go through.

On assignment user input, what assignments do you remove from the replay for the next frame? If you keep all assignments for the next frame, then you get an irritating variant of LMB advances physics before cancelling replay. If you delete all assignments for the next frame, you can't assign multiple times. If you cache new assignments, and only commit them to the replay when the update happens, you must develop this caching.

The question is: if you assign a skill, then step back and assign a skill to a different lemming, what do you expect to happen / what would be more convenient to have happen -- for it to override the first assignment or for both to be carried out?

At least override when you have framestepped to this frame from the past instead of from the future.

-- Simon

[Nepster]

Framestepping is really the big issue here. The question is: if you assign a skill, then step back and assign a skill to a different lemming, what do you expect to happen / what would be more convenient to have happen -- for it to override the first assignment or for both to be carried out?

I think there are two conflicting use-cases:
A) I have made a skill assignment, but now I want to do the same but one frame later. The ideal workflow for me would be: Framestep to the frame with the current skill assignment, click once on the screen to cancel this assignment and move one frame forward, then assign the skill again.
B) I have forgotten to assign one skill and go back to do so now. Then I usually want to keep all other skill assignments as much as possible, even if I accidentally stop going backwards at a frame that already has a skill assignment.¹⁾

Thus I would prefer the following:
- Allow multiple skill assignments in one frame
- If multiple contradicting assignments are made to a lemming, keep only the most recent one. So in Simon's example, we would assign a builder, not a basher.
- Left-Click on empty space removes all skill assignments on the current frame and moves to the next frame.
- Discourage level creation that relies on multiple skill assignments in one frame: We already discourage frame-precise skill assignments if they are not absolutely necessary for the puzzle idea (and "use multiple skill assignments in one frame" is not a puzzle idea)

¹⁾But perhaps this is part of an even larger problem that needs a completely separate solution: There is currently no way to add a skill assignment while keeping all subsequent skill assignments of a previous attempt.

[namida]

But perhaps this is part of an even larger problem that needs a completely separate solution: There is currently no way to add a skill assignment while keeping all subsequent skill assignments of a previous attempt.

Yeah, this is something that needs addressing too. I'm not sure how to best approach it - perhaps as an interim solution, some kind of "Insert" hotkey, which inserts an action into a replay without removing others. Maybe also some counterpart to remove just part of a replay.

The new replay code might actually make it simpler to implement such things, now that I think about it. For one, it does not rely on the actions being in any specific order (either in memory or in a file), whereas the old code required that in both cases the actions were exactly in the order they occur in-game in.

[Proxima]

I think there are two conflicting use-cases:
A) I have made a skill assignment, but now I want to do the same but one frame later. The ideal workflow for me would be: Framestep to the frame with the current skill assignment, click once on the screen to cancel this assignment and move one frame forward, then assign the skill again.
B) I have forgotten to assign one skill and go back to do so now. Then I usually want to keep all other skill assignments as much as possible, even if I accidentally stop going backwards at a frame that already has a skill assignment.

It seems to me that more common than either is the following:

C) I realise my solution will not work and rewind and try something different. In this case I would prefer that assigning a skill completely cancels all skills in the replay from that point onwards. Let's say I want to keep all skill assignments at times A to B and reject all at times C to D, by making a new assignment between B and C. I jump back in time to before C, and see that no skills from C onwards have been carried out. However, it isn't visible whether I have happened to land on the very last frame before C. If I now assign a new skill and the first assignment at time C also gets carried out, I will have to spend more time framestepping backwards and redoing assignments.

[Dullstar]

On a related note I've noticed in the past is that it appears to completely cancel out a skill assignment (say you had the wrong skill selected) I've had to go back at least two frames.  I have no idea why that happens (or if it's even still true as of the most recent experimental version) but it's not the behavior I expect. I know for certain this happens in 1.43n-B.
To replicate:
        1) Pause the game.
        2) Assign a skill. The game will advance one frame.
        3) Go back one frame, try to assign a different skill. The skill being replayed takes priority over the new skill.

If you want to actually override the original assignment, you have to framestep backwards twice in step 3 instead of once. It seems that, for some reason, a skill assignment in the replay is prioritized over a new assignment from the player in the event of a conflict.

Here are my thoughts:
If multiple assignments on the same frame are allowed:
        If two skills are assigned to the same lemming on the same frame (i.e. one in the replay and another from the player), the player's most recent skill assignment is prioritized over the one in the replay.

If multiple assignments on the same frame are NOT allowed:
        If the player attempts to assign a skill on the same frame that a skill is assigned in the replay, the player's skill assignment takes priority over the one in the replay.

As far as allowing multiple assignments, I'm leaning towards yes but I'm not certain.

[namida]

This is a seperate, well-established issue that's on the todo list to fix.

[namida]

Okay so, looking back at this discussion, it seems we do indeed want "max one assignment per frame".

So my next question - should nuking count as an assignment, or is it seperate altogether? I can see valid reasons for both. "Count it as a skill" because it makes lemmings do stuff. "Don't count it as a skill" because you aren't directly taking a skill and assigning it to one lemming.

I believe current code does allow it; but this is not as the result of any intentional decision to do so; rather, there simply isn't anything preventing it.

[Dullstar]

Okay so, looking back at this discussion, it seems we do indeed want "max one assignment per frame".

So my next question - should nuking count as an assignment, or is it seperate altogether? I can see valid reasons for both. "Count it as a skill" because it makes lemmings do stuff. "Don't count it as a skill" because you aren't directly taking a skill and assigning it to one lemming.

I believe current code does allow it; but this is not as the result of any intentional decision to do so; rather, there simply isn't anything preventing it.

Are there any situations in which this would make a difference (excluding replay compatibility, since I don't think "it would break some replays" is a good enough justification not to do something)? I'd lean towards just keeping whatever the current behavior is if there isn't.

That said, if you're looking for consistency, then counting it as an assignment would be the way to go.