Artillery Radar Script Release 0.3

[ofp_f3d3 28]

Hi everyone, long time forum lurker.

This is my first script to be released and i hope it won´t be the last.

 

This script was and idea that came to my mind when a wrong click on a zeus mission sent a full 82mm mortar barrage on a squad. Thats when i came with the idea, even if it isnt completly realistic, of creating something that would give the players some time to react by displaying a small marker on the map to warn them of a possible round coming down on the area.

 

I dont use any kind of eventhandlers, and if im not mistaken, all the calculations are run server-side. The script only works for mortars and artillery as easier to predict its target, where mlrs or rocket propelled rounds have an engine providing acceleration. (i might try to get them to work in the future)

 

Radar Script 0.3

 

Hope you enjoy it, and if suggestions or ideas come up, write them down and if its in my skill range, ill try my best to add them.

 

Future ideas:

-Remove markers after hit.

-Predict launch position after X rounds fired from around the same area.

 

Released under APL-SA

 

CHANGELOG:

 

Version 0.3

 

#Changed

-Fixed bug where markers wouldnt delete because of being stored the wrong way.

-More optimizations were made.

-Tested in Dedicated server and LAN. No script errors and no FPS drops while running. (Set at 5000m range and 6 second interval). Tested with 16 simultaneous players in VeteranMod.

I can safely say that this boi saved lots of lives that day, exactly the purpose i built it for.

 

 

 

Version 0.2

#Added
-Radar_MrkR --- Its job is to mark the radar´s position and its range so its visible to everyone in the side of the radar.

 

#Changed
-All markers (Radar pos and range, and prediction markers) now only show to the side the radar belong to,making
this viable for PVP. Markers are created globally but its alpha is set to 0 and only changed to 1 by remoteexec.
-Several optimizations marked by sarogahtyp

 

 

 

Version 0.1 BETA
#Added
-Added a floor height for the radar to detect rounds to simulate blind-zones too close to the radar.(Default Radar Pos ASL + 500m)
-Added death range. This value shows the "sure range" of death around the round´s impact. If you are within this range, you die. THANKS sarogahtyp for showing me how to check class configs
-Added filter to only predict artillery rounds and avoid tank shells or anything else - AGAIN THANKS sarogahtyp for the code
-Markers are now stored and deleted in order when rounds impact

 

#Changed
-As artillery radars cant locate a single round, the threshold for detection has been increased from "> 0" to "> 2".
-Position of the round was changed from getposATL to getposASL, this showed improved precision.
-The radius of the marker now corresponds with the indirectHitRange X 5

 

#Removed
-Replaced Radar_Alcance for Radar_CalcImpact.sqf by sarogahtyp

 

Version 0 Release

[stanhope 411]

Just a quick tip: it's best to include a license in anything you make.  It makes things so much more simple for everyone.  Bohemia offers a nice flowchart here if you don't know where to start on choosing a license. 

[ofp_f3d3 28]

Quote

Just a quick tip: it's best to include a license in anything you make.  It makes things so much more simple for everyone.  Bohemia offers a nice flowchart here if you don't know where to start on choosing a license. 

Thank you, i didn´t know that i had to include that.

 

Also, this was tested in SP/MP, dedicated (too be checked extensively)

[stanhope 411]

You don't really have to, it's just best to do it. 

[sarogahtyp 1108]

I didn't look at your script but sometime ago I tried to simulate rocket flight in this thread, maybe it helps.

 

EDIT: full script (predict target position on impact) can be found here.

[ofp_f3d3 28]

Quote

I didn't look at your script but sometime ago I tried to simulate rocket flight in this thread, maybe it helps.

 

EDIT: full script (predict target position on impact) can be found here.

 

Both are amazing. The thing is that i didn´t want to know anything about the shooter or the target. Thats why i try to catch and detect the round mid-air and run any kind of predictions there. I´ll try to come up with solutions for both of the future ideas and any other quality-of-life improvements people can suggest.

 

 

[sarogahtyp 1108]

I think the important thing for self-propelled devices is that thrust in CfgAmmo is equal to acceleration and that air friction is different calculated on self-propelled rockets.

I modified the entries in the wiki some time ago. So you should be able to solve your calculation for self-propelled devices with those entries:

https://community.bistudio.com/wiki/CfgAmmo_Config_Reference#airFriction

https://community.bistudio.com/wiki/CfgAmmo_Config_Reference#thrust

 

EDIT: it would be nice if u could post ur script in a spoiler. I can't open archives at work :-)

[ofp_f3d3 28]

Quote

EDIT: it would be nice if u could post ur script in a spoiler. I can't open archives at work :-)

Done 👍

[Eroge 3]

Very interesting script... but I can't get it to work! I did exactly what you wrote in readme, and I didn't hear the sirena for the whole time. I could really use a video tutorial

[ofp_f3d3 28]

10 minutes ago, Eroge said:

Very interesting script... but I can't get it to work! I did exactly what you wrote in readme, and I didn't hear the sirena for the whole time. I could really use a video tutorial

 

Instead of just the script, i uploaded a test mission that is currently working to test it yourself.

 

 

[sarogahtyp 1108]

I do not understand ur entire script but I guess you don't take air friction into account. Therefore it should not be very precise. You could improve your calculations with air friction which you could get with this line for a given _shell_object:

_air_friction = getNumber(configFile >> "CfgAmmo" >> (typeOf _shell_object) >> "airFriction");

 

Also you can get the thrust (acceleration) of a rocket this way:

_thrust = getNumber(configFile >> "CfgAmmo" >> (typeOf _shell_object) >> "thrust");

With those links I provided above (CfgAmmo Config Reference) you should be able to take air friction into account and solve your problem with rockets.

 

EDIT:

I guess you need max_speed as well for rockets:

_max_speed = getNumber(configFile >> "CfgAmmo" >> (typeOf _shell_object) >> "maxSpeed");

 

[ofp_f3d3 28]

Quote

I do not understand ur entire script but I guess you don't take air friction into account. Therefore it should not be very precise. You could improve your calculations with air friction which you could get with this line for a given _shell_object

 

I tried to keep it simple first, and now with the base working properly i can start adding more controls for better predictions.

 

With the code you gave me, be sure i´ll try to get the friction into account and i´ll add the mlrs stuff down the road.

[ofp_f3d3 28]

I found that mk-6 mortar rounds and some 155mm rounds have "airfriction"=0.

 

I´m having issues finding or coming up with a formula for the max range of a round. I know i´ll find one in the end 😑

 

EDIT: Found a formula 😁 ((2*b)/(3*v0*cosθ))R2+R−R0=0 , now i have to calculate the 2 solutions for the formula and im good to go

[sarogahtyp 1108]

According to airFriction entry of the config reference:

Quote

If the ammo class has artilleryLock = 1 set, the config value for airfriction gets ignored and airfriction=0 is assumed ingame.

 

This brought me to a config file I didn't know bout before:

https://community.bistudio.com/wiki/Arma_3_Targeting_config_reference#artilleryLock

 

I don't know how to get that ArtilleryLock value correctly but you could try:

_arty_lock = getNumber(configFile >> "CfgAmmo" >> (typeOf _shell_object) >> "artilleryLock");

But you just could test for _air_friction == 0 instead of crawling that artilleryLock value.

 

What do you need max range for?

[ofp_f3d3 28]

Quote

What do you need max range for?

 

I have the direction of the round. If i get the range, i can find and mark on the map an aproximate position to warn players about incoming rounds.

But now i saw that the formula i found doesnt take into account that initial height wont be zero, as i catch the round midair.

 

EDIT:

 

Quote

But you just could test for _air_friction == 0 instead of crawling that artilleryLock value.

 

now thats a thing. Using that i can FINALLY stop tracking rounds that don´t correspond, like a fricking tank shooting at 70°. If i check for that artillerylock i can find actual artillery rounds.

 

you fixed a headache indirectly 😀

[sarogahtyp 1108]

13 minutes ago, ofp_f3d3 said:

 

I have the direction of the round. If i get the range, i can find and mark on the map an aproximate position to warn players about incoming rounds.

 

 

But I thought this is what your script is doing actually? I'm confused

[ofp_f3d3 28]

9 minutes ago, sarogahtyp said:

 

But I thought this is what your script is doing actually? I'm confused

My script every X time scans for artillery rounds. If a round is found, i obtain its direction and speed, and with that (not considering friction) i can get an aproximate range. With that range, and direction i get the relative position from the round and can find a good aproximation of the point of impact. And when i have that point, i mark it to notify players.

 

I hope this explains the script better than i did before.

[Eroge 3]

10 hours ago, ofp_f3d3 said:

My script every X time scans for artillery rounds. If a round is found, i obtain its direction and speed, and with that (not considering friction) i can get an aproximate range. With that range, and direction i get the relative position from the round and can find a good aproximation of the point of impact. And when i have that point, i mark it to notify players.

 

I hope this explains the script better than i did before.

 

 

I tried that mission, but when the mortar shells incoming I only got hint instead of siren...

[ofp_f3d3 28]

5 minutes ago, Eroge said:

 

 

I tried that mission, but when the mortar shells incoming I only got hint instead of siren...

Just downloaded it. The hint you see is the estimated distance of the round to the target, check the map and you´ll see red border markers around the predicted area. Give the mortar a fire mission and check it.

If it still doesnt work just tell me and ill try to fix it.

[ofp_f3d3 28]

Quick question @sarogahtyp

 

Quote

 

The function appears to work in two dimensions, and as such can be used to find the position of a target relative to the player if bearing and distance are known. However, if there is a significant change in elevation between yourself and the target, the distance registered on a ragefinder (which is measuring a 3 dimensional straight line) will always be larger than the two-dimensional value required for BIS_fnc_relPos and as such air-strikes and ordnance called in using such a function can miss by several hundred metres in extreme cases. Currently searching for a method which incorporates the azimuth of the rangefinder in calculation.

 

Thats in the documentation for BIS_fnc_relPos and is almost certainly the cause that my predictions are missing by 100 or so meters, have you found a solution for it anywhere or even a mathematical way to correct it? I´ve been searching and optimizing the script but this still bugs me.

[sarogahtyp 1108]

Not yet but I think u should use the alternative syntax of getPos cause it does the same and one should use the engine command if available (getPos in this case) instead of that BIS function.

 

Later on Ill look for a solution of your 3D problem.

[Grumpy Old Man 3546]

You could track arty guns via fired eventhandler, check if projectiles enter your radar range and display them and/or add precision errors to your flavor.

No need to use expensive calculations when you can track what's already there, even more so when the player won't be able to tell the difference.

 

Cheers

[sarogahtyp 1108]

34 minutes ago, Grumpy Old Man said:

You could track arty guns via fired eventhandler, check if projectiles enter your radar range and display them and/or add precision errors to your flavor.

No need to use expensive calculations when you can track what's already there, even more so when the player won't be able to tell the difference.

 

Cheers

the difference is that players would see the impact point when shell enters radar range and not just see a realtime marker of the shell.

[sarogahtyp 1108]

4 hours ago, ofp_f3d3 said:

Quick question @sarogahtyp

 

 

Thats in the documentation for BIS_fnc_relPos and is almost certainly the cause that my predictions are missing by 100 or so meters, have you found a solution for it anywhere or even a mathematical way to correct it? I´ve been searching and optimizing the script but this still bugs me.

 

I think you have no chance to calculate the impact point without simulating (or do some iterations of calculation) the flight instead of calculating with those simple physics formula. The reason is that you don't know the height of the terrain on impact point before calculation. Also there could be a mountain along the flight path of the shell and it would just impact in the mountain instead of flying a few kilometers more.

[Grumpy Old Man 3546]

2 hours ago, sarogahtyp said:

the difference is that players would see the impact point when shell enters radar range and not just see a realtime marker of the shell.

Well since most artillery requires a player to command the fire it should be no problem to retrieve the target area via mapClick or other means and add wanted imprecision to those coordinates to display a marker.

 

Cheers