Allow continuous weapon aiming across 45° elevation

[WatchTheFort]

Currently, a weapon def has to use the highTrajectory tag to choose whether it will always shoot below 45° or above 45°.

This requires a huge amount of code game-side to handle units which are desired to fire either low or high trajectory automatically (see beyond-all-reason/Beyond-All-Reason#3720).

Allow weapons to continuously target throughout an elevation of 0° to 90°, and add weapon def tags to optionally specify minimum and maximum elevation angles.

When doing targeting checks, prioritize low trajectory, and only switch to the high trajectory angle if low trajectory is blocked or forbidden.

Deprecate the highTrajectory tag in favour of minimum and maximum elevation angle tags.

[sprunk]

Currently, a weapon def has to use the highTrajectory tag to choose whether it will always shoot below 45° or above 45°.

AFAIK 45° has nothing to do with it. It just picks between the two angles that are valid firing solutions, just that 45° happens to be the breakpoint for targets on equal elevation. But you can have a target already above 45°, units of both trajectory settings can target it and it will pick between the straight angle and the 89ish° one.

add weapon def tags to optionally specify minimum and maximum elevation angles.

Sounds good, perhaps it should be +/- compared to a mainDir though since that sort of already exists and almost does what is wanted, except it currently uses a cone:

As a corollary, if you need to move the gameside BAR PR forward you can already specify a maximum by setting the mainDir to Y -1 and setting a maxAngle above 180°:

When doing targeting checks, prioritize low trajectory, and only switch the high trajectory angle if low trajectory is blocked or forbidden.

IMO have a separate bool, "able to pick alternate trajectory", and then it would prioritize according to the highTrajectory tag (so 0: defaults to low but can go high, 1: defaults to high but can go low, 2: defaults to whatever the player sets but can go the opposite)

[lhog]

@sprunk theory looks right to me, there are usually two firing solutions corresponding to the high arc and more direct mode of fire.
Generally agree with his approach.
I'd expand highTrajectory to also accept -1 to prefer the low trajectory (but check both) and -2 to prefer the high trajectory, but check both or something like that.
Overall doesn't look too complicated almost a candidate for good first issue

[sprunk]

Would also solve this legendary Emmanuel ticket.

[lostsquirrel1]

Sprunk is correct. There are always 2 shooting solutions. I think understanding the problem to be solved here is the first step to being able to help you. I wish people would avoid deciding on a solution to a problem and ask for it to be implemnented in engine, and instead explain the problem they are having, how the solution should look to the player, and then maybe throw out some ideas on how it could be solved.

[WatchTheFort]

The issue is that of the two shooting solutions, low & high, you have to pick one. We want smart handling, so low is default, but if low is blocked, high is used.

Currently, implementing that game-side is a huge headache, involving complex unit scripts and dummy weapons, with tons of edge cases.

[SethDGamre]

Isn't quite so simple for game engine to handle without knowing the exact use case.

• When should low trajectory be preferred?
• should low immediately change to high? How long should it remain low until switching to high?
• how long should it stay high after being triggered?
• what happens if the target is intermittently returning true for a target check from low then high then low etc?
• what if the target moves much, much faster than high could ever hope to hit?

We would need more levers to fiddle with user side to get the desired behavior right beyond highTrajectory = 3

[lostsquirrel1]

The issue is that of the two shooting solutions, low & high, you have to pick one. We want smart handling, so low is default, but if low is blocked, high is used.

Currently, implementing that game-side is a huge headache, involving complex unit scripts and dummy weapons, with tons of edge cases.

That isn't going to be good for performance. You'd have to ensure the number of active units using it is always smallish, otherwise it will be used as a means to grind multiplayer performance to a halt.

[SethDGamre]

That isn't going to be good for performance. You'd have to ensure the number of active units using it is always smallish, otherwise it will be used as a means to grind multiplayer performance to a halt.

Worse than LUS gadget implementation alternative?

[lostsquirrel1]

I know don't know about the LUS gadget alternative, so I couldn't say. Part of the appeal for TA-genre games is the large scale battles - trying to add computationally complex mechanics to potentially a large number of units is going to reduce the practical size of the battles.

[sprunk]

Hopefully uncontroversial: Spring.SetUnitWeaponState should accept a "highTrajectory" argument that lets you set the mode for a weapon. This avoids the need for dummy weapons.

[SethDGamre]

Hopefully uncontroversial: Spring.SetUnitWeaponState should accept a "highTrajectory" argument that lets you set the mode for a weapon. This avoids the need for dummy weapons.

that would solve the need for a separate high trajectory weapondef.

The dummy weapon in the smart select gadget I wrote was to provide a static QueryWeapon point to aim from a static unmoving location slightly lower than the turret to reduce erratic GetFreeLineOfFire returns

[sprunk]

Spring.GetUnitWeaponHaveFreeLineOfFire already accepts an arbitrary xyz as the source query point, you can pass any piece's position there without having to define a new weapon. I guess that function's interface is an undocumented mess.