Mortars Technicals Implementation research

[sh4rkman]

Squad v2 should be out in January according the OWI latest update and will introduce mortars mounted on pickups (or "mortar technicals"). I'm creating this thread to discuss the possibilities and research for an implementation.

After playing with these new toys on the squad testing branch, it looks like it's using same properties on the paper than traditional mortars :

• Min range : 50m
• Max range : 1250m (1230 in reality)

BUT OWI decided that the elevation should be different, and they are not using MIL/Nato MIL :

It look like it's using classic degrees, and the mortar calculator could be ajusted by just skipping the DegToMil conversion but after some test the method RadianToDeg return values a little bit off.
I'm not sure if OWI Screenshot values are off or if they are using a different velocity/property for these mortars :

Distance	OWI Values	RadianToDeg Method
50	83,8	?
100	82,9	87,673
200	80,5	85,33
300	78,0	82,955
400	75,7	80,529
500	73,2	78,031
600	70,5	75,431
700	68,0	72,692
800	65,0	69,759
900	62,0	66,941
1000	58,4	62,877
1100	53,8	58,394
1200	48,2	51,568
1250	40,0	?

Have you played with it yet ? Would you want these implemented ?

[Endebert]

Thanks starting off the discussion and copying the ingame table.

Haven't played with it yet, would definitely be interested to get it into the app.

Most parts are already there:

• The calcMortarSettings script could easily be adjusted to calculate the velocity based off of degrees instead of nato mils: https://github.com/Endebert/squadmc/blob/dev/calcMortarSettings.js
  • even simpler, we could just convert the degrees to nato mils and feed the script with those values
• In PSMC, you can already select between various mortars, so we can reuse that part for Squad

Once we have calculated the velocity for this new mortar, we'll just need to make it available to the user the same way we do it for PostScriptum.

---

Side note regarding calcMortarSettings: I've noticed in recent play sessions that the calculated values are not as accurate as I'd like them to be. I'm guessing that the script tries too hard to align with the ingame tables (by reducing deviation with a brute force method).

But that shouldn't keep anyone from from implementing the above bullet points. Otherwise I'll probably tackle this when v2 comes out and I can test the new mortar in game.

I'll create an issue for this. thanks again for gathering the necessary information!

[sh4rkman]

Side note regarding calcMortarSettings: I've noticed in recent play sessions that the calculated values are not as accurate as I'd like them to be. I'm guessing that the script tries too hard to align with the ingame tables (by reducing deviation with a brute force method).

I'm discovering this part of your code and i'm confused now.

Are you adjusting the mortar velocity when calculating elevation according to the distance ? I'm using the squad velocity (109.890938) whatever the distance is and our calculators have the same elevation values results. (i'm probably missing something)

---

I reinstalled "Squad - Public Testing" and unfortunatly after some testing i have come to the realisation that OWI Table values is perfectly correct. Looks like they gave those mortars a different velocity and not the classic "109.890938".

@300meters, the velocity is 85.02 but it looks like the velocity change the further you shoot.
I'm really confused now, i maybe need to read the mortar wikipedia page again.

[Endebert]

Are you adjusting the mortar velocity when calculating elevation according to the distance ?

No, the initial speed/velocity of the mortar shell should be the same, no matter the angle. That's the whole "thing" about SquadMC: Instead of interpolating between table values, try to estimate the initial shell velocity based on the provided data points/table rows. The benefits are (1) better accuracy and (2) ability to calculate angles for distances outside of table range (so far only relevant for some PostScriptum mortars).

I reinstalled "Squad - Public Testing" and unfortunatly after some testing i have come to the realisation that OWI Table values is perfectly correct. Looks like they gave those mortars a different velocity and not the classic "109.890938".

I would have been surprised if the new mortars would have used the same velocity as the standard ones. So, we'll have to find the velocity for those...

---

Some time later...

Ok, so I've played around with the calculation script, check it out here: https://gist.github.com/Endebert/eddea8ba47a9d75366c0c9658daa2bb2

This is the result

Gathering velocities...
===============================================
50m	83.8° => 47.76901551667287
100m	82.9° => 63.205915416189384
200m	80.5° => 77.59023671857297
300m	78.0° => 85.01920022317464
400m	75.7° => 90.49300565154297
500m	73.2° => 94.09830025288926
600m	70.5° => 96.66132880788781
700m	68.0° => 99.37483515373741
800m	65.0° => 101.16517754823082
900m	62.0° => 103.14476383125053
1000m	58.4° => 104.78232884106704
1100m	53.8° => 106.34559110613415
1200m	48.2° => 108.7830358082141
1250m	40.0° => 111.53015733693007
===============================================
average velocity: 92.89824395915245
maximum distance: 867.24
===============================================
Generating overview...
===============================================
 DIST  T-DEG  | F-DEG |  DEV
--------------|-------|-------
50m	83.8° | 88.4° | -4.57°
100m	82.9° | 86.7° | -3.84°
200m	80.5° | 83.4° | -2.94°
300m	78.0° | 80.0° | -2.04°
400m	75.7° | 76.5° | -0.79°
500m	73.2° | 72.7° | +0.50°
600m	70.5° | 68.5° | +1.97°
700m	68.0° | 63.7° | +4.32°
800m	65.0° | 57.4° | +7.65°
900m	62.0° | XX.X° | +X.XX°
1000m	58.4° | XX.X° | +X.XX°
1100m	53.8° | XX.X° | +X.XX°
1200m	48.2° | XX.X° | +X.XX°
1250m	40.0° | XX.X° | +X.XX°

As you can see, the velocity increases per table row. This leads me to the following conclusion:

Either the ingame table is incorrect/imprecise, or they changed the mortar shell behaviour (e.g. by adding air resistance).

Because you said max range is rather 1230m, for testing purposes, this is how it looks like when forcing the velocity to 110.5:

average velocity: 110.5
maximum distance: 1227.02
===============================================
Generating overview...
===============================================
 DIST  T-DEG  | F-DEG |  DEV
--------------|-------|-------
50m	83.8° | 88.9° | -5.05°
100m	82.9° | 87.7° | -4.80°
200m	80.5° | 85.4° | -4.88°
300m	78.0° | 83.0° | -5.03°
400m	75.7° | 80.6° | -4.94°
500m	73.2° | 78.2° | -4.97°
600m	70.5° | 75.6° | -5.11°
700m	68.0° | 72.9° | -4.91°
800m	65.0° | 70.0° | -5.03°
900m	62.0° | 66.9° | -4.88°
1000m	58.4° | 63.3° | -4.91°
1100m	53.8° | 59.0° | -5.21°
1200m	48.2° | 52.8° | -4.60°
1250m	40.0° | XX.X° | +X.XX°

If possible, could you please compare the calculated angles for 110.5 with the table angles, and let me know which ones are more precise? I'm currently on vacation and can't check myself.

[Artoria2e5]

As additional evidence, the gist now also includes tableDiff.js. It gives:

// range, diff, tech value, mortar value converted
[
  [50, 5.018718241608994, 83.8, 88.81871824160899],
  [100, 4.737468663981517, 82.9, 87.63746866398152],
  [200, 4.83121948861357, 80.5, 85.33121948861357],
  [300, 4.9687203333586325, 78, 82.96872033335863],
  [400, 4.793721218329637, 75.7, 80.49372121832964],
  [500, 4.818722103300615, 73.2, 78.01872210330062],
  [600, 4.93122302849757, 70.5, 75.43122302849757],
  [700, 4.674974014033452, 68, 72.67497401403345],
  [800, 4.749975059908266, 65, 69.74997505990827],
  [900, 4.543726206347969, 62, 66.54372620634797],
  [1000, 4.487477513691495, 58.4, 62.88747751369149],
  [1100, 4.643729102616682, 53.8, 58.44372910261668],
  [1200, 3.437481536286924, 48.2, 51.63748153628693],
  [1250, 4.999983909618244, 40, 44.999983909618244],
];

[sh4rkman]

Hey, what if the angle is just wrong by 5 degrees? Basic principles of projectile motion says that max range is reached at 45 degrees, but in the OWI table it looks more like somewhere between 1200-1250.

It definitly could have been right, but from my ingame tests i did months ago the whole OWI table for techmortars is perfectly accurate once ingame. The 1250m in OWI table is the only thing false imo : max distance is around 1233m from memory, and that should be around 45°

[Artoria2e5]

the whole OWI table for techmortars is perfectly accurate once ingame

maybe it's just consistently wrong, from chart to mortar angle measurement 🤔

The 1250m in OWI table is the only thing false imo

yeah, the calcMortarWhatever.js trims off first and last values for exactly this reason. no way both the angle value and the distance value are nicely round.

[sh4rkman]

maybe it's just consistently wrong, from chart to mortar angle measurement

There is definitly something tricky with tech mortar, and same thing goes the hellcanon : different initial velocity are calculated for every distance. Values are so different that calculating an average velocity is pointless.

It could be as you say an error directly coded in the game, or an external factor (air resistance) as Endebert suggested. That being said i don't see OWI bothering coding air resistance, so it can just be some random error.

For now the only solution i found is to stock the ingame angles and distances, and interpolating between then. It's ugly but works

[Artoria2e5]

I did some more investigation about the angle difference, at the same gist in a separate minimzer.js. The useful output was:

"angle diff assuming same vel & height diff 0"
Object {fx: 0.024563313695691077, x: [4.631591796875]}

fx was the root-mean-square difference in radians. It translates to 1.407 degrees, quite good IMO. Although the original RMS wasn't bad: console.log(Math.sqrt(loss_angle_diff([5]))) gives 0.032920069712104004

[Endebert]

Oh, btw just to clarify, this is the function SquadMC calculations are based on: https://en.wikipedia.org/wiki/Projectile_motion#Angle_%CE%B8_required_to_hit_coordinate_(x,_y)

Thanks to the table, each table row gives us range x, and angle θ, with altitude y = 0.

The script solves for v for each row, takes the average, and shows the angle deviation when applying the original function compared to the table row angle.

[sh4rkman]

As you can see, the velocity increases per table row. This leads me to the following conclusion:
Either the ingame table is incorrect/imprecise, or they changed the mortar shell behaviour (e.g. by adding air resistance).

That was my observation too and why i was confused : every other squad mortar (i don't know about PS but i assumed it was the same) use a single velocity, but not this one. But you are surely right it must be a single velocity with air resistance or something else altering the results.

First thing i did was to test if they didn't change the other mortars behaviour : they didn't.
I retested the OWI table angles for the technical mortar and they are very precise.

---

Because you said max range is rather 1230m, for testing purposes, this is how it looks like when forcing the velocity to 110.5
If possible, could you please compare the calculated angles for 110.5 with the table angles, and let me know which ones are more precise?

I wasn't clear : the max distance is around 1230m not because of the mortar velocity but because of the lower angle you can go on these mortars when the vehicule is completly horizontal : 38.3. You can in theory go lower by leaning the vehicule (screenshot below) but it's not recommanded : the car will move at each shot. You can even do direct shots.

Obviously the angles calculated with an average 110.5 velocity are either too short (eg: 170m too short when shooting at 1000m !) or impossible too use (<38.3)

We can either use a different velocity according to the distance based on owi's angle or ask OWI what they changed on the formula.

I've checked wikipedia air resistance formula but it's out of my competences.
https://en.wikipedia.org/wiki/Projectile_motion#Trajectory_of_a_projectile_with_air_resistance

---

For futur reference :

Distance (m)	OWI Values (°)	Velocity
50	83,8	47.76901551667287
100	82,9	63.205915416189384
200	80,5	77.59023671857297
300	78,0	85.01920022317464
400	75,7	90.49300565154297
500	73,2	94.09830025288926
600	70,5	96.66132880788781
700	68,0	99.37483515373741
800	65,0	101.16517754823082
900	62,0	103.14476383125053
1000	58,4	104.78232884106704
1100	53,8	106.34559110613415
1200	48,2	108.7830358082141
1250	40,0	111.53015733693007

[sh4rkman]

A quick but dirty and imprecise solution would be to stock an array with those values and ajust the velocity according to how far you are from the closest value :

var technicals = [
  [50, 47.76901552],
  [100, 63.20591542],
  [200, 77.59023672],
  [300, 85.01920022],
  [400, 90.49300565],
  [500, 94.09830025],
  [600, 96.66132881],
  [700, 99.37483515],
  [800, 101.1651775],
  [900, 103.1447638],
  [1000, 104.7823288],
  [1100, 106.3455911],
  [1200, 108.7830358],
  [1250, 111.5301573]
];

for (i = 0; i < technicals.length; i++) {
        if(distance<technicals[i][0]){
          var h = technicals[i-1][0];
          var H = technicals[i][0];
          var v = technicals[i-1][1];
          var V = technicals[i][1];

          var vel = v + ((distance - h)/(H-h))*(V-v);
          var elevation = getElevation(distance, height, vel);
          break;
        }
}

EG: the distance to shoot is 570m.

• I look at the array and define that i'm between 500 and 600, and i'm at 70% between those two distance.
• The difference between 500m velocity and 600m velocity is 96.66 - 94.09 = 2.57
• 70% of 2.57 is 1.79
• I add 1.79 to the 500m velocity (94.09 + 1.79 = 95.89)
• i call getElevation() with v=95.89

Just tested this fix at several range with my calculator and it's doing the job pretty fine.