The ticket is still actual. Eventually the amount of dead bodies (the size of allDead array) becomes bigger and bigger and restart is only way to purge it.

@Tenshi
He is using GeForce Now - it is server-side rendering service if you don't have decent PC to play. All user data is stored on the server and not on the client's machine. The user only sees "remote desktop" which runs in virtualized environment and it gets deleted afer session ends trashing all his/her game data. Probably he/she even doesn't have direct access to the file system of the remote machine (depends on GeForce Now service provider)

1st vanilla 1.38.128.937
2nd vanilla rifles/sights have an issues (VS-121 and EBR)

There are few ways to check this.

1. EH on HandleDamage/Hit
2. Bullet trace (e.g Hypnomatic's script)
3. Bullet cam (conKORD's Proving Ground)
4. Just by visual

All of these ways say that there's a problem. 2 mils is a big angle, much more than weapon dispersion defined in cfg.

No responses. Should I upload some video or just nobody shoots at distances over 100-300m?

The result is the same if we'll use bot name instead of cursorTarget:

hint (currentWeapon bot1); // bot1 - the name of the bot

It's not always possible to use selectWeapon on the bot, especially if bot is server-controlled (non-local) or handled by another client and/or for security reason in MP.

I guess the only correct way (with no reinventing the wheel) to fix that is change AI behaviour in FSM.

Client
PREFIX_send = format ["[33, 44, 55, %1]", player]; fail, error in expression
PREFIX_send = "[33, 44, 55, player]"; // fail, undefined var player

publicVariableServer "PREFIX_send";

Server
_blah = call compile PREFIX_send; fail

Normal way
Client
PREFIX_send = [33, 44, 55, player];
publicVariableServer "PREFIX_send";

Server
PREFIX_send is ready to be used

Ok. I've used our algorythm again:

// =====================================
someVariable = "Some shitty value";

for "_i" from 0 to 999 step 1 do
{

publicVariable "someVariable";

};
// =====================================

Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 0 Kbps
Server load: FPS 50, memory 227 MB, out: 1 Kbps in: 189 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 108 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 0 Kbps

It is better than it was in initial ticket.

// =====================================
someVariable = ["Some shitty value"];

for "_i" from 0 to 999 step 1 do
{

publicVariable "someVariable";

};
// =====================================

Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 0 Kbps
Server load: FPS 50, memory 227 MB, out: 1 Kbps in: 304 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 349 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 350 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 366 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 296 Kbps
Server load: FPS 50, memory 227 MB, out: 0 Kbps in: 0 Kbps

The behaviour was changed. It seems the speed (amount of data and/or their size in single packet) of transfering via pV has been changed but actualy we almost have same amount of data for arrays: 304 + 349 + 350 + 366 + 296 = 1 665 kbps.

As you can see the pV data transfer speed was reduced, but amount of the data almost was not changed. Dedicated server was running on the same machine with a client.

PS Was tested on Dedicated Server with simpliest mission possible on Virtual Reality island with a single playable slot available and Dev Console enabled.

arma3.exe

File version: 1.26.126.789
Product version: 1.26.0.126789

arma3server.exe

File version: 1.26.126.789
Product version: 1.26.0.126789

Yep. It's more usefull to store data types as identifiers with one byte of data instead of using strings.

The second thing - I think there's something wrong in ARRAY description/header inside of the serialized net packet. One data type descriptor per one element should be.

This thing is critical when your server holds > 50-100 players and you're using BIS_fnc_MP or same system to call remote functions passing arguments to them.

it will be just workaround but not fixing and will not fix all kind of cases of using arrays on network. For example client-to-server data packet:

MYPREFIX_packet = [player, cursorTarget, 123, 321, true, false, "some other stuff", ["nested", "array"]];
publicVariableServer "MYPREFIX_packet";

There's a problem while deserializing player and cursorTarget, because if you send to server "player" and "cursorTarget, it'll cause issues after deserializing back via parseArray. player and cursorTarget don't exist on the server side.

The problem should be fixed on the engine level, not on scripts.