Ace3: (weather) wind and rain sync should not be a option

[Cuel]

Arma 3 Version: stable
CBA Version: v3.4.0.170627
ACE3 Version: 3.10.2

Mods:

- CBA_A3
- ace

In some recent patch, rain and wind synchronization seems to be done by the engine
Clients will overtime start using the value the server has.

Missions or servers with useAceWeather off needs to turn syncRain and syncWind off. As for syncMisc, it requires some further investigation. Most likely Ace Weather (world data) shouldn't be synchronizing either, only setting the values on the server

This is due to https://github.com/acemod/ACE3/blob/master/addons/weather/functions/fnc_serverController.sqf#L30 using vectorMagnitude on wind, but updateWind and getWind will jump between engines wanted values and ACE_WIND_PARAMS, most likely. On some missions, reasons unknown, the value will eventually get extremely high

On those missions, doing [ace_weather_fnc_serverController, 1] call CBA_fnc_addPerFrameHandler; will increase the wind extremely fast, reaching unplayable values. By default the update timer is 60s, so it can take up to 20 minutes before it gets very high

https://feedback.bistudio.com/T61395
this seems to suggest BI worked on improving weather sync about the same time as the weather module was created

#help chatlog

cuel [12:46]
yea it just feels like it's all connected somehow. wind changes slowly at start, but once serverController has run a couple of times it's very off and extreme winds

[12:46]
and from what i can tell it only happens when useaceweather is off

[12:47]
calling updateaceweather seems to stabilize it

[12:47]
just an observation

silentspike
[12:48]
Yeah I believe you're right

[12:48]
And I triple checked the maths and it's right :stuck_out_tongue:

[12:48]
Forgot my trig for a second there

cuel [12:58]
ok it should be since useAceWeather is off, ACE_WIND_PARAMS is only set in fnc_serverController to current wind
updateWind gets called every sec and uses ACE_wind (from getWind, that uses ACE_WIND_PARAMS) but since serverController uses the current wind it will slowly increase

[12:59]
something something

silentspike
[13:00]
So it's like a mismatch in timing between updating the GVAR and reading it?

cuel [13:00]
yeah something like that. shouldn't the serverController use fnc_getWind instead?

[13:00]
not sure how that plays along with forecast set in eden

silentspike
[13:01]
Would that not just be a feedback loop? Since the server controller is feeding fnc_getWind

[13:03]
My understanding is server controller handles syncing all clients. With useAceWeather off, it just reads the actual wind and sets that as the params. Then on the clients updateWind sets the wind to those params

cuel [13:03]
but the server also runs updateWind

silentspike
[13:04]
Perhaps that's the issue :slightly_smiling_face:

cuel [13:04]
the wind is constant at mission start until the first serverController fires, that's when it starts jumping in small values

[13:04]
and eventually it'll reach high values because of the jumping

silentspike
[13:05]
I can see no need to run updateWind on the server unless useAceWeather is active

cuel [13:05]
but will it update along with the forecast then?

silentspike
[13:06]
You mean the mission forecast thing?

cuel [13:06]
yeah

[13:06]
or is that ignored now even

silentspike
[13:06]
I think that is overridden by useAceWeather, so it all hinges on that setting

[13:07]
If that setting is on, the server will need updateWind so that ace weather is applied. If not, then the server is just syncing the engine value to all clients

cuel [13:07]
i'll do some tests

silentspike
[13:08]
I think maybe there's some sort of feedback loop between it reading the engine value and then re-applying it on the server again

[13:09]
Have wanted to squash this bug for a while, good to have another pair of eyes on it :slightly_smiling_face:

silentspike
[13:15]
If what I think is true is true, I'd just add if !(isServer) around lines 21+22 of updateWind to fix it

cuel [13:16]
aye

[13:16]
i'll check it on a dedi

silentspike
[13:18]
It also kind of makes sense why disabling automatic engine whether usually fixes it but not always

[13:18]
I think it's reading the value at mission start then constantly resetting that value, but fluctuating between that and the engine value applied by the forecast/auto weather

cuel [13:21]
oh yeah

cuel [13:48]
it seems to work

it's jumping between these values
[0,0.147803,0]
[1.16967e-008,0.133795,0]

and i guess that's when ace_weather is fighting vanilla weather?

[13:49]
it matches ace_wind_params

silentspike
[13:53]
It jumps with the !isServer added?

[13:53]
Or it works with that?

cuel [13:55]
it doesn't increase in an extreme matter but it's still behaves odd. it's jumping between ace_wind_params values and something else (vanilla?) (edited)

silentspike
[13:56]
:smile: It's a start I suppose

cuel [13:58]
is the servercontroller even needed anymore? when useAceWeather is off?
NOTE: The effect is global only if command is executed on the server. Wind set locally will sync back to server value in a while. (edited)

silentspike
[13:59]
I wasn't involved with ace when weather was made, but supposedly there's desync between server and clients

cuel [14:00]
actually yeah one of the values it's hopping between seems to match the server's wind (edited)

silentspike
[14:00]
Personally I just disable it because who cares unless you're doing super long range shots :stuck_out_tongue:

[14:01]
I feel like maybe it's just an intrinsic problem with trying to force weather sync non-engine side

cuel [14:01]
yeah, vanilla weather sync was probably broken earlier but fixed lately (edited)

silentspike
[14:02]
Wouldn't be against considering the removal of syncing but keeping the custom weather stuff

cuel [14:09]
yeah seems like at least rain and wind sync needs to go

[14:09]
uncertain about lightnings gusts and waves

[14:09]
biki doesn't say

cuel [15:13]
i'll make an issue, not entirely sure what works or not or what the rewrite would include

[commy2]

not sure if i should post the chat log

Do it with spoiler tags.

chat log

blah blah

---

<details>
<summary>chat log</summary>

text here!!!

</details>

[Cuel]

Added to 1st post

[Cuel]

After doing some testing with CBA target debugging on a dedicated server, these are my findings. If someone could confirm the same that would be great 👍

These findings were done with only CBA enabled

10 setOvercast 1; (server exec)
Works on server, client does not synchronize. Using forceWeatherChange will synchronize overcast, but will make the transition instant and ignore given delay. simulWeatherSync will make the client go in the "right direction", but the transition is extremely slow. 0.001 change every second. setOvercast has no effect on clients.

0 setFog 1; (server exec)
Works on server, client will not sync. simulWeatherSync has no effect, forceWeatherChange will make the client jump to the value, but it will return to the client's old value. Using 0 setFog X on the client it will return to previous value. Perhaps this is related to something else? The command doesn't have any effect on the client when a delay is introduced. The command behaves extremely weird.

Using the extended version with fogValue, fogDecay, fogBase, and 0 delay, the value synchronizes when used with forceWeatherChange, the value still seems to return on the client after being set. All in all setFog seems completely broken.

Edit: just tried 10 setfog [0,0,0] and the client did indeed synchronize. setFog requires further investigation.

10 setGusts 1; (server exec)
Client does not sync. forceWeatherChange/simulWeatherSync has no effect.

10 setWaves 1; (server exec)
Client does not sync. forceWeatherChange/simulWeatherSync has no effect.

10 setRainbow 1; (server exec)
Client does not sync. forceWeatherChange/simulWeatherSync has no effect.

10 setRain 1 (server exec)
Client syncs

10 setLightnings 1 (server exec)
Client syncs

setWind [1, 1, true] (server exec)
Client syncs.

Summary:
Wind, rain and lightnings are synchronized. Overcast requires forceWeaterChange (instant change) or simulWeatherSync (very slow change - but it'll move in the right direction). Fog is very special and will sometimes reset the old value on clients, sometimes not. Requires further investigation

Executive summary: weather is a mess

[commy2]

Executive summary: weather is a mess

We knew this already.

[kymckay]

So are we in favour of gutting out the rain/wind/lighting stuff? Also, did you test waves at all? The wind sync stuff sets those too.

[Cuel]

Yes.

10 setWaves 1; (server exec)
Client does not sync. forceWeatherChange/simulWeatherSync has no effect.

[kymckay]

Sorry, I missed that!

Add my vote in favour of removing the sync code for rain/wind/lightning. We can move the wave sync to either it's own setting or misc or something

[kymckay]

Though, I suppose it raises the question of: Does running those commands on clients even sync them with the server like ace weather seems to expect?

[Cuel]

Not sure what you mean, but what I saw was that they were 100% local based on class Intel from mission.sqm and didn't care what the server had

[kymckay]

I suppose I'm asking whether they work on clients at all, as I understand it ace weather is running those commands repeatedly on clients and I'm questioning whether it's even worth doing that. Furthermore, do we even care if waves/rainbow/gusts aren't synced?

[commy2]

gusts maybe. Never seen a rainbow in an actual mission. Or thought about the waves, although those could heavily influence boats I guess.

[Cuel]

Don't we need an issue for the todo on fog?

[bux]

@Cuel yes please

[jonpas]

Yes. And also it would be great if someone would test completely vanilla sync (without using any commands, even server-side).