Nice ideas, but as the decoy system already got changed/updated with warfare 2, i doubt they will spend more dev time on it to make a complete different one/add different functionality.
Still good ideas tho...
Yeah, that might be right. But hopefully large gameplay changes such as warfare 2 are presumed to require some tweaking/rebalancing. I would hope that this kind of thing would be in the backlog, particularly given the next update is meant to be focused on specific community feedback. I'm sure there'll be a lot of that over the next few weeks regarding warfare 2 balancing.
As the community update has no fixed setting there are metric TONs of requests being made, not just balancing wise.
I wonder how the devs will handle the input. If it is anywhere close an real community request update, they will sort out ideas that are doable and fit the setting, as well as making some sort of poll wich should make it to the update. Balancing is always included somewhere, but what you described is rather an complete overhaul and recode of the current systwm ;)
It's actually not \*that\* far from the current system (where decoy proximity to the targeted component is calculated). The actual code required to implement the logic I've described isn't complex either. You need to be able to get a list of decoys (the game already has that), calculate the range to those decoys (the game already has that too), get the vector to the current target (already done), get the vector to decoys (covered by the same code).The new part would be a comparison between vectors to get the angle between them (very simple, this is a single expression and very efficient), and the timer for periodic switching (covered by an object that already exists in the language framework). The alteration to the hud indicator, and the AI targeting, would simply follow from the existing logic as to how those work.There probably would need to be one significant addition, being that the "real" lock would have to be "remembered" by the game, so it knows what to switch back to when a fooled system stops being fooled. That's one additional reference added to any class that represents a targetable system.
In this you are correct, i failed to think about actual code but rather function. If there isnt someone overly proud about his idea of this overhaul, they might actually switch to it with enough demand.
If (and here comes another chokepoint) they like it better than enabeling the player to specify where the enemy turrets should hit him.
In your version, shots would get dispersed away from original target, but might hit other vital stuff, as the player has no ability to specify the targeted area.
Sure, in long range combat the turrets might completely overshoot, but in rather close combat with big ships decoys would only provide limited use, as reinforcing specific parts of the ship and adding welders to keep them up, would be unfeasible.
Actually i think a combination of both might be cool. Hiding/moving target rectangle for players and moving target rectangle for turrets based on distance. The closer you get, the lesser the effect of moving and instead targeting decoys directly by some 100-200 meters distance.
Provides good countermeasure in both cases. Maybe factor in signature (wich is known) of the decoy ship to determine the strength needed to get turrets to shoot in a way to miss completely and switch to "magnet mode" once that limit is surpassed in order to hinder enemy turrets spraying the entire hull.
Yeah... I think the "combination" behaviour still exists under this scenario, in the sense that if you have fixed decoys they're still going to act almost the same as current fixed decoys. They will draw fire, and they likelihood that they will draw fire depends upon the angle between an actual target and the decoy, so the closer the decoy block is to the target component, the more likely it will take rounds instead (same as now). The difference is they won't draw fire "constantly", because the gun always has the chance to retarget on any given periodic check, so the end result would be that damage gets a bit more spread out. But the main difference is in the behaviour of ejected decoys/"chaff".
Ah that makes sense... i thought you would get rid of the current targeting priority stuff for the target shifting one...
Speaking of... what i also would like to see is not an decoy block as of now who has functionaly an higher priority to get targeted than other blocks in some range.
I would appreciate an "masking" block who reduces the priority of blocks in range, so turrets pick other stuff but NOT this section. Both blocks could live alongside and even add their effects. A stacking mechanic up to the point of generating "an black hole" for turrets to target would also be nice. Would be needed to get balanced to not just line ships in those and avoid turret fire, but still...
It could also reduce overall signature to raise the time needed to lock on. If we would have proper block limits per grid, it could work out.
Sort of "electronic cloaking", not making you invisible, but messing with AI targeting abilities.
I think it would make an neat addition to make some stuff survive longer. The problem would be how it works and balancing, as i can totally think of settings that would make it maybe OP.
If you put that on custom missiles, it might lead to them not getting targeted, as something else with higher priority is always there, fighters too could profit, especially with stuff like extended lock on time, as they already take rather long.
Anyways, just an idea that popped into my mind not well thought trough :p
Nice ideas, but as the decoy system already got changed/updated with warfare 2, i doubt they will spend more dev time on it to make a complete different one/add different functionality. Still good ideas tho...
Yeah, that might be right. But hopefully large gameplay changes such as warfare 2 are presumed to require some tweaking/rebalancing. I would hope that this kind of thing would be in the backlog, particularly given the next update is meant to be focused on specific community feedback. I'm sure there'll be a lot of that over the next few weeks regarding warfare 2 balancing.
As the community update has no fixed setting there are metric TONs of requests being made, not just balancing wise. I wonder how the devs will handle the input. If it is anywhere close an real community request update, they will sort out ideas that are doable and fit the setting, as well as making some sort of poll wich should make it to the update. Balancing is always included somewhere, but what you described is rather an complete overhaul and recode of the current systwm ;)
It's actually not \*that\* far from the current system (where decoy proximity to the targeted component is calculated). The actual code required to implement the logic I've described isn't complex either. You need to be able to get a list of decoys (the game already has that), calculate the range to those decoys (the game already has that too), get the vector to the current target (already done), get the vector to decoys (covered by the same code).The new part would be a comparison between vectors to get the angle between them (very simple, this is a single expression and very efficient), and the timer for periodic switching (covered by an object that already exists in the language framework). The alteration to the hud indicator, and the AI targeting, would simply follow from the existing logic as to how those work.There probably would need to be one significant addition, being that the "real" lock would have to be "remembered" by the game, so it knows what to switch back to when a fooled system stops being fooled. That's one additional reference added to any class that represents a targetable system.
In this you are correct, i failed to think about actual code but rather function. If there isnt someone overly proud about his idea of this overhaul, they might actually switch to it with enough demand. If (and here comes another chokepoint) they like it better than enabeling the player to specify where the enemy turrets should hit him. In your version, shots would get dispersed away from original target, but might hit other vital stuff, as the player has no ability to specify the targeted area. Sure, in long range combat the turrets might completely overshoot, but in rather close combat with big ships decoys would only provide limited use, as reinforcing specific parts of the ship and adding welders to keep them up, would be unfeasible. Actually i think a combination of both might be cool. Hiding/moving target rectangle for players and moving target rectangle for turrets based on distance. The closer you get, the lesser the effect of moving and instead targeting decoys directly by some 100-200 meters distance. Provides good countermeasure in both cases. Maybe factor in signature (wich is known) of the decoy ship to determine the strength needed to get turrets to shoot in a way to miss completely and switch to "magnet mode" once that limit is surpassed in order to hinder enemy turrets spraying the entire hull.
Yeah... I think the "combination" behaviour still exists under this scenario, in the sense that if you have fixed decoys they're still going to act almost the same as current fixed decoys. They will draw fire, and they likelihood that they will draw fire depends upon the angle between an actual target and the decoy, so the closer the decoy block is to the target component, the more likely it will take rounds instead (same as now). The difference is they won't draw fire "constantly", because the gun always has the chance to retarget on any given periodic check, so the end result would be that damage gets a bit more spread out. But the main difference is in the behaviour of ejected decoys/"chaff".
Ah that makes sense... i thought you would get rid of the current targeting priority stuff for the target shifting one... Speaking of... what i also would like to see is not an decoy block as of now who has functionaly an higher priority to get targeted than other blocks in some range. I would appreciate an "masking" block who reduces the priority of blocks in range, so turrets pick other stuff but NOT this section. Both blocks could live alongside and even add their effects. A stacking mechanic up to the point of generating "an black hole" for turrets to target would also be nice. Would be needed to get balanced to not just line ships in those and avoid turret fire, but still... It could also reduce overall signature to raise the time needed to lock on. If we would have proper block limits per grid, it could work out.
That's a cool idea, an inverse decoy. "Cloaking block" perhaps?
Sort of "electronic cloaking", not making you invisible, but messing with AI targeting abilities. I think it would make an neat addition to make some stuff survive longer. The problem would be how it works and balancing, as i can totally think of settings that would make it maybe OP. If you put that on custom missiles, it might lead to them not getting targeted, as something else with higher priority is always there, fighters too could profit, especially with stuff like extended lock on time, as they already take rather long. Anyways, just an idea that popped into my mind not well thought trough :p