[SUGGESTION] [PLAYER] [ADDED] Mass-assigning floaters to dense bunch

[Simon]

Status: Changes have been made to prioritization algorithm, see this post. Topic remains open so how to improve it further (if nessecary) can be discussed.

[Simon]

Have 10 lems densely packed. We want to assign floaters to all of them. Select floater. a) Hover with the mouse over the bunch, and click 10 times. Alternatively, b) hold select-only-walkers, and click 10 times on the bunch.

Expected: 10 floater assignments to 10 different lems.

Observed instead: 1 assignment, both in a) and b). The game seems to prioritize the existing floater for further assignments.

-- Simon

[namida]

The status of already being a floater has no impact either way on the priority. The highest-priority lemming remains the highest-priority lemming, both before and after being assigned the floater skill. Priority is not dependant on what skill you're trying to assign. Whether it should be or not is another matter...

[mobius]

I've mentioned this problem in the past [not here or for this, it was a long time ago]. Assigning floaters to falling lemmings can be really annoying. RTW makes a good example of this while using Lemmini:
(go to last level in video) https://www.youtube.com/watch?v=nk7igS5sB_I&list=PL_pnO1EM18vtukwX6tCO7GzmQk20tBCOD&index=20
obviously due to different reasons it's not quite as bad on NeoLemmix but the same problem is still here.

I think the best solution to this problem is to simply have the selection priority invert button work with not only walkers; but also fallers and any lemming doing anything other than a skill [building, bashing, climbing etc.]

Swimming and other non-permanant skills may present a problem here idk....

[namida]

This is essentially what the problem comes down to - there isn't one single answer as to how it should be handled; everyone has their own opinions, and it may even depend on the situation. However, a rule of "ignore lemmings the skill cannot be assigned to" may work as a fairly logical starting point.

[mobius]

actually I was just going to say that--since I've only seen this problem come up with floaters [though I feel like there is a similar or related issue but can't think of it right now.] you may even be able to get away with making a special exception in the case of floaters.

[Simon]

möbius: Thanks for pitching in with demand for this. ;-)

I think the best solution to this problem is to simply have the selection priority invert button work with not only walkers

Your idea works for mass-assigning floaters to fallers.

But a dense bunch of walkers couldn't be mass-assigned like that, because they don't stop walking after the assignment. Mass-assigning climbers to walkers is maybe more common, and would exhibit the same interaction with select-only-X.

With the current priority code, select-only-walkers or priority-invert alone can't solve the underlying problem.

I'm biased from having implemented my own solution, priorityForNewAc(). The code may be ugly, but the resulting behavior feels good.

However, a rule of "ignore lemmings the skill cannot be assigned to" may work as a fairly logical starting point.

Yeah.

-- Simon

[namida]

I've implemented some changes to this; probably not to the full extent that could be done, but it will have to do for now (as the priority detection code needs major overhauling at some stage anyway, so I don't want to do too much quick-fixing in it).

Basically - I've made it so that if a lemming is in a state from which it cannot perform a skill, it will be de-prioritized (but not entirely unselectable) if that skill is selected. For example, if you have the Glider skill selected, Floaters and Gliders will be deprioritized; if you have the Builder skill selected, builders, blockers, ohnoers, etc will be deprioritized.

This also extends to a few cases that aren't strictly speaking a matter of can't be assigned, but not very logical to do so - for example, you technically can assign the Swimmer or Disarmer skill to a ghost, but there's not much use in doing so, so they'll be deprioritized.

One side effect is that this priority change based on selected skill applies even to things where the selected skill is irrelevant, such as highlighting a lemming. For now, I'm not worried about this; if people report that it's problematic, I'll do something about it.

I've uploaded a new experimental version that contains this modified prioritization behaviour.

I'll leave this topic open for further discussion on this matter.

[IchoTolot]

I've implemented some changes to this; probably not to the full extent that could be done, but it will have to do for now (as the priority detection code needs major overhauling at some stage anyway, so I don't want to do too much quick-fixing in it).

Basically - I've made it so that if a lemming is in a state from which it cannot perform a skill, it will be de-prioritized (but not entirely unselectable) if that skill is selected. For example, if you have the Glider skill selected, Floaters and Gliders will be deprioritized; if you have the Builder skill selected, builders, blockers, ohnoers, etc will be deprioritized.

This also extends to a few cases that aren't strictly speaking a matter of can't be assigned, but not very logical to do so - for example, you technically can assign the Swimmer or Disarmer skill to a ghost, but there's not much use in doing so, so they'll be deprioritized.

One side effect is that this priority change based on selected skill applies even to things where the selected skill is irrelevant, such as highlighting a lemming. For now, I'm not worried about this; if people report that it's problematic, I'll do something about it.

I've uploaded a new experimental version that contains this modified prioritization behaviour.

I'll leave this topic open for further discussion on this matter.

This sounds excellent!     Catching lemming bunches with floaters will finally be easy

[Nepster]

Very good change!

This also extends to a few cases that aren't strictly speaking a matter of can't be assigned, but not very logical to do so - for example, you technically can assign the Swimmer or Disarmer skill to a ghost, but there's not much use in doing so, so they'll be deprioritized.

Do I understand it correctly, that assigning the completely useless Swimmer and Disarmer skill to ghosts is still possible in V1.39?

[namida]

Very good change!

This also extends to a few cases that aren't strictly speaking a matter of can't be assigned, but not very logical to do so - for example, you technically can assign the Swimmer or Disarmer skill to a ghost, but there's not much use in doing so, so they'll be deprioritized.

Do I understand it correctly, that assigning the completely useless Swimmer and Disarmer skill to ghosts is still possible in V1.39?

Yes, this remains possible. There's nothing that makes the ghost unable to receive the skill per se (compared to say, trying to assign a builder to a blocker); I figure it doesn't make sense to prevent an assignment altogether just because it isn't useful. However, I did indeed feel that deprioritizing the ghost in such a case was well and truly justified.

[Nepster]

Sorry, but you already have instances, where a priori a lemming should be able to receive a skill, but it isn't allowed, because it is useless:
- A builder isn't a priori unable to receive skills, but making him a builder would simply not result in any change and the builder would be wasted. So one cannot assign builders to blockers, because it would be useless!
- Gliders cannot be assigned to lemmings already having the floating skill, because again this would be a waste of skills.
- Drowners can be assigned skills as seen by the Swimmer skill. However making him a Climber does not work. Even worse: The Stoner, which would be useful, doesn't work as well.
- In the gimmick "clone on assignment", diggers are not cloned. However one can assign cloners to regular diggers.
These examples should stay as they are - I mention them only to show you that you already disallow wasting skills. So the general rule is: One can only assign skills that the lemming is able to use.
If I use the climber skill on a lemming, I expect him to climb. If I assign it to a ghost, I would expect the ghost to climb as well. And in the same way I would expect the ghost to swim/disarm if I gave it the swimmer/disarmer skill.

[ccexplore]

The simplest case that even exists in the original L1 game mechanics, is that it never lets you assign a skill to a given lemming if that lemming is already performing/having the skill (the latter for permanent skills like climbers and floaters).  This is even if you consider carefully that removing this check for builders, bashers, miners and diggers wouldn't necessarily have resulted in a wasted assignment (though likely so in most cases).  L1 even blocks you from doing basher/miner/digger skill assignments that it knows will conflict with steel or OWW (even though it can perhaps be argued that this is not as useful, and in fact they did remove this check by L2).  So I think overall, Nepster's principle is probably a good one to consider.

L1 is probably not the best to model after anyway.  It has fewer skills, and has known issues like having no prioritization schemes at all for climbers and floaters (thus leading to problems like the one noted in this topic).  L2 might be better, but I'm not sure if anyone knows all the exact details of its assignment logic.  Lix's is probably a good one to model after as more deliberate thought has been put into prioritization logic (and in fact fixes have been made in that area previously to address problems that had occurred in actual gameplay).

[namida]

Discussion of whether that should be changed should probably be put in its own topic.

[Simon]

The L2 assignment is blocking like old NL assignment: If there are a walker and a stunner under the cursor, and the game prefers the stunner, clicks do nothing. This is the prime cause of Ceci n'est pas une pipe's difficulty: Assign the bomber fast enough.

Lix doesn't feature highlighting, and I take some pride in how the assignment is good enough to render highlighting unnecessary. Theoretical problems with highlighting: You have to pick the lem ahead of time, before it becomes impossible to select it. This is only possible if there is a time when you can select the lemming. And highlighting is stateful.

In practice, there may well be people who don't like priority-invert, and would take highlight over it any day. And there will usually be time, especially with framestepping, when you can highlight the correct lem.

My judgment is that mass-assigning permanents is a must -- and it's awesome that it's in now --, following Nepster's rule is warmly encouraged,  and adding finer-grained priority and priority-invert are merely pretty nice.

-- Simon