Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[TTC Redfield]

Perfect for the correction 

i had fun with options WakeTurbScaler 

[TXZCJSP]

I found a new problem.
In an online game, when I set UseWakeTurbulence=1.
the AI appears to be "drifting" in the eyes of others, and the larger the group of AI planes, the worse the phenomenon becomes. 

The AI planes get out of sync, then immediately get synced back to their normal position, and continue to do so.

When I set UseWakeTurbulence=0, the AI behaves normally.
Is it possible to release another patch so that UseWakeTurbulence=1 only affects players?
The effect of gusts on the AI remains the same.

[WxTech]

Hmmm... Interesting how a systematic offset would be induced over time with the wake turbulence on AI planes.  I'll add an additional control so that one can individually enable wake turbulence for player and AI.

How's the 'regular' turbulence and gust behaviour? Has anyone explored the full range? Any preferences?

[TXZCJSP]

The old version of turbulence had no problems with multiplayer (it was integrated into BAT).
With the new version, as I said, with WakeTurbulence=1, there is a "drift" in multiplayer.
WakeTurbulence=0 and it behaves normally.（Well, it's not. It's just that there are so few planes, it's not obvious.）

I'm guessing that when wake turbulence is enabled, the amount of data exceeds the efficiency of the game's data transfer, causing this phenomenon?

After all, I once created a mission to intercept a B17 formation with over 150 planes.
The "drift" phenomenon also occurs in online play, although not as much as now.

[TXZCJSP]

I tested it carefully.
I've been running the same map script in single player mode, and with all features enabled (turbulence, gusts and wake turbulence) the average fps is 8-12 fps lower than without.
So far it seems that the over-calculation is really affecting the game performance, even though there is no "drift".

Then my friends and I played a multiplayer bomber escort mission (64 B17s).
With UseWakeTurbulence=0, there was a slight "drift" of the P51s circling overhead.
When UseWakeTurbulence=1, the "drift" is greatly increased.

It seems that IL-2 1946 set the AI to be independent of turbulence and gusts for a reason.
Excessive computation leads to lower fps, increased CPU load, and drift/unsynchronization in multiplayer.

Drift and desynchronization become more pronounced with more planes.
If you want to play multiplayer, removing the effect on the AI seems to be a no-brainer.
In single player, as long as the CPU is strong enough, it's not a big deal to have all the features on, except for the FPS drop.

Looks like I'll have to compromise for online play
Simply divide it into two parts:
1. Turn on the effect on the AI for single-player games.
2. Turn off the effect on the AI for online games.

Or a simpler approach
1 copy for AI affected 2nd copy for AI unaffected
For single player, take the first copy.
Second copy for multiplayer

[WxTech]

I've released an update; same download link in the top post.

The only change is the separating of player and AI planes where the enabling of wake turbulence is concerned. Formerly AI planes were included with the player's plane for calculation and execution. Now you can have this turbulence active for:
- player only,
- AI only, or
- player and AI.

I debated offering two different versions but settled on just the one, in which you can separately enable/disable wake turbulence for player and AI planes separately.

[TXZCJSP]

I've released an update; same download link in the top post.

The only change is the separating of player and AI planes where the enabling of wake turbulence is concerned. Formerly AI planes were included with the player's plane for calculation and execution. Now you can have this turbulence active for:
- player only,
- AI only, or
- player and AI.

I debated offering two different versions but settled on just the one, in which you can separately enable/disable wake turbulence for player and AI planes separately.

Could you please add an AI switch for gust effects?
It's not much of a problem in general, but the "drift" is still noticeable in large-scale combat situations like intercepting bomber swarms.
The drift of AI P51 escorting bombers is a big headache for players.

Like I said, I compromised.
Enjoying full functionality can only be done in single player

[WxTech]

Here's something I've not noticed before, not having examined formation behaviour in detail. With a fairly strong wind speed set in the mission (15m/s is the max permissible, and increases with altitude), planes in a formation cannot remain on station with respect to the flight leader when flying in a direction more or less perpendicular to the wind direction. If, for example, I set the wind to be from 90 degrees, a flight flying north or south will have flight elements shifted downwind, or to the west. The faster the wind, the greater this offset. But it does not continue to get worse over any significant duration; once a certain offset is established, it is maintained, until the altitude and hence wind speed changes significantly enough.

I've been trying this with and without gusts enabled for any planes, and the same behaviour just described is exhibited.



I'll note that the gust algorithm employs vector scaling of the added wind velocity and gust velocity. As in:

  vector3d.scale(windVelocity(f1) + (double) gust_vel);

I've tried the same approach for AI turbulence, it resulting in rather less 'jittery' bouncing.

The original application of turbulence employs vector addition of the individual X, Y and Z vectors, as in:

  vector3d.add((double) TrueRandom.nextGaussian(f4, 0.0), (double) TrueRandom.nextGaussian(f4, 0.0), (double) TrueRandom.nextGaussian(f4, 0.0));


Examination and experimentation continues!   

[TXZCJSP]

It's possible that the machine translation may have been skewed, and I'm trying to be as detailed as possible.

In my opinion, there's no "drift" in single player.
The AI is trying to make constant corrections to maintain formation, and it looks more like it's fighting gusts/turbulence.
It doesn't have any effect other than a drop in FPS.

The only problem is in multiplayer, where it causes the AI to "drift" as observed by everyone except the room builder (and even between players).
Just like in multiplayer games where the data is not synchronized in time, the AI will go off course and then immediately be pulled back to the correct position.
This phenomenon is especially noticeable in large-scale combat behavior, for example, if a player is chasing an AI fighter, and the AI engages in evasive behavior, the player will see the AI being pulled back to the correct position (which occurs once every 1 to 10 seconds, depending on the size of the engagement).

If the battle is very small, like 20 planes on the map, the "drift" rarely occurs.
I don't know if it's because the amount of data being sent/received is reaching its upper limit, and then there's a lot of desynchronization/pulling of planes back to their correct positions.

Incidentally, when the battle size is too large (e.g. 30 fighters intercepting 150 bombers) even without using gust/turbulence/wake turbulence, there will be "drift" in the eyes of the people who join the game room.

Maybe the problem is in the multiplayer data synchronization, or maybe it's just too much data for the game itself to handle in time?
After all, it's like playing a first-person online shooter with 450ms latency, where everything keeps drifting, and then the server pulls them back into place, but the players who created the room feel like they're playing a single-player game with no problems at all. All of the people experiencing the "drift" were players who had joined the room.

[TXZCJSP]

I've uploaded two videos sent to me by players who participated in my multiplayer game.
This explains it in more detail

[WxTech]

I'm continuing to expand on the options. These are the current controls I expect to include in the next release, at least for WIP testing purposes. I don't fly online or on a network, and so cannot test this aspect.

  AITurbMethod=0  //0 for NONE, 1 for vector addition (original, but jittery), 2 for vector scaling (better, but limited)
  UseWakeTurbulencePlayer=1  //0 or 1, for disabled or enabled
  UseWakeTurbulenceAI=1  //0 or 1, for disabled or enabled
  WakeTurbulenceScaler=0.67 //values between 0 to 2 permissible; 1 is the reference

The first is the new one, controlling how to handle AI turbulence. The 3 options:
- 0: Calculate NO mechanical/cloud turbulence for AI, leaving wake turbulence as its own dedicated control, as before.
- 1: Calculate mechanical/cloud turb as originally done, via vector addition of the individual XYZ vector components. (This method suffers a high-frequency, 'jittery' behaviour.
- 2: Calculate mechanical/cloud turb via vector scaling, adding a speed value to the underlying wind speed. (This method is better behaved, although currently it is limited to application of impulses parallel to the direction of the underlying wind vector; I will look into application in 3 dimensions.)


I've already been aware of the gust implementation causing a less than agreeable behaviour. Because the impulses are always aligned with the wind vector, the effect on the plane is as follows. When flying in a direction more perpendicular to the wind, the gusts impart a yaw moment, leading to a momentary swing in azimuth. When flying largely into or against the wind, no discernible or notable effect is seen; neither a pitch-up/down nor a rising/sinking. Perhaps in part because the impulses are fairly brief; although the evident yaw swings argue against this.

I'm leaning toward going back to ignoring gust type behaviour, restricting to turbulence. But this would necessitate the treatment for AI being further tuned.


Interestingly, when bypassing any turbulence for AI, any planes in one's own flight for which he is the leader are nonetheless having turbulence applied. If you're in position 1 of a flight of 4, planes 2, 3 and 4 do have turbulence calculated. I have yet to see what happens when the player is not the leader...

[WxTech]

Still pecking away at this. Making for three solid days of tweaking and testing so far. 

I'm cooking up a 'full control' Wind.class, which I'll release soon...

- I've decided to go back to my former, and fairly longstanding, policy of ignoring gusts. The ONLY time the gust value is considered is when gust > 0 AND turbulence = 0. (This should not be a common situation, but in the eventuality of such, where some turbulent action is assumed as intended by the mission maker, I will enable turbulence.) In such case, I use the gust value as a stand-in for turbulence. Where gusts scale 0-12 and turbulence scales 0-6, I halve the gust value so that it scales the same as turbulence. For instance, if the mission's gust = 6 (out of 12) and turbulence = 0 (out of 6), the code essentially makes this as turbulence = 3 (out of 6) and gust = 0.

- If you have the "Wind'nTurbulence" difficulty option enabled, you can now have the wind be active, but have turbulence disabled--for one or both of player and AI. If a mission has strong turbulence/gusts set, and you don't like that, but do like to have a wind be in effect, now you can enjoy that aspect you desire without having to suffer 'the full Monty' (and not have to edit the mission.)

- Turbulence is individually controllable for player and AI; one or the other or both can be enabled.

- Wake turbulence is individually controllable for player and AI; one or the other or both can be enabled.

- I've created a new algorithm for AI turbulence, and keep the old one available; you can select NONE, the EARLY (more 'jittery') method or the LATER (less 'jittery') method.

- I've done some more renaming of the controls.

The conf.ini controls:

TurbulencePlayer=0  //0 or 1 for disabled or enabled (mechanical and cloud components)
TurbulenceAI=0  //0 for NONE, 1 for first method (jittery), 2 for second method (less jittery)
WakeTurbulencePlayer=0  //0 or 1, for disabled or enabled
WakeTurbulenceAI=0  //0 or 1, for disabled or enabled
WakeTurbulenceScaler=0.67 //values between 0 to 2 permissible; 1 is the reference


Some more notes:

The stock class has no turbulence or gusts ever enabled for AI. Only the steady application of the wind is. For the player, in the stock class there is a mix of vector3d.add and vector3d.scale at work when gusts/turbulence are at work. Vector3d.scale is always in operation for the application of the wind. My turbulence code, of all causes, employs vector3d.add. (the basic vector3d.scale still operates for the base wind.)

In mulling over the 'drift' reported for online play, I recall similar oddities when playing back ntrk recordings where the wind was active in which there were occasional VERY significant jumps made by planes. I presume that a similar limitation is at the root of what's going on in both situations. That being the discordance that must result between vector additions performed at the sending end or during a recording and what the receiving end is also doing or is additionally calculating during playback. It seems to me that for online play and track recording it might be wise to at least have turbulence of all types disabled. Because the turbulence algorithms utilize randomization, which can only be expected to lead to divergence, or 'drift' when such calculations are executed again 'on top of' already executed calculations.

Now, if the server or host in an online session is the only source of turbulence calculations, doling out the packets of resulting positional adjustments, concerns about 'drift' should be lessened, I would think.    I don't know how this is actually conducted.