It is not fully bugged, but the action becomes harder to acquire, I can only get the action by first walking around the weapon.

can mark as resolved :)

Is this for all events (object,display,control) or just stackable mission events?

In T121793#1542415, @razazel wrote:

@MDCCLXXVI Please make a separate ticket for this tweak request so we can track it and its progress separatly, this ticket should serve only as a ticket for the bugged AA missile issue, thanks :)

Please make the Incoming Missile event handler pass the projectile (missile) as a parameter!

This one can be marked as resolved, thanks team

Still an issue 1.62.xxxxxx

Thanks for the response.

How do I insert a remote execution call into the Team management UI of the IGUI group bar?

AFAIK, I would still have to have some scripted management for squad leader to monitor local team changes (made with the IGUI) in order to broadcast. I don't know a way, without using addons, to modify the igui code.

I believe the assignTeam / assignedTeam commands should be extended for global args/effects.

As an example use case to support extending its functionality, one of the most widely used and popular A3 mods, ShackTac Fireteam HUD, uses a scripted loop to provide global-effect support to assignTeam/assignedTeam.

Update ...

Credit given where credit is due.

It is fixed in todays patch.

Well played guys, well played.

Create custom objective task with Zeus.

Where is the notification text?

Fix it.

Why is this marked as resolved?

In main branch 1.54 this most certainly is not resolved.

I also have had problems with 'append', though I tossed it up to incorrect usage and didn't look into it.

used it to replace instances of (array1 + array2).

Such as: (array1 append (array2 append array3))

Does not seem to work for those uses, I am guessing I just don't yet understand 'append'.

pushBack only works for arrays created in script language.

for instance, you cannot do (allDeadMen pushBack [man])

Can mark this one as resolved since introduction of isStaminaEnabled

The one issue is fuel consumption is not simulated properly. Takes a lot of jet fuel to fly vertical!

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

"Was there a small update for Arma today? Earlier I was getting hit hard with the issues. Then I logged out of arma and noticed an update in steam for arma (not workshop related). Since then I have resumed playing and so far so good but still too early to say for sure. I would disagree with the battleeye comment if it doesn't run when playing SP missions because that's what I've been playing and still affected by this. However the comment about 3rd person may be a clue since that's when it was happening to me earlier today. Will continue to test the 3rd person theory"

BattlEye now runs at all times, from the moment you launch A3 to the moment you close it.

in addition to the 2.5mb update, there was also an earlier automated client update. IIRC the 2.5mb update was for BEServer, while the earlier automated one (which coincided with my improved client performance) was for BEClient.

For what its worth, my 1.48-related FPS issues are now resolved.

I didn't do anything in particular, I suspect BattlEye was the cause.

As after a some nasty BattlEye crashes (no message received client ejected from server) and a client BattlEye update, my FPS return to roughly 1.46 normal.

Tried the tbb4 contained in the file, don't notice any difference from default 1.48 one. Still heavy frame drag.

Using i5 CPU.

Is there any merit to this "Intel having issues while AMD is fine" theory?

If I jump onto a server as a client and get into another clients helicopter, go to 3rd person camera and tilt up so I see the rotors + sky, FPS drops to 1-5 very predictably.

Can please unlock the permissions on the google drive

My dx diag = 4

Running vanilla client on a vanilla servers.
6 SQF scripts running serverside
6 SQF scripts running clientside
No SQS scripts running server or client
No FSMs running server or client
No script errors in RPT
No script errors on client
No script errors on server
No custom launch params (client)
Server FPS is good

Don't know what Steam is doing in the background though, wouldn't exclude Steam as a potential cause.

Another small repro example method:

1. Join dedicated server as client
2. Get in client-owned helicopter as passenger
3. Get pilot to fly around
4. Go into third person
5. Look straight up or straight down

https://www.youtube.com/watch?v=HwXP_WZt6so

In my opinion a better solution (workaround) is to add garbage to a global array and each machine can run a (local _x) on it before deleting the element. Then the server comes along and removes null elements periodically. Still a sloppy fix for a problem that BI could easily solve.

My 800,000 line RPT file (zero script errors) from yesterday says no. At the very least we should be able to filter this crap out, similar to BE filters.

The most useful solution is simply to remove this logging since it serves no positive value and simply renders the RPT file useless for quick review.

BIS Adam
Thanks for the repro mission! But unfortunately i only got one
0:42:44 Server: Object 3:30 not found
for the 5-10 mins the server has been running

Did use the 'Run Test' action?

Also, are viewing the client RPT or the server RPT? The pasted output above is from my dedi's RPT only a few seconds into the test.

Client RPT will not show anything of note in this repro.

Ticket updated with repro PBO. Sorry about the delay! :)

1. Run PBO in dedicated environment

2. In-game, use action menu to toggle Test on/off.

3. While test is on, view the servers RPT.

4. Some control variables in the initPlayerLocal.sqf to toggle on/off creation of certain types of objects, as well as the recursive slaying of the player.

Sample should be filled with this type of text:

Error: Object(3 : 518) not found
Server: Object 3:769 not found (message Type_125)
Server: Object 3:770 not found (message Type_112)
Error: Object(3 : 765) not found
Error: Object(3 : 768) not found
Error: Object(3 : 764) not found
Server: Object 3:776 not found (message Type_125)
Server: Object 3:777 not found (message Type_112)

Hey Adam,

I'll sort out a reliable REPRO this weekend.

For those interested, the output when #exportJIPQueue is called, will answer some more questions about the spam.

These objects are no longer slingable, while I believe they should be:

B_CargoNet_01_ammo_F
O_CargoNet_01_ammo_F
I_CargoNet_01_ammo_F

mass = 1000

While on this subject, please lower the default mass of the:

Box_NATO_AmmoVeh_F
Box_East_AmmoVeh_F
Box_IND_AmmoVeh_F

to a mass liftable by the UH-80 and CH-49 helicopters. At the moment its mass is 5000, I believe it should be 3500 or something under the 4000 UH-80/CH-49 limit.

A small wishlist

1. description.ext whitelist of functions, or serverside compileFinal'able array of functions. The latter would be more flexible.

2. ability to enable reasonable RPT logging each time the functions are called. What, from who, and to whom. If its called, I want it logged.

3. ability for server to block unsolicited uses of the function. If I have it being called from 2 different scripts, and it gets called from an unknown 3rd script, I don't want the code to be remote executed.

4. Ability to easily disable other remote execution methods. Such as disabling BIS_fnc_MP without preinit tricks.

5. BattlEye kick for unsolicited uses of remoteExec/remoteExecCall

6. Define in description.ext the filepaths of the script where each approved use of remoteExec is located. If remoteExec not from these scripts and use in console disabled, then reject the attempt.

Just some ideas.

Regards,
Quiksilver

I would rather scenario designers, admins and kiddies did not have access to my profile, and also clients not have access to the servers profile. What legitimate information is in my profile that you as a hypothetical server admin, need read/write/overwrite access to?

http://forums.bistudio.com/showthread.php?149636-Development-Branch-Changelog&p=2945723&viewfull=1#post2945723

That is great news, thank you BIS/Adam.

Perhaps then the allVariables function should not work with profileNamespace, at least in MP?

I cannot see a legitimate use for 'allVariables profileNamespace'.

still borked, hopefully 1.52 :)

Animals spawned locally on the client IIRC are not propagated on the network.

If they are created on the server I believe clients can see them.

Up! :)

Animals add a nice touch to scenarios, will be nice to have moving ones again!

The model rotates but functional movement is currently zilch.

this one is all oukej's fault I can feel it!

excellent pettka, have a great day.

sent you a forum PM regarding another similar low-hanging fruit.

This is a low-hanging fruit for any BIS devs working on performance optimisation.

As Killzone_Kid and Manzarek are stating, this need not be run on the server machine, looks like early SP code anyways.

if (isServer) exitWith {};
if (!hasInterface) exitWith{};

Also, a variable to terminate the loop would be nice too.

if (_this getVariable "BIS_disableCarClock") exitWith {};

Reason being if I have a scenario with a dozen civilian ambient vehicles, I doubt many scenario designers want a dozen threads running just for the car clocks.

It is good to have it enabled by default, but allow more advanced scenario designers to terminate the script when there is no intention of having players see the clocks, in the interest of efficiency and performance.

Also could use a little optimisation itself. The 'date' function is being called 4 times in quick succession. Could call it once and store as variable for the next three uses. Small fry but its an irritating little script which shows up in diag_activeSQFScripts :) In a scenario with many civilian vehicles, it is the most prolific script, in my case comprising the bulk of the diag_activeSQFScripts array.

_date = date;

Would be very helpful for simulation to have ability to force AI to use road at all cost and not enter some off-road pathfinding states, even if this could cause other issues (bumping into objects and vehicles on roads). Primarily, I would use this for civilian vehicle simulation. With the reality of A3, I cannot allow civilian vehicles with AI drivers to go off road.

A more reliable repro:

Create a helicopter + AI crew on the client machine (spawning one with Zeus will work.) Ensure you are nearby so as to hear the noise.

Assign it a public variable.

IE:

testHeli = cursorTarget; publicVariable 'testHeli';

Now, delete it on the server machine locality.

// server exec
deleteVehicle testHeli;

The heli's rotor noise as it was at time of delete, will be stuck in your uiNamespace and have to restart ArmA 3 to remove it.

Is this ever to be acknowledged or addressed in any way?

On 2013-11-29, Smookie said it was fixed. Repro steps say otherwise.

I believe we now get regular (albeit delayed) updates on player vehicles which are outside the real-time update bubble. IIRC in the 1.38 sitrep Petr Kolar said there is 1-second update loop for player vehicles which are, say, across the island. Whereas a few versions ago, there was no update loop until the player got closer to the distant one.

If my theory above is correct, this issue is now resolved (said tentatively).

http://dev.arma3.com/post/spotrep-00038
1.38 SPOTREP:

Fixed: Problem with MP synchronization of living characters in ragdoll
Tweaked: Send player position message as high priority once per second

If no one is having issue with this anymore, perhaps it can be marked as Resolved.

It is ragdoll related, not related to the exit from a vehicle.

As said above, I have players running around on foot on my server, getting very fatigued and then passing out (using createVehicleLocal to nudge them in the back to induce ragdoll).

They locally emerge from ragdoll and can get up and move around fine.

However another client may still see their ragdoll lying on the ground, and the actual player appears invisible.

If would like to run a small MP test on the weekend let me know.

--

aside info:

I also have map icons for players. after a death event, the icon briefly sets to [0,0,0] but does not disappear. Once the new unit is created on respawn, the icon goes back over their head.

Contrast with this ragdoll issue.

Player enters ragdoll.
Map icon goes to [0,0,0]

^ That is as much as other clients become aware of.

They are never informed of the player exiting ragdoll and the map icon stays at [0,0,0].

Only when a player enters a vehicle or dies/respawns is this synced correctly.

Also confirmed.

The location of the 'invisible' client to my client is [0,0,0] or perhaps that is just where the affected players icon goes when my machine cannot find the affected player.

I think I know the reason for this too, or at least a glimmer of reason.

When a player gets ragdolled, does their attached Logic get sent to [0,0,0]?

If so, [0,0,0] is outside the 'bubble' we now have where clients get accurately updated information on vehicles. There often is very fast flickering of vehicles that are perceived by the client to be outside their bubble, and also I believe if some client reference is getting sent to [0,0,0] during ragdoll, then that location is well outside the bubble on most areas of the island.

After that occurs, perhaps we no longer get accurate updates on the affected client.

I have implemented a 'knock-down' effect for fatigue system (using createVehicleLocal), and often players are reporting that once a player goes down, he becomes invisible to others afterwards until his vehicle changes. Other clients sometimes cannot track position of the player after ragdoll state is entered.

Once the players vehicle changes (ie the invisible player gets into a truck) all is well and synced properly again.

Seems perhaps there is an issue with (vehicle player) after the ragdoll state?

I'll try doing some MP testing on affected clients, to see if a simple broadcasted anim change will have any effect.

Until a command like this gets implemented, we have to resort to silly work-arounds like this:

_randomPlayer = playableUnits select (floor (random (count playableUnits)));
_ownerNumber = owner _randomPlayer;
QS_vehicleRequestGearDown = <vehicle object>; _ownerNumber publicVariableClient "QS_vehicleRequestGearDown";
[{player action ["LandGear",QS_vehicleRequestGearDown]; QS_vehicleRequestGearDown = nil;},"BIS_fnc_call",_ownerNumber,FALSE] spawn BIS_fnc_MP;
QS_vehicleRequestGearDown = nil;

Just to deploy the landing gear on a Server-local air vehicle.

This is great TY.

I have been getting daily bug reports on the I&A servers from this issue. Good to see it resolve.

Also worth mentioning, re the topic of medic animation. Please include a transition to correct animation 'wrfl' or 'wnon' for medics who initiate the Treat process with a pistol in hand.

At the moment, if pistol is in hand there is no animation and Treat occurs instantaneously. Simply needs a check for current animationState, a check for isNil primaryWeapon and then decide which correct Heal animationstate to enter. IE holster handgunWeapon prior to 'wnon' heal anim, or switch to primary prior to 'wrfl' heal anim.

Regards,

• Quiksilver

In busy MP (> 50 players), it is impossible to read the chat box unless you are always watching it.

It is constantly spammed with:

• BattlEye and system messages, impossible to disable.
• Killed messages
• Join messages
• Disconnect messages

I think the BattlEye and server messages in systemChat should be able to be completely disabled. They look like debug messages meant for admin eyes only, they should not be spamming the chat for everybody.

This is especially important as the use of side channel and global channel is quite limited due to VON stuttering.

Occurs whenever there is not a valid animation transition for the Healer. Seems to occur primarily when currentWeapon == secondaryWeapon or currentWeapon == handgun.

Haven't tested in some time however.

The animation perhaps should attempt to get to a valid animation state prior to entry to the heal self animation.

As it is there is only a currentWeapon == primaryWeapon animation and currentWeapon == nil animation, for putting the weapon on the ground during the healing process. There is no such animation for the secondaryWeapon (launcher) or handgun.

Also it does not save Laserbatteries when the player has a laser designator.

So you cannot reproduce a UAV interacting with the terrain when locality transfers from host to client?

I have also noticed some anomalies when using setPosATL and setPosASL.

Perhaps, if in the transition from server-local to player-local, if there is any use of 'setPosASL' or 'setPosATL', please try just using 'setPos'.

I have noticed anomalies with all "Air" type vehicles when using 'ASL/ATL' setting.

For instance:

setPosATL may cause an explosion

setPosASL may cause sub-terrain position and then it will warp upwards to terrain level.

If there is anything else I can do to aid the process of determining why and fixing the unwanted UAV interaction with the terrain, let me know.

I am able to reproduce almost 100% of the time, the UAVs sinking into the terrain briefly when they first become local. Using the above repro.

There is some apparently random variation in the extent of the negative Z-axis movement, but always there is a slight-to-dramatic negative movement in the Z-axis.

Not sure how the cameras work in such cases. Is there instances of camCreate or camSetTarget that occurs? Does that have any get/set significance on the model position?

I would start by examining any getPos/setPos stuff that occurs in the remoteControl command, or when (vehicle player) becomes the new vehicle, as well as the player camera protocol, during this transition event.

In the schedule of the remoteControl command, the unfortunate sinking occurs AFTER the camSetFov command is used.

Some more details:

https://www.youtube.com/watch?v=d9514fKsKqQ - Example of the explosion. In this case, it seems like there is downward pressure applied, but the vehicle will not successfully clip with the terrain like the vid above, and an explosion occurs.

The precise spawning regime is in the attached files.

The vehicles are put down in the editor as empty UAVs, with this in the init field:

0 = [this,30,FALSE,QS_fnc_vSetup02] spawn QS_fnc_vMonitor;

-----

Edit:

If there are any scenario/script troubleshooting you would like me to do, or any stones un-turned on my end, please let me know. This is an unacceptable situation for Nov 2014 (long time since beta officially ended) and I'd like to help get it resolved ASAP.

Repro attached. Test in dedicated environment. Connect as JIP.

• Note the summary of this issue is:

0021685: UAVs clip into ground on first connection.

No reference to explosion, I see that as only a symptom/outcome of the issue.

Instructions:

• Try connecting as Driver
• After that first connect, that test subject is depleted and must be respawned.
• On connection, start engine to full and switch to 3rd person, you will SOMETIMES see the UAV clipping with the terrain. Sometimes no clip, sometimes only small clip, other times the entire UAV can disappear underground before rising to terrain level again.

• I was not able to reproduce the explosion, but it does reproduce the UAV interacting with the terrain.

• I'd suggest figuring out why the UAV clips with the terrain and attacking that, instead of focusing on the actual explosion. It's highly likely the two are related, and the terrain clipping is reproduceable with only 1 connected client.

• Loading the server CPU does not appear to be a factor, I was able to reproduce terrain clipping with no added code or mission objects. I tried loading the server CPU with a few hundred AI in combat, but found no change in result.

• Also please be aware that some MP/localization issues only are apparent with high traffic. Attempting to reproduce a high-traffic-related issue in a low-traffic environment may not be accurate. The failure to reproduce such an issue is not necessarily the fault of the repro PBO.

• If necessary I can probably arrange for you to have debug console for a short time in a main branch high-pop MP server.

Hello,
could yuu please upload a short repro mission? We are unable to reproduce the explosion. Thank you.

The repro posted is sufficient to reproduce the bug summary:

0021685: UAVs clip into ground on first connection