Subsystem targeting logic request

[pref]

I have a lot of fun fighting bigger targets in an M ship, the flight controls/physics are awesome but i think the experience could be much improved with a few minor changes.

The way it goes is i close in on the target, selecting the most dangerous turret at first.
When i kill it i have to pause the game while still in range of all the turrets on the target in the most intense situation.
Have to reselect the target as i have none after having the subsystem killed.
Have to cycle through tons of subsystems to get to another turret.
Then release pause and continue the fight. This causes me to epically fail like 4 out of 1 pause events as i loose precision of control due to the yaw/pitch angle change with the mouse position/hotas while in pause and the delay between pause releasing and reacting to it.

This is so damaging to the experience.
Wouldn't it be better if
1. On subsystem kill the parent object would be autotargeted,
2. The order of cycling the subsystems would be turrets first and then shields?

This would get rid of the pause phase altogether, the whole fight would go much more fluently.
Would this hurt anyone's playstyle? Or is this more complicated to implement then it sounds? (never heard about such a thing in software development : )

[CBJ]

We're going to make it so that the game auto-selects the next target (or subsystem) when the current one is destroyed. That should pretty much match point 1 of your request. The issue with your point 2 is that we don't know what the player is doing at any given time, so whatever logic we choose for the order of targets is going to be wrong for someone, if not most people. The current logic is that the order is defined by proximity to the target reticule, and that will remain the case with the above change.

[Buzz2005]

so glad you did this post, was meaning to do it myself

I play with a controller and less so with HOTAS and don't even pause the game to retarget so this problem is even worse for me

up until 6.0 version or such the targeting cycle was "static" so I could with some certainty retarget the turrets bc most times cycle "list" had turrets one after the other and while still losing the target I got used it and it was fast enough to just don't get mad about it

but then Ego decided to change it, on paper it sounds great, the target is what is in the center of aim dot cycling outward

first thing is the controls in settings are reverse so to target elements in the aim circle you need to use previous subsurface element, i you put next then it will target furthest

was going crazy until I figured that out and CBJ was constantly telling me it was working

second thing is this new way is totally worse then before, playing with a controllerer you need to be dead set on that turret to target it, if it's just a little outside it tragets a shield on the other side of the ship or maybe some other shield that could be closer or not, in the heat of battle and in the dark of space you can't really see where exactly is that dead center of the turret and so I get mad all the time trying to actually target it

third thing is why aren't turrets a priority in surface element targeting I could be wrong but 99% of the time you are trying to target a turret, why would I ever target a M shield while a turret next to it is shooting at me

last thing i want to say is I agree with you 100%, why not have automatic retarget of same closest element?

kuertee mod does that but it retargets shields and that just gets even more confusing and frustrating when it auto switchs to shields when I quickly mash targeting buttons on my controller since i will get a xenon bullet in the head if Im not fast

this is all experience with mostly dealing with xenon ships

this is all a problem for controller/hotas play, with k+m you just click on the turret

[Nanook]

....
third thing is why aren't turrets a priority in surface element targeting I could be wrong but 99% of the time you are trying to target a turret, why would I ever target a M shield while a turret next to it is shooting at me...

Many turrets come in pairs, and usually are protected by a single shield. Knocking out the shield first greatly reduces the time it takes to knock out the two protected turrets. When this is the case, I always go for the shield first. Also, shields seem a lot easier to destroy than the turret(s) they protect, so it makes sense to knock them out first, if you can.

[pref]

The current logic is that the order is defined by proximity to the target reticule, and that will remain the case with the above change.

I'm talking about priority when cycling the subsystem targets with the dedicated keybind, not when the target button is clicked. Target button works fine, at least for me.

Many turrets come in pairs, and usually are protected by a single shield. Knocking out the shield first greatly reduces the time it takes to knock out the two protected turrets. When this is the case, I always go for the shield first. Also, shields seem a lot easier to destroy than the turret(s) they protect, so it makes sense to knock them out first, if you can.

Don't think we're talking about the same thing.
Once the current surface element is killed no target is selected. Wouldn't expect the game to memorize last killed target and select the shield belonging to it?
I'm talking about the subsystem cycling, and having a turret/generally turrets as first selection when one starts cycling if possible.

But in your example situation it's always better to go for the other turret in the pair as that has no shields either and with that you reduce the incoming damage. Their shield should come right after that ideally.

The best would be if after subsystem kill the game would select the next subsystem in the same batch or the next batch of subsystems that still has a turret. Then there is no need to cycle in most cases.
I just thought the simpler the request the better.

[pref]

The best would be if after subsystem kill the game would select the next subsystem in the same batch or the next batch of subsystems that still has a turret. Then there is no need to cycle in most cases.
I just thought the simpler the request the better.

On second thought maybe i should have requested this initially, seemed like a more complex one but maybe it's not much harder then autoselecting the parent?
Or have the cycle subsystem target button select the next target according to the above logic but that feels a bit complicated having to memorize the last player killed subsystem.

[Koizuki]

I do agree there should be improvement in this area, as I've run into the same issues myself. For example, trying to quickly disable that SCA Phoenix before it starts making life difficult, and you have to cycle through so many things to get to each engine. Then you shoot off the turret on one wing and have to cycle through 30 objects to get to the next closest turret.

There should be some additional logic here, where when a subsystem is destroyed, try to select the next nearest subsystem of the same type that was just destroyed, within line of sight if possible, otherwise just next nearest if no line-of-sight-eligible targets exist. If no more subsystems of that type exist, just switch back to targeting the ship itself, so that the player can start cycling manually.

For manual cycling, it should prefer to cycle through subsystems that again have line of sight first before going through the list of obscured subsystems. "Select target at crosshair" (I forget the exact term for this in-game) should target subsystems nearest to it as well, obviously with line of sight required. Using this in tandem with the previous suggestion should allow for rapid engagement of subsystem clusters -- target either the shield or turrets first, and when one group is exhausted, press T (or whatever it was) while you're still aiming at that section and it should immediatley pick up the other thing from that cluster that needs to be destroyed.

This should make combat against larger ships much simpler and less reliant on pausing every few seconds to find your next target. How feasible it would be to implement these, though, I have no idea.

[CBJ]

I'm talking about priority when cycling the subsystem targets with the dedicated keybind, not when the target button is clicked.

So am I.

[pref]

I'm talking about priority when cycling the subsystem targets with the dedicated keybind, not when the target button is clicked.

So am I.

Cycle always gets me the same subsystem first, no matter if it's the farthest one to my location or aim point. Just tried it again to be sure. Has nothing to do with proximity.
Also the order of cycling is fixed in my experience.

If it worked like you say it would be much better.

Edit: I mean the Next/Previous surface element bind under Target management section of general controls.

[Nanook]

The current logic is that the order is defined by proximity to the target reticule, and that will remain the case with the above change.

I'm talking about priority when cycling the subsystem targets with the dedicated keybind, not when the target button is clicked. Target button works fine, at least for me.

Many turrets come in pairs, and usually are protected by a single shield. Knocking out the shield first greatly reduces the time it takes to knock out the two protected turrets. When this is the case, I always go for the shield first. Also, shields seem a lot easier to destroy than the turret(s) they protect, so it makes sense to knock them out first, if you can.

Don't think we're talking about the same thing....

I think we are. You used the term "autotargeted" in your OP. My point was that I don't want the game automatically choosing my next target, no matter what it may be. I kill a shield, then I kill one or two turrets. In your system, I'd have to then deselect whatever the game chose for me, then pause, search for and target what I wanted. You see my problem? Currently, the shield and turret(s) are in close proximity so simply hitting 'T' almost always chooses the target I'm after.

[pref]

I think we are. You used the term "autotargeted" in your OP. My point was that I don't want the game automatically choosing my next target, no matter what it may be. I kill a shield, then I kill one or two turrets. In your system, I'd have to then deselect whatever the game chose for me, then pause, search for and target what I wanted. You see my problem? Currently, the shield and turret(s) are in close proximity so simply hitting 'T' almost always chooses the target I'm after.

No, i'm only talking about what happens when clicking the cycle subsystem button. The way it works currently is that you always go through the subsystems in a fixed order.
For ex targeting an asgard this happens regardless of circumstances:
1. target the ship
2. cycle once - this targets one of the engine shields
3. cycle again - targets other engine shield
4. cycle again - one of the engines
... tons of clicks on bigger targets until i get a subsystem in LoS ...
x. make it to a subsystem in sight
y. kill it
z. start from 1 on pause as i don't have seconds to do this while evading 10 turrets.

Hitting T is unreliable here as it's prone to err, in a close-up dogfight you don't have the opportunity to perfectly align the aim (even then it can pick a drone or something on the far side of the ship). So cycling works better as one can more-or less memorize the amount of clicks needed and it's safer then going to mouse click while releasing the controls.

If it was working as you say - cycle remembering the last target then i wouldn't need to request anything.
The autotarget suggestion is exactly what you just said, when killing a subsystem the next should be targeted from the same batch or the first in the next batch. Not restart from engine shields or whichever is first on that type of ship.
That would be perfect. I just thought that would be too much of an ask as it needs saving the last killed subsystem opposed to just changing the ordering.

Just selecting the parent on subsystem kill would only eliminate point 1 but not the rest.

[GCU Grey Area]

No, i'm only talking about what happens when clicking the cycle subsystem button. The way it works currently is that you always go through the subsystems in a fixed order.
For ex targeting an asgard this happens regardless of circumstances:
1. target the ship
2. cycle once - this targets one of the engine shields
3. cycle again - targets other engine shield
4. cycle again - one of the engines
... tons of clicks on bigger targets until i get a subsystem in LoS ...
x. make it to a subsystem in sight
y. kill it
z. start from 1 on pause as i don't have seconds to do this while evading 10 turrets.

Sounds like you're cycling with 'target next subsystem' key if it's always selecting the one most distant from your current aim point & you have to cycle through the entire ship to get to the subsystem you actually want. Suggest trying 'target previous subsystem' instead. Essentially they're wired up backwards.

[pref]

Sounds like you're cycling with 'target next subsystem' key if it's always selecting the one most distant from your current aim point & you have to cycle through the entire ship to get to the subsystem you actually want. Suggest trying 'target previous subsystem' instead. Essentially they're wired up backwards.

It's fixed order, regardless where am i or where i aim.

Edit: So to clarify i aim at the front or bow of the ship, while that's also the closest point of the ship from about a 60deg angle so my reticle points nowhere near the stern. I get the same cycle order as when doing it in opposite position and aim, aiming at the back of the ship and staying in proximity to it as well.

Maybe some setting affects this..?

[GCU Grey Area]

A few screenshots to illustrate.

This is what happens if I target a ship & then use target next subsystem: https://www.dropbox.com/scl/fi/e8l22u1d ... xh5dj&dl=0
Immediately selects the subsystem furthest from my aim point. If I keep hitting target next it cycles through all subsystems, in order of decreasing distance from aim point, until it gets to the engine closest to my aim point.

This is what happens if I target a ship & then use target previous subsystem: https://www.dropbox.com/scl/fi/k3twbc6g ... 7i0lh&dl=0
Immediately selects the closest subsystem to my aim point (same engine as mentioned above). If I keep hitting target previous it cycles through all subsystems moving away from my aim point until it gets to the shield in screenshot 1.

If I move my ship to a different position relative to the Mammoth, target it & use target previous it immediately selects the other engine, since that one is now closest to my aim point:
https://www.dropbox.com/scl/fi/cbieoa6h ... m69pt&dl=0

[ajime]

I just need a center reticle subsystem lock Keybinding instead of current endless pause and subsystem targeting scrolling, which abhorrent.

[pref]

I had a party with a few K's now and it works as CBJ described. Wanted to make a video to show the bug, but it turned into a cool fight.
I'll post it here anyway
https://www.youtube.com/watch?v=3B3tFAlJQUk

Could be better if it considered LoS, but that's just nitpicking - thanks for the explanations!

On the 'friendly' ships (asgard) i tested on earlier it really had a fixed order - or maybe i just have a severe memory issue..

[A5PECT]

Given the potiential number of surface elements a ship or station can have in X4, I'm not fond of arbitrarily ordered targeting lists and cycling through them one-by-one. Gonna plug my old idea for surface element targeting:

Tapping the "Target object under crosshairs" key functions as it currently does. Pressing and holding the key while an object is already targeted activates a new "Target Element Under Cursor" mode:

1. as long as the key is held, all surface elements on the target and within line of sight become outlined
2. any non-destroyed surface element under the mouse cursor becomes highlighted
3. releasing the key sets the highlighted surface element as the player's new target.

I feel this would work incredibly well in conjunction with VE goggles.

[pref]

Though after watching the vid again and killing 3 more K's at the same spot it would feel much more reliable if besides the crosshair proximity to the reticle also the distance to the player ship position was considered in picking the target somehow.

Could it order by distance to the point where the aim line crosses the geometry of the target, and use current logic if there is no intersection without too much dev effort?
I think that would give much better and more predictable results.

Providing visual feedback on selection as A5pect suggests would be nice, but with keeping the current or above suggested proximity check instead of the 'under the crosshair' + LoS condition - that level of precision does not work well in intense fights. Especially for elements that are just about to enter LoS, those should not be excluded from available targets in any way.


Additionally, in some cases it seems to target an element next to the crosshair and not the one right under it - had this with the graviton turrets in the K's belly on several occasions when it targeted a shield meters away from the crosshair while the turret was right under it.

[Ålma]

We're going to make it so that the game auto-selects the next target (or subsystem) when the current one is destroyed. That should pretty much match point 1 of your request. The issue with your point 2 is that we don't know what the player is doing at any given time, so whatever logic we choose for the order of targets is going to be wrong for someone, if not most people. The current logic is that the order is defined by proximity to the target reticule, and that will remain the case with the above change.

The subsystem targeting cycle (the one that is cycled through via the keys) is one of the most infuriating mechanisms in this (otherwise damn fine) game. I very much second the OP's frustration.

Making it so the target isn't deselected when the element is destroyed would be a start. What would also very much help IMO would be to prioritise, when cycling, elements that are not obstructed (i.e. those that can actually be fired at). There's a visual indicator for that, so the information should be at hand.

[CBJ]

Making it so the target isn't deselected when the element is destroyed would be a start.

You can't target something that isn't there, but in the 7.00 Public Beta, the next available target is now automatically selected when the current one is destroyed.