[SUGGESTION] [PLAYER] [ADDED] Replay messes with skill UI

[Simon]

Status: Reclassified as a suggestion, as - while possibly considered a bad design decision - the current behaviour is intended, so changing it is a suggestion.

Implemented for next update, as an option. Default setting is off.

[Simon]

Bug/suggestion, I don't know. It feels like a blatant bug during play, and I will show why it's a misdesign. In NL land, because someone has implemented it consciously, this is usually not called a bug.

Repro

Play.
Select builder. (Point X in time here, right after the selection of builder.)
Select basher.
Select builder.
Assign builder.
See that the assignment is misplaced.
Go backwards in time to X.
Look at the skillbar, it shows that builder is selected.
Try to assign builder at the correct place now.
Enjoy your basher assignment.

Expected instead: Builder assignment instead of basher assignment.

Reasoning

Selected skills are a state of the user interface.

When replaying, I concentrate on the physics. That's what replay is for. I don't concentrate both on physics and my past skill changes in the UI. The forced skill selection of basher comes as a complete surprise.

With or without the skill change, the lemmings will do the exact same thing on the screen for now. Tracking skill changes in the replay couples tightly the UI to the physics. Let's prefer loose coupling wherever possible -- one depends on the other, but not the other way around.

Pausing for n seconds isn't replayed, because it's pure UI.

Changing highlit lemming isn't replayed, because it's pure UI.

Changing the skill should not be replayed, because it's pure UI.

-- Simon

[IchoTolot]

I agree with this one. Quite regulary I find myself in the situation to re-adjust skill X, just to assign Skill Y by accident, because the replay selected another skill.

Could be a bit difficult to get the "select+assign-skill" behavior out of the replay format for just a simple "assign-skill" instead. Maybe the change (if it will be made) will just be there in the "after-fix" replays and not also in the "pre-fix" replays, because the old behavior is still written in there.

[namida]

If the suggestion is to remove something from a replay, it is as simple as ignoring it when playing back. It is only adding detail that may lead to incompatibility / etc.

Ignoring simply changing the selected skill should be easy enough. However, I believe the skill would still get changed when assigning a skill (other than the currently selected one) to a lemming, and this may be trickier - though far from impossible - to change.

I can consider this if it seems to be agreed on as a good idea; I can see benefits in both sides of it (for example - if you're going quite far back, you may expect the selected skill to be builder because that's what's currently being used, but in fact basher is currently selected because the replay's selections were not applied).

Look at the skillbar, it shows that builder is selected.
Try to assign builder at the correct place now.
Enjoy your basher assignment.

Just to be clear - you're saying this on account of that the basher was selected (from the replay) just before the user intended to assign the builder? Because if it shows the builder as selected, but actually assigns a basher, this is very much a bug - possibly as a result of some error with the new save-stating.

[Simon]

Just to be clear - you're saying this on account of that the basher was selected (from the replay) just before the user intended to assign the builder?

No bug related to savestating. I muddled my experience with what the program does.

Program shows builder. Then program switches to basher and shows basher. Then program accepts assignment and assigns basher. According to the current design, that's correct.

Experience: The switch to basher happens unexpectedly, or very shortly before the click. I don't notice the switch to basher, and therfore a human assumption is violated at time of click.

-- Simon

[namida]

I don't notice the switch to basher, and therfore a human assumption is violated at time of click.

The "change selected skill" sound effect should still play, unless you've turned sound off.

Anyway, I'll see if I can implement this change, although I will almost certianly make this an option, as there are good reasons to favor both behaviours (personally, I've found it quite annoying how Lix doesn't select the skills based on the replay's actions - quite possibly as a result of being used to how (Neo)Lemmix does).

[Simon]

"change selected skill" sound effect should still play

Yeah, the sound plays still.

I've found it quite annoying how Lix doesn't select the skills based on the replay's actions - quite possibly as a result of being used to how (Neo)Lemmix does).

This is interesting feedback.

I've plowed through the project history. Lix replays affected the current skill until June 2015. Then, I considered it bad design in Lix, and made the skill independent from the replay.

People haven't asked for detailed justification of the change. geoo was surprised how clicks on skill buttons wouldn't cancel the replay anymore.

Do you have a strong association of (what's currently assigned on the screen) to (what would be assigned with next click)? This assumption doesn't always map to program behavior, with assignments far apart spatially, but close together in time.

will look into adding an option to ignore the replay's skill changes.

Awesome.

I don't care about what ends up in the file. Especially if you make an option, you probably want UI candy over the old replay data format. Good with me!

-- Simon

[namida]

I've implemented making the replay's skill selections / assignments not change the currently selected skill; this was quite simple. The potentially harder part will be making changing skill while replaying not interrupt the replay.