I wonder if we can just get general engine-driven calculation for predicted projectile hit position? This way you could run it in Fired to find out where AI was firing. This will differ a bit from where AI *wanted* to fire though.

getArtilleryComputerSettings sounds good place to put this.
The position is stored in global UI, "GetAtilleryTarget"
the settings command could also return a reference to the UI display? Like shownArtilleryComputer checks.
Its actually a dialog, the dialog that https://community.bistudio.com/wiki/dialog checks. That could've also just returned the dialog display (which can then be checked for null), but alas we have 20 years of tech debt.

Using getArtilleryComputerSettings makes sense for players, but I'm not sure how it'd work for AI artillery since they don't use the UI (and there can be more than one of them on a machine). I'd prefer to have a solution that can also work for AI.

What I'd personally like to see for this would be:

• unit EH for artillery firing that gives info about the target (possibly could skipped as can be replicated with Fired EH + following items)
• a command to get what an artillery unit is currently aiming at
• a command to get an AI's current fire mission (as set with e.g. doArtilleryFire)

REV 151946 ArtilleryShellFired mission EH

@BIS_fnc_KK thanks for this!

I have a bit of a theoretical question on this. I see it's a mission event handler, which means it has local effect, but wiki says ArtilleryShellFired is global, which means... it's global effect??

I'm trying to understand what it means for server/client/network if say two players and and AI have one MLRS each. Assume each one of them fires a 40-round salvo almost simultaneously... is that 40x3xN executions where N is the sum of number of clients + server? Does this go over the network? Should this be avoided? 😅

Wondering if it's better to have it trigger once per fire mission instead, and _shell returns just the first fired shell? For players I guess it could work each time the FIRE button is pressed, since 3rd party artillery pieces can fire salvos and not just single rounds like vanilla vehicles. So in that sense, each time the FIRE button is pressed it's a discrete fire mission for players, which would be consistent with how it would work with AI fire missions.

Adding some stuff from Discord #dev_rc_branch channel:

In T180721#2653113, @SuicideKing wrote:

I'm trying to understand what it means for server/client/network if say two players and and AI have one MLRS each. Assume each one of them fires a 40-round salvo almost simultaneously... is that 40x3xN executions where N is the sum of number of clients + server? Does this go over the network? Should this be avoided? 😅

Killzone_Kid — 14/08/2024 21:11
the big shells are network synced so can trigger EH globally without loss of performance. they are also seldom events in game not like firing vulcan

Is there a way to expand the EH to obtain the fire mission too? like do fire missions have an ID or something?

In my current implementation of a counter-battery artillery script, I am handling it by adding a Fired EH and then removing it using the code executed by the EH (so that it only fired once), and then adding it again later, which i think is super clunky.

I just need to answer the question "where is the artillery firing this time" but having this information per shell in the fire mission is not useful to me (but it can be for other implementations, so it's good to have), and would just add more processing steps (which i'm not sure of how to handle with this EH really).

So this EH solves the problem of having a unified EH to track artillery fire events and targets for players and AI (hopefully ignores commander turrets?) but will still cause complications for tracking per-firemission info. For example, if the target is the same then it's the same fire mission, but that's not necessarily true at all. I could impose a time limit but artillery units in the game have significantly different salvo firing rates. So i'm a bit unsure of what the solution is, short of removing and re-adding the EH, but since this is global and tracks all artillery units, it would be chaos :/

It could be as simple as adding a counter to the vehicle (unit namespace?) that increments from 0 on each fire mission, and is returned by the EH (Although that would still require some processing in code to prevent things running per shell fired).

@BIS_fnc_KK Maybe ArtilleryMissionFired could be a variant EH of this, that just execs once per fire mission? Otherwise just having a fire mission counter returned by this EH would be useful too.

RM-51 and RM-70 of the CSLA CDLC seem to not work with this EH. The EH doesn't seem to fire. Only these two vehicles from the CDLC seem affected. I tested vanilla, GM, CSLA, RF/WS artillery units, and they all work except these two.