He is talking about that it is not shown in the gear dialog not that it doesn't exist at all in the unit.

LOL at whoever downvoted this, having a bad day?

Maybe because you can do this already quite easily without a specific eventhandler?

Sad to read this.
We had this working perfectly fine in CBA XEH.
(and no, those two scripts are not an option :))

Will this be fixed anytime soon, read before the next stable version of A3 is available?

There's also a problem with public variables which are not available for clients on a dedicated server in preInit, but this is an extra issue (for example paramsArray).

@ProGamer
And especially in this case (dynamic weather throughout the mission) it is really needed that there is one instance (server) which handles it and syncs changes to clients (especially in missions with JIP). Currently it's a pain in the a** to get all clients/JIP clients into the same state concerning weather.

The way weather is handled by the engine should be changed. Any weather change on the server = clients will be updated automatically (including JIP clients).
So instead of just making scripting commands global this should be part of the engine out of the box (and only the server should have the right to change weather in MP and not some client because of global scripting commands).

Indeed. So nothing has changed.

Great job with the magazinesAmmoFull command.

Now it would be totally cool if we could simply add back the output of magazinesAmmoFull to a unit/container with another command like addMagazinesAmmoFull :)

You are right, I didn't reload.
Anyway, the command should return the values for all magazines, loaded or not.

@ST. Jimmy
If you've ever played Red Orchestra 2/Rising Storm then you would know what is possible in games and just think "what a piece of crap" the A3 grenade throw thingie is :)

(And RO2 has even inertia and weapon resting :))

WarfigherOne, upvoted.

"In Arma, realism is a tool, not a goal."
https://twitter.com/KarelMoricky/status/321999777917177857

This happens because CfgFunctions preinit in A3 does not work correctly anymore since a few days (afaik since tuesday A3 DEV version).
preinit is not processed before other inits and so it breaks the mission.

From RPT:
[13189,388.43,0,"Executing Dom init.sqf"]
[13191,388.536,0,"Executing Dom fn_preinit.sqf"]
[13191,388.559,0,"Dom fn_preinit.sqf processed"]

fn_preinit is called from CfgFunctions with preInit = 1. But as you can see it gets executed 2 frames after init.sqf.

@cancerouspete
VAS stores its data on the client side in profileNamespace. That's a no go for any MP mission. This data belongs on the server and nowhere else because one can easily overwrite profileNamespace data via the editor.

profileNamespace is fine as it is for storing simple client settings, it's not meant for storing important data which might influence MP missions.

And if the player with the flag was in a vehicle the flag also appeared visually on the vehicle, which is also gone in Alpha 3.

Completely normal behaviour, read not a bug (thus does not belong here).

!alive undefined_variable does not return anything like it always did.

Correct is:
(isNil "p2" || {!alive p2}) && {isNil "p3" || {!alive p3}}

Note the curly braces which is lazy evaluation.
If p2 is nil it does not execute !alive p2, if p3 is nil it does not execute !alive p3.
If the first part of the statement
(isNil "p2" || {!alive p2})
is false it won't execute the second part
{isNil "p3" || {!alive p3}}

@zorrobyte, a better HC implementation won't fix the main problem of the engine. That is, the engine simulates itself to death. If a rice bag falls over 200 miles away from the clients the server will send an update to each client and it will be simulated on each client even if the clients will never see or get near the rice bag.

More objects = more simlations = less FPS. A HC does just offload AI from the server to another instance leaving the server a little bit more room to breathe but does not solve the heart of the problem.

(At least that was afaik the way it worked in A2/OA but I doubt that it has changed seeing that there is a script module in A3 which disabled the simulation of objects more than 2000m away from the player and hide them with hideobject. Please correct me if I'm wrong).

Anyway, still doesn't change the fact that you now need to buy more A3 copies just to do something simple as MP testing.

@Dwarden
Makes absolutely no sense. No one will buy 2 or 3 A3 copies just to test MP content he/she provides for free or invest time into steamcmd whatever just to do a quick test of a change.

So how do people who make MP stuff test now ?

I personally use up to three clients (two normal clients plus HC) beside a dedicated server on my local machine to test MP stuff, but, as already written above, it's no longer possible.

It completely prevents connecting with a second client (normal or HC) to a dedicated server even if kickduplicate is disabled.

Makes MP testing with two clients on a local machine impossible now.

Now that the handleDamage eventhandler was changed

http://forums.bistudio.com/showthread.php?160330-Development-Branch-Scripting-Discussion&p=2550677&viewfull=1#post2550677

it would be cool if the handleDamage eventhandler beeing used in fn_feedbackInit in the feedback system would also be changed (it still returns _this select 2).

(Edit: how about the explosion eventhandler?)

DarkDruid, I'm shocked that a BIS developer does not know that adding more than one handleDamage eventhandler to an object results in unknown behaviour as it is unknown which result from which handleDamage EH the engine uses (especially if one tries to modify the _this select 2 values for his needs).

Attached is a simple test mission (HDEHTest). Shoot the unit in front of you in the head.
The following handleDamage eventhandlers are added via init line to the unit:

this addEventHandler ["handleDamage", {diag_log ["First HD EH returning _this select 2, _this:",_this];_this select 2}];
this addEventHandler ["handleDamage", {diag_log ["Second HD EH returns 0 instead of _this select 2 (which should make the unit immortal), _this:",_this];0}];
this addEventHandler ["handleDamage", {diag_log ["Third HD EH returning _this select 2, _this:",_this];_this select 2}];

The second handleDamage EH should make the unit immortal (it just returns 0) but the unit dies.

There is one simple rule when it comes to eventhandlers like handleDamage (probably explosion EH too): Never add more than one of them to an object.

Furthermore, you do not remove the handleDamage EH before respawn which means that it is still triggered for the dead unit (if it receives damage) and thus changing the variables even though the current player unit does not receive any damage.

Iceman, it has nothing to do with dynamic and heavily scripted missions. You can't script invisible fire or anything related to fire anyway... And yes, it still happens.

Joris (DnA) has added a note to the setOvercast BIKI page:

"Arma 3's volumetric clouds cannot be instantly changed (it would take up to a few seconds to do a full recompute). Therefore, 0 setOvercast 0 will not have the desired effect. You can use skipTime to get to the desired cloud coverage - even 0.5 seconds will usually do the trick."

A skipTime 0.5 is not 0.5 seconds but 30 minutes! And setOvercast currently needs 30 minutes for the changes.
This makes it virtually impossible to add dynamic weather to missions with JIP.

@Fireball, you are mixing something up. What you are talking about is Steamworks not Steam Workshop.

Anyway, see http://forums.bistudio.com/showthread.php?148879-ARMA-III-amp-Steam-WORKSHOP
Modders don't like it all (and right so) so why waste time implementing it.

Does it really need a repro mission to investigate the problem? Especially when it is an issue which already exists for years.

Simply drop a group of vehicles in the edtor, give them a waypoint and watch them...

Déjà-vu :)
https://dev-heaven.net/issues/12990

BI themself uses for example blurr in features like the A3 fatigue/staminia system. But what is the point of adding blurr it if the player can simply disable it by turning off post processing in the video settings...