Add the ability to assign multiple aimpoints on a unit

[drivver44]

Currently all units can only accept one aimposition (ussually its in line with the midposition of the unit/building)

there are a number of known to me edge cases where the same unit or building will be in a one way engagements while stationary

https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2897

[PtaQQ]

To flesh out this ticket a little bit, what we would like to explore is:

• the possibility of enabling encoding multiple aimpositions (aimpos) into units and features s3o
• making those additional aimpositions able to be used for unit line of fire checks
• if unit uses multiple aimpositions, it should also be possible to control for their priority (if line of fire check returns nil for aimpos1, check aimpos2, aimpos3 and so on)

What issue does it solve? Currently engine allows for a single aimposition per unit/feature. That becomes problematic is an array of situations:

• when unit model sticks out of the water but it's aimpos is submerged, units will not target it, despite visual cues tell they should be able to
• unsymmetrical interactions between units, as exemplified here: https://github.com/beyond-all-reason/Beyond-All-Reason/pull/2897
• big units often can;t be targeted despite visually looking like they should, if their aimpos is covered by terrain etc but there are parts of the model and colvol which are not covered.

[drivver44]

* when unit model sticks out of the water but it's aimpos is submerged, units will not target it, despite visual cues tell they should be able to

this is already handled by an alldeffs line somewhere here is a picture of a commander whose aimposition is below the water line and is being shot at by a whistler

the issue that kroyla raised was about catagories not aimpositions

[lostsquirrel1]

Re: the possibility of enabling encoding multiple aimpositions (aimpos) into units and features s3o

Is the model the correct place for this? Wouldn't the unit def be a better place? I admit I'm not sure what the litmus test is for determining whether a property should be in the unit or the model.

[drivver44]

Re: the possibility of enabling encoding multiple aimpositions (aimpos) into units and features s3o

Is the model the correct place for this? Wouldn't the unit def be a better place? I admit I'm not sure what the litmus test is for determining whether a property should be in the unit or the model.

aimpositions are adjusted currently as offsets of the midposition the two can and are normally the same spot on a model but that is just current behavoir

doing it via unitdeff make sense if the aimpositions are their own point and not an offset

[lostsquirrel1]

I guess you would want artillery to aim at the bottom centre of units in preference? I guess you would want regular shots to aim at the mid centre of units in preference? I guess you would want a fall back to top centre of units in case the previous checks fail? I'd guess artillery would check bottom, then mid, then top for example. While regular units would check mid then top. And lasers may need to pick the nearest point first?

[sprunk]

Units can be long but not very tall, for example aircraft or ships. In that case top/bottom extra aimpoints wouldn't help much if the center is obscured, but front/back might. So perhaps it would be best to let the gamedev specify extra points per unit type as appropriate to the mesh rather than hardcoding points.

Another edge case: when a target is proportionally very large compared to weapon range (e.g. melee, or maybe a building is just really big) the optimal (sometimes the only) place to hit may be not be some salient place like top or middle, but just some random spot that happens to be in range. Extra aimspots don't really help or harm this one but maybe it's good to keep in mind.

[lostsquirrel1]

It almost sounds like the engine should call into Lua, and ask for the game to aim check for a weapon and provide helper functions to support the game code.