A majority of clientside lag on MP is the scripting used in the mission.

Most missions run scripts in parallel to the client (IE, all run the same scripts, 1x per player) so the comparison between server FPS dragging down client FPS is somewhat wrong.

The server is struggling because it's running all the same things the client is running, but is also running all the other player's scripts in parallel also.

The scripts are poorly written/designed and thus drag your clientFPS through the sand, as well as the server's. BUT the server's FPS does NOT actually affect client FPS, it just seems that way, due to poor scripting on the client-ran scripts.

^ Very unfounded conclusion, but imo, it seems to be the case in the way I've written missions. I've just as much code as most others, yet I execute it in a more structured, CPU time friendly manner.

Just my 2 cents.

How on earth do you download attachments? I'm trying to do Nics' fix for this issue, but clicking on the attachments above does nothing. I must be missing something obvious...

Essentially, what the OP is saying, is that the reticule is meant to be leaning with the player.

Currently, the horizon of the reticule is the same as the rendered horizon, when it should actually be at the same angle as the player's lean.

^ this.

What good does this EH do exactly? From what I can tell, it just records useless stuff.

At least save the index to a variable, so people can get it and remove the damned thing, or know if it's defined, so they can waituntil {!isnil BIS_var_HDEHIndex} and define their own afterwards. Eliminating guess work.

The 'solution' that DarkDruid has given, is rather confusing.

What does he mean by 'Add sleep before adding your EH (for example "sleep 0.1").' ?? At what point? Is this to put it on the EH list at a specific index? What if the player is initialised, and then later given the EH, or, what?

A full example is needed.

This is odd, as I am using a similar set up and am not having this issue. Attach a reproduction mission?

I'd say it's because the servers have updated to the latest game version, and they've not updated their missions for the class name change in the Ilfrit vehicles, so, they're probably just crashing, restarting, everyone piles back in and starts playing like nothing happened.

Who knows...

If your modem's connection drops, and reconnects with another IP (dynamic IP), you wont be able to reconnect via waiting. You'll have to do as you said, that being, exit to server list and rejoin.

Whilst playing, have a cmd prompt open running 'ping google.com -t'

if it shows any packet drop, then your connection is dropping, and that's why you're being disconnected.

I too have noticed that the latest patch (279) has caused the player IDs to be huge numbers vs how they were before.

Has anyone tried using a different memory allocator?

I personally use ned_malloc, and I've not had any issues, but I don't have a server to test.

http://community.bistudio.com/wiki/ArmA_2:_Custom_Memory_Allocator

^ I for one would still like an option to disable them is missions, for the sake of clientside radius checks etc, it's all unneeded overhead, when within a 5 metre radius, you've got 14 different butterflies floating around....

There's a script function called 'enableEnvironment' which does not seem to do what it says it does on the wiki: http://community.bistudio.com/wiki/enableEnvironment

yes please!

^ another way is to put 'killed' event handlers on every 'man' when they spawn.

The eventhandler script can just have "sleep 10; deletevehicle _this select 0;"

http://community.bistudio.com/wiki/addEventHandler

This is all due to poor mission scripting.

BIS has already got a Garbage collector module built into the game, all the scripters need to do is use it. OR better yet, make their own!

This is no fault of BIS, again, it's poor mission script quality.

if only there were an option to disable the spawning of rabbits, snakes, 1 billion flying insects, etc. They cause way too much overhead on clientside scripts that get objects within a radius, and in most cases, don't add anything to the mission/gameplay anyway.

Have you tried running this on a respawn eventhandler?

The event handler passes the corpse of the previous player object on respawn. Refering to that, rather than 'player' could yield other results.

At what range was the target? Grenades from launchers have a minimum required travel distance before their fuse arms. If the building is within this distance, then they will not explode.

I could suggest that, for now, people add online1you.com and howtoplaycard.com to their hosts file and set them to 127.0.0.1 (localhost). That way, any attempted connections will be redirected by your hosts file to your own PC, and not to those sites.

OR

you could add some firewall rules or something.

My AV has been spiking for the past few hours and I was just about to post a ticket on it. +1

Thank you for approving this. I can't wait to finally be able to ditch 'cursorTarget' from my scripts.

I'm pretty sure it's just a matter of breaking up those statements into defined variables, and then using those, vs having a long line of functions getting variables, because they can have some odd syntax issues, ie
""""

getposATL _x select 1; // <- This errors out, because the _x is an array. It doesn't get the position of the object in index 1, because the getposATL function only cares about the first righthand operand.

""""

These commands are working perfectly for me in my UI in Arma 3. Perhaps post some code to see if it's just a minor issue in change of syntax?

Confirmed, the 'hint' function has no sound effect, so thus it behaves just like hintSilent.

This issue is more a bug in your own programming, than a bug in the script functions.

In order for a vehicle to be created EXACTLY at the position specified, you need to use "createvehicle [array]". http://community.bistudio.com/wiki/createVehicle_array

With that, you can use the 'special' "CAN_COLLIDE", which will spawn the vehicle at the exact given position.

+1.

A command to force 'man' object into a ragdoll state is something I'd really like to see and use.

http://community.bistudio.com/wiki/Category:Arma_3:_New_Scripting_Commands_List

@OP

Reason you got good FPS on that mission is because it's not at all script intense. Most MP missions are written with hundreds of threads, all hogging up CPU time and delaying render calls (via other means), which causes FPS to plummet.

A3 has also a few engine bugs that are inhibiting it from getting good performance on near enough anything. (By good performance, I mean, using > 60% CPU/GPU at any one time).

A majority of clientside lag on MP is the scripting used in the mission.

Most missions run scripts in parallel to the client (IE, all run the same scripts, 1x per player) so the comparison between server FPS dragging down client FPS is somewhat wrong.

The server is struggling because it's running all the same things the client is running, but is also running all the other player's scripts in parallel also.

The scripts are poorly written/designed and thus drag your clientFPS through the sand, as well as the server's. BUT the server's FPS does NOT actually affect client FPS, it just seems that way, due to poor scripting on the client-ran scripts.

^ Very unfounded conclusion, but imo, it seems to be the case in the way I've written missions. I've just as much code as most others, yet I execute it in a more structured, CPU time friendly manner.

Just my 2 cents.