As expected we now have support calls incoming because of this issue! Please be aware, this also affects ZEUS: https://forums.bistudio.com/forums/topic/202806-eden-editor-64bit-update-bug/

This bug has been cherry picked to RC and is now on way to LIVE...

Added Screen Resolution

Updated repro steps and description for clarity

Issue still present in current perf binaries! But I found that the above specifically happens with interface-size set to "small"! With interface-size "normal" it breaks on the 4th option slot.....

PS: To illustrate the problem with the current implementation here the link to KKs "guide to locality": http://killzonekid.com/arma-scripting-tutorials-locality/

adding a custom function, PVC, PVS and PVEHs only to allow the server to add fuel to a vehicle...

corrected error in title

This isn't isolated to ALiVE as the author says, it happens when spawning several groups during mission runtime. It eventually gives a stutter on unit creation!

Heya Ice!

I believe its not working as intended (sorry)! Groups switched to another locality, won't accept move/domove commands from a different locality (esp. server).

Execute globally in debug console
headless is the name for HC

• spawn {

if (local player) then {POS = getpos player; publicvariable "POS"};

if (isServer) then {
TESTGROUPSERVER = [POS, WEST, (configfile >> "CfgGroups" >> "West" >> "BLU_F" >> "Infantry" >> "BUS_InfSquad")] call BIS_fnc_spawnGroup;

TESTGROUPSERVER setGroupOwner (owner headLess);

waituntil {!local (leader TESTGROUPSERVER)};

TESTGROUPSERVER move (getArray(configFile >> "CfgWorlds" >> worldName >> "centerPosition"));

PublicVariable "TESTGROUPSERVER";
};

};

// wont move the unit...

also tested with different positions.
Group is created at player pos, but wont move at all...

The unit is funnily even calling out "MOVE TO blah"... but isnt moving at all!

it seems to be working with waypoints, but not with move/domove

Hi!

Thanks! Thats awesome!

Just a question -> brain/state from server to a different locality, i guess?
And will it work for groups that have been created on a different locality too (ergo call command serverside on any group to have full control)?

Thanks for your work!

forgot one bit in test

added simple repro mission, with 3 tests:

• AI creation on server, changing owner to client, executing domove (not working)
• AI creation on server, not changing owner, executing domove (working)
• AI creation on client, not changing owner, executing domove (working)

Fixed again in Steam Dev rev. 127800 and higher.

PS: You also fixed ZEUS #adminLogged with it ;)
http://feedback.arma3.com/view.php?id=21163

Thank you, working again in DEV! If there is an alternative (and usable) method for admin-checks/actions im sure serverCommand/Available can be removed fully. Thanks again! And I would really appreciate if deploy an hotfix so this gets to stable.

yeah i figured out that much, putting a loop/EH on a player that gets setvariabled each frame or each userInput :)

Happy it works in your case, Tyrghen! I will share anything for the situation in here, as soon as I find it!

Whereas this code can be used to hint/print if a servercommand is available when simulation runs, or a button is pressed it cannot be used in a regular function, that just checks the adminstate... The first also throws all kind of deserialization errors if wrapped in a function or called in debug console on dedi.

Also when trying to use that code snippet in a function with a global var beeing set when the EH fires just fails, as obv. the draw EH doesnt fire at the same time when the function is called...

To be clear:
What is now broken/disabled and desperatly needed is a similar functionality like serverCommandAvailable "#kick" was, that determines if a client is the admin.

ergo...
_isAdmin = serverCommandAvailable "#kick"
_isAdmin = call fnc_isServerAdmin
_isAdmin = isAdmin (future)

Of course I am happy if someone in here manages to write such a function with the workarounds stated above.

We found a way with addDisplayEventhandler too, but its hacky

It seems to work still in some cases, like executing it in debug console.
Or in conditions of CBA FlexiMenu.

is there another way to detect admins now?

as a hack to get around the issues one can spawn a waituntil {time > 0} before executing the commands. OFC this is NO solution and will only compromise your own code, but there is no other solution until BIS fixes that (i didnt find any yet)

1. "object hideObjectGlobal hidden" is not working when used in the Init of the unit, even in MP on dedicated,...

Repro:
Place a unit with "this hideObjectGlobal true" (or hideObjectGlobal this) in the Init and run the mission on a dedicated server: no effect. (it works via debug console though).

2. ...while enableSimulationGlobal does, though not from the very beginning of the mission, which may lead to unwanted side effects

both are still valid in Version 1.22.125300!
Actually hideObjectGlobal and enableSimulationGlobal seem to only work during mission runtime, seems like there is no way to hide/disable any objects prior to mission start with these commands, even if the objects themselves exist already and are not null.

Thanks for linking the tickets!

Can we combine all the latest information we have into one of those tickets, so we are all up to date and have a central ticket, to look into? If you tell me which one, i will do that!

BIS should be already aware of the weather sync issues and all the tickets should be combined into one ticket! We have several duplicates!

Should be merged into one:
http://feedback.arma3.com/view.php?id=3028 (resolved - why....?)
http://feedback.arma3.com/view.php?id=14296 (all time favorite)
http://feedback.arma3.com/view.php?id=18118 (the current issue)

together we count 147 votes for those 3.........

Additionally:
http://feedback.arma3.com/view.php?id=18124 (yeah, but sync first please)
http://feedback.arma3.com/view.php?id=13729 (yeah, but sync first please)
http://feedback.arma3.com/view.php?id=15510 (yeah, same as above)

Please advice on how you would like it to have:

• Do you want me to log a seperate ticket for unsync weather and close this, because the specific issue "When a player JIPs into a running game the nextWeatherChange value on the server (and client) breaks" is solved due to the CBA hotfix?

• Do you want to refer to ticket ID 14296 (http://feedback.arma3.com/view.php?id=14296 ), where more or less those issues are also noted but in a different relationship (local vs. global) and close this one?

• Do you want to stick with this ticket and update it?

KK opened a seperate ticket here http://feedback.arma3.com/view.php?id=18237

After CBA team took their time to investigate the issue, i also pulled my head out and gave it another go...

To start with the positive news...
"When a player JIPs into a running game the nextWeatherChange value on the server"
--> Thanks to the CBA team, this seems fixed with the hotfix! Awesome, how quickly you could determine and resolve the issue!

• Still, weather sync is not handled correctly by the engine - and this was replicable three times in a row with all the information already provided in this ticket on Vanilla A3 stable (so not related to CBA in any way).

• Still Nextweatherchange isnt in sync, resulting in the exact same behaviours (unsync weather for all clients). If its intended to slowly sync weather independendly on clients, then it just goes wrong.

• You can find server.rpt (dedi) and client.rpt attached. You can also see it in KKs rpt.

Highlights...

Weather starts off synced after mission start:

Weather was forced to change
"Time: 16.058 | Locality: SERVER | Overcast: 1 | nextWeatherChange: 1783.96"

"Time: 17.12 | Locality: CLIENT | Overcast: 1 | nextWeatherChange: 1782.95"

After 5 minutes of beeing connected (before JIP), server and client are not synced anymore (see overcast value):

"Time: 438.223 | Locality: SERVER | Overcast: 0.844491 | nextWeatherChange: 1361.87"

"Time: 438.554 | Locality: CLIENT | Overcast: 0.990919 | nextWeatherChange: 1361.24"

After JIP, clients sync weather back from server, means that every JIP player will have a different weather (because of the issue above):

"Time: 458.296 | Locality: SERVER | Overcast: 0.836713 | nextWeatherChange: 1341.81"

"Time: 458.196 | Locality: CLIENT | Overcast: 0.837593 | nextWeatherChange: 1799.23"

And after 20 minutes of beeing connected its out of sync completely, esp. new clients that just JIPed (that were just synced) vs. connected clients.

"Time: 1230.95 | Locality: SERVER | Overcast: 0.537346 | nextWeatherChange: 568.49"
"Time: 1230.07 | Locality: CLIENT | Overcast: 0.79736 | nextWeatherChange: 1027.36"

connected players: http://imgur.com/gqwImP9&qS85fR1#0

freshly joined players: http://imgur.com/gqwImP9&qS85fR1#1

Wind direction changed from varying between 0-30deg at start to 330-360 degrees at the end of my test (about 25 mins)!
I havent tested if wind was synced.

PS: corrected some spelling mistakes and made some parts clearer (hopefully, my english is not the best)

what xeno said ^ ive also observed that without CBA

we are out, sorry! if you think its fine and fixed, Fireball, so be it! Im sure we could provide a repro that is even more clear about it, but we don't have the time to invest more hours on testing that issue, than the several hours our team invested already. We were just wanting to help!

i can just agree with ARJay...

On a very simple QA analysis the issue becomes obvious so quickly...
I took the 10 minutes to analyse the houses incl. references on stratis: Of 682 "house" objects, over 450 are still broken, 66%!

http://pastebin.com/bbF7Lx5V

hey guys! Thanks for rolling back the change, i know it must have been hard a day before release! I think you can close the ticket, as this special case wont pop up anytime soon! Thanks again!

thanks, will try as soon I get back to the PC in some hours

thanks, will check tomorrow!

resolved since 1.26 for me

Im not aware of this, and its not stated in the BIKI. But it makes sense somehow if you refer to the chat as "radio". Also that means, by default civilian players can't use sidechat at all.

Of course it is replicable. I believe its not intended, that sidechat is only working if you carry a radio?

I also cant seem to find that change documented so i assume its simply a bug.
By the way, you dont need a repro mission. Just place a civilian or drop the radio of any unit (and use sidechat in debug console)

and you also dont need DEV branch, but its also in latest "stable"

not completely confirmed working but...

f.e.
0 setovercast 1; (serverside)
ForceWeatherChange; (applied afterwards on server)

--> syncs weatherstate from server to clients including simulweatherchange.

to be checked:
JIP and nextweatherchange values in MP (seems still strange)

http://feedback.arma3.com/view.php?id=18118

related

Issue still applies in version 1.14.116248

No documentation about change "Added: Prototype of weather and time synchronization for MP" found (http://dev.arma3.com/spotrep-00021)