I think it's a good approach.

Related to #3387, #14769

Rebased and updated.

Would this need an upgrade rule for 3rd party mods and maps?

Would this need an upgrade rule for 3rd party mods and maps?

This isn't changing any default behaviour, right? If so, then no.

Would this need an upgrade rule for 3rd party mods and maps?

This isn't changing any default behaviour, right? If so, then no.

It's not changing the default behavior. It's just that the new feature won't be very usable without the YAML setup.

What's the status here @dragunoff?

@pchote I definitely want to finish this. But it turned out to be more complex than I thought. I think this warrants some more discussion.

The problem for me is that the modes are not tied to the selection priority, so calling them "flat" and "low priority" doesn't make sense... I thought about just calling them "default", "mode 1", "mode 2", "mode 3" and then let actors have different priority for each mode (falling back to the default priority). We can even let mods define the names for these modes and if the want to even use them. That would make the feature very flexible.

# A cobmat unit, priority lowered in MODE2
Priority: 10
Priority@MODE1: 10
Priority@MODE2: 0

# A support unit, priority raised in MODE1
Priority: 6
Priority@MODE1: 10

# A high priority combat unit,  priority lowered in MODE2 and raised in MODE3
Priority: 10
Priority@MODE2: 0
Priority@MODE3: 20

I'm not sure about the YAML notation, just trying to explain the idea.

How important is the "low priority" modifier? Can we get most of the gameplay benefits without the complexity by ignoring all the per-actor definitions and implementing this as a global "ignore priority" modifier during selection?

Yes, ignoring priority is fine - that way we can keep the normal priority based selection and introduce modified selections that force raise/lower the priority. The naming problem remains though.

What is there to name at this point? We wouldn't need to expose anything to the mod rules.

What is there to name at this point? We wouldn't need to expose anything to the mod rules.

How are we going to then define which actors should be included in which selection? 🤔

I may be misunderstanding your idea...

My suggestion was to have it include all actors that are controllable by the player.

If we really do need a distinction for buildings we could call have something like "ValidForFlattenedPriority: (true|false)".

Ah, I see - you suggest dropping the "low priority" mode entirely. I'd really like to make it work though ☺️ And the naming problem won't go away - what would stop modders from repurposing the "flat" mode into something else? That may not be a huge problem but it bugs me...

My motivation with exploring these other options is so that we can find a way to get this merged in time for the playtest branching.

Okay, so I have simplified this a little bit. And I'm finally (mostly) satisfied with the result.

I have dropped the selection modes names from the C# code and just named the flags after the actual modifier keys (Ctrl and Alt). This solves the naming problem and gives modders the freedom to use the feature however they want. For the default mods I've created two selection modes that are implemented as YAML templates which actors inherit.

I've also dropped my original idea for the "Low Priority" mode (where selection priority was honored) - now modifiers simply raise the selection priority to int.MaxValue thus always flattening the priority for affected actors.

Rebased on latest bleed.

Seems like you missed engineers (and thumpers?) in D2k. Looks good to me otherwise.

It is intentional as they don't have a lower selection priority in D2k. This should be tackled as part of #16662

https://github.com/OpenRA/OpenRA/wiki/Changelog-(bleed)/_compare/f3e83db7bd88d08dde9ea0a5557e3b3379a25611...d2b5c48c2528d629acc8ef41fffe229ac9c63613