Fix helicopter rotor collides at twice the rotor diameter

[olanti-p]

Summary

SUMMARY: Bugfixes "Fix helicopter rotor collides at twice the rotor diameter"

Purpose of change

Fixes #39474

Describe the solution

Divide by 2

Testing

Spawned a helicopter with rotor diameter 8 and placed a wall 5 tiles away.

Ascended, then descended. The helicopter lands safely with this fix but crashes without it.

[kevingranade]

Round up please, integer division implicitly floors.

[olanti-p]

It should be floored, shouldn't it? If D=9, you count 4.5 tiles from the center of the rotor and have the same situation as in the pic

[olanti-p]

Sorry for a lack of response, I was sleeping.
Flooring was not a division error, it was intentional.

Let's say D = 2K or D = 2K + 1. Then K = floor(D/2.0). g->m.points_in_radius(R) returns an iterator over a (2R+1)x(2R+1) area. If we pass it K, we get an iterator over DxD for D = 2K + 1 and (D+1)x(D+1) for D = 2K. Example values:
D=1 ..... area=1x1
D=2 ..... area=3x3
D=3 ..... area=3x3
D=4 ..... area=5x5
D=5 ..... area=5x5

Let's say D = 2K + 1. We round it up: L = round(D/2.0) = K + 1. Then we pass L to the function and receive an iterator over (2*(K+1)+1)x(2*(K+1)+1), i.e. (D+2)x(D+2). Example values:
D=1 ..... area=3x3
D=2 ..... area=3x3
D=3 ..... area=5x5
D=4 ..... area=5x5
D=5 ..... area=7x7

For a rotor with D=5 to have a collision area of 7x7 would be unexpected for the players.

[ZhilkinSerg]

Let's change rotor diameter to blade length maybe? It would be g->m.points_in_radius( dsp, blade_length ) (i.e. blade_length * 2 + 1) then.

[jbytheway]

If division by two really is intended, suggest using divide_round_up rather than floating-point arithmetic here.

[olanti-p]

Sounds good to me. The lift thrust calculation can be easily adapted to use blade length too. I can make it a PR. Does it include changing diameter to blade length in json too?

[kevingranade]

Flooring was not a division error, it was intentional.

I understand, I just disagree.
When rotor diameter exceeds 1m (it always will), it necessarally enters tiles adjacent to it's origin. In order for that to happen when D = 1.1, R = f( D ) must be greater than 1.
From there, as D increases, R obviously increases at half the rate of D.
Given these invariants, the most straightforward definition of R is ceil( D / 2 ).

From a balance point of view, anything we do here is incredibly generous, from what I've read about helipad layout, minimum safe landing zone footprint is 2D. It is very likely that we will add up to several tiles of horizontal jitter when ascending and descending to represent this. Because of this, I'm not particularly concerned about the, "players will be surprised that they can't land in a tiny area" issue, because that is a fundamentally unsafe thing to do. If you want to alleviate the surprise factor there, we can look into emitting a, "minimum safe distance" number, but that number should be significantly larger than the physical rotor footprint.

[olanti-p]

So it basically adds 0.5-1 tile to real radius as a penalty for tiny jitter? Can't argue that. Should be mentioned somewhere in the code probably.

If you want to alleviate the surprise factor there

No, it's fine. It was more of a "this code produces wrong R for given D since helicopters are absolutely still" issue. When (if) the jitter is added, the surprise factor will no longer be there since helicopters would be visibly affected by jitter/wind.