[SHOWCASE] Helicopter Aircraft Turbulence

[sebsterbl 78]

Hi all, I really like the basic ArmA helicopter flight model however I never liked how it was so predictable, there is no turbulence or bounciness to the air which I thought was dissapointing.

 

So, I have created a script which uses PhysX forces to randomly jossle aircraft around. It uses boundingBoxReal to calculate the an approximation of the surface area of the aricraft, and uses that alongside the wind and overcast a paramters to generate roughly realistic forces.

The cool thing about PhysX is aircraft already have a mass assigned, and due to inertia larger aircraft are therefore less impacted.

 

This is designed and tested using helicopters, but might work on planes. Give it a go.

 

Features:

• Works with modded aircraft
• Scales based on weather (overcast and windspeed both generate turbulence)
• Larger, heavier aircraft are less impacted due to inertia, however as they have a larger surface area the forces are greater. This means each aircraft handles turbulence slightly different as the surface area/mass ratio is different.
• Generates no network traffic
• Kinda computationally expensive, but shouldn't lag your game to hell.
• Only calculates if player is the pilot.
• Doesn't affect AI pilots (they need the help)

 

Require CBA. To test it out, just use it as an execVM in an object init. "this execVM turbulence.sqf". It won't work if you spawn into the aircraft, you have to get into the aircraft after mission start.

 

Why did I do this? IDK lol.

Any feedback would be appreciated, and if you want to turn this into a mod that applies itself to all PM me.

https://github.com/Seb105/Random-Arma-Scripts/blob/master/aircraft turbulence/turbulence.sqf

 

[pierremgi 4737]

Good idea. I'll test it iff... you remove all CBA things. There is no need for CBA to match the same performance.

[sebsterbl 78]

The reason for using CBA is the waitAndExecute and perFrameHandlers, which remove the need for a while loop with sleeps. A while loop is at the mercy of the scheduler, and would result in inconsistent perfomance for the script, which is constantly running whilst the player is flying. Plus, the event handlers added using CBA persist across saves and can accept parameters.

[pierremgi 4737]

3 hours ago, sebsterbl said:

The reason for using CBA is the waitAndExecute and perFrameHandlers, which remove the need for a while loop with sleeps. A while loop is at the mercy of the scheduler, and would result in inconsistent perfomance for the script, which is constantly running whilst the player is flying. Plus, the event handlers added using CBA persist across saves and can accept parameters.

There is no need for that.

[Wiket 0]

On 11/27/2020 at 8:49 PM, pierremgi said:

There is no need for that.

How are you going to tell him what he needs and does not. This mod is awesome, don't use it if you hate CBA.

[pierremgi 4737]

13 minutes ago, Wiket said:

How are you going to tell him what he needs and does not. This mod is awesome, don't use it if you hate CBA.

Your opinion. First of all, I don't hate CBA. (nowadays people don't make anymore difference between hate and dislike),  I don't use it for my goals, so thanks for your advice but it seems to me useless. And yes, I can bet for same result without CBA. If you want a serious conversation about CBA, the waitAndExecute and the EHs which are OK or not with save system, no problem. We can go deeper than bad/awesome consideration.
 

[Melody_Mike 127]

Well I am definitely curious.

It seems that the script uses a 0.05 tick rate for the physics simulation:

	}, 
	0.05 //Physics update rate.
	,[_FNC_turbulence,_vehicle,_dimensions,_surfaceArea]] call CBA_fnc_addPerFrameHandler;
};

But "vanilla" onEachFrame doesn't seem to allow suspension. Mind you I have thus far completely avoided using it because of everyone's warnings about performance.
How would you get around this?  

[pierremgi 4737]

1 hour ago, Melody_Mike said:

Well I am definitely curious.
 

But "vanilla" onEachFrame doesn't seem to allow suspension. Mind you I have thus far completely avoided using it because of everyone's warnings about performance.
How would you get around this?  

 

For course... on each framed code is not supposed to be scheduled! It's weird to spawn inside each frame!

 

If you want to skip some frames you can add a condition inside your framed code. Condition skips if false. As example:
diag_ticktime mod 2 > 1 (now you have a blinker true/false each second)

or something according to a specific condition:
if (isNil "pass") then { code1 to be run; pass = TRUE};
// code1  will not run anymore on other frames til you decide pass = nil;

That said, you can throw away the holy waitAndExecute in your framed code.
 

NOTE: If you want to pass parameters on framed code, just use the BIS_fnc_addStackedEventHandler:

["noCBA", "onEachFrame", {hintSilent str _this}, [_FNC_turbulence,_vehicle,_dimensions,_surfaceArea]] call BIS_fnc_addStackedEventHandler;

 

Anyway, this turbulence.sqf is not performance friendly. How it works:
You have a "get in" CBA_fnc_addBISEventHandler  , with no real added value compared with the standard BI "getInMan" EH (but let's overlook)...
this EH (CBA or not) call a function with the framed CBA code (CBA_fnc_addPerFrameHandler) (and remove it when player is on foot)

Nothing wrong but:

- in single player, the code is utterly complicated for nuts as you can work on current vehicle player and work as explained above.
- in multiplayer, it's weird because the CBA_fnc_addPerFrameHandler must be applied on each vehicle players!  DON'T!

The good practice is to have a unique framed event handler (for same codes of course, not in absolute).

So, it's far better to treat an array of vehicles inside a framed EH, instead of loading the CPU bark with framed EH * nbr of vehicles.