3LGStevo

When Players disconnect my server, their bodies are left behind in the server as stationary AI... What has been amended in the latest update for this to start happening? Are there settings in the mission.sqm file that now need to be updated in accordance with something being changed? To clarify, the players bodies used to be deleted on disconnect, now they are not deleted.

Does anyone have the ASM.exe file they can send me? I have the addon, but don't have the executable anymore and it was a really useful tool to see what was happening on the server.

FYI, the alterations needed to maintain a vehicle that's also increasing/decreasing altitude (even vehicles on Terrain going up and down) means you also need to preserve the X and Z references, not set them to 0. SUV for example, will start to take off if you use the simple modification of Y with setVelocityModelSpace. I just did the below inside an addAction to bypass the whole trigger scenario. The - 0.2 aspect I found to be more consistent than multiplying by a decimal, and it seemed more realistic for vehicle braking. life_limiting_speed = true; life_speed_limit = speed (vehicle player); ["speedLimiter","onEachFrame",{ if (speed (vehicle player) > (life_speed_limit + 0.5)) then { _VM = velocityModelSpace (vehicle player); (vehicle player) setVelocityModelSpace [(_VM select 0),((_VM select 1) - 0.2),(_VM select 2)]; }; }] call bis_fnc_addStackedEventHandler;

I need a way to force a player vehicle to brake via script without using SetVelocity. I've tried to use keyHandler which de-presses the W key when the criteria is met by returning True, but this then means the vehicle can't accelerate again unless the key is lifted, and pressed again... while it's not an ideal solution to use this handler, it is the most effective way of slowing a player's vehicle based on a trigger from what I've found so far. So my questions are simple; Are there any possible methods where you can force a player's key press (i.e. in this Scenario, force a keypress event for "S")? Is there a way to configure the KeyHandler so that it continues on with keypresses after the "true" handle is triggered?

My custom mission uses three headless clients to spread processing across multiple instances to allow for better performance. Server - Network packets and base game operations HC1 - Database writing HC2 - Object handling (i.e. assigning objects to variables, creating vehicles, managing basic scripts) HC3 - Intensive scripting (i.e. consistent and recursive loop queries) I run my server using a powershell script which is assigned to Task Scheduler on Windows. Every 4 hours, the powershell script triggers to run 4 instances of Arma3Server_x64.exe, and monitors those processes to ensure they aren't terminated, and if they are, restart them. Very rarely do the processes crash so that catch isn't really significant (at least I don't think so). The account used to run the task is the local server Administrator account, and the processes run as background tasks (i.e. I don't see the consoles). I have a steam account that has it's own copy of Arma3 to run these instances of Arma3server_x64.exe. Now, while I have Battleye enabled on the server, the Headless clients take turns in being disconnected from the server with the vague response of "Battleye - Query Timeout". It gives me no other indications other than that, and it doesn't write anything in any logfiles about the disconnects - battleye, headlessclient.rpt or server.rpt. It simply throws them off, for them to reconnect. This obviously restarts a lot of scripting, which shouldn't be restarted unless the server is restarted which is causing problems. For the timebeing, I've disabled battleye and the HCs are now running through full server cycles without disconnects. Here's what I've tried; Running the HCs from Arma3_x64.exe instead of Arma3server_x64.exe Copying the Battleye files direct to the HC user locations Opening the games as the HC clients on the server to manually verify the Battleye license policy Manually running Arma3Battleye.exe alongside the HC arma3server_x64.exe processes Now I'm at a dead end, I literally have no idea why these timeouts are occurring, the only thing I can think of is the process in which I'm running Arma3server_x64.exe is causing the Battleye license verification issues because it isn't technically running it as an application, it's running it as a background task. Questions: Has anyone else had this issue with Headlessclients and if so, how did you rectify it? Can TADST be used to schedule server restarts on a 4 hour schedule? If you use Headlessclients for your server, what process do you use to launch the HC? Arma3_x64 or Arma3server_x64? Thanks in advance, Steve

I've gone with something similar to this... it's still not ideal, as it's quite jittery, but I guess it will have to do. Thanks all.

headlessClients[] = {127.0.0.1}; localClient[] = {127.0.0.1}; All three HCs run from the local server... I'm assuming I don't have to have 127.0.0.1 x3 added into the headlessClients[] array?

Still need literally any kind of help with this... I can't run an Altis server without Battleye, and the server doesn't run properly with the HCs constantly getting booted via Battleye for seemingly nothing.

limitSpeed doesn't work on player vehicles. I already tried this, and inside a loop to repeatedly force the "speed limit"... unfortunately nothing happened at all. Again, unfortunately setVelocity and setVelocityModelSpace is jittery as hell, even simply in 3DEN, solo... with this command over a multiplayer environment, it's going to send desyncs through the roof and constant issues with multiple clients sat in the same vehicle. Yup, already tried fuel, engine, wheels... everything with regards to damaging and removing the fuel. It sounds horrific though and when the trigger stops, there's a slight chance that it renders the vehicle without any fuel while exiting the script because initial trigger loop is still running when the trigger exits - definitely not an ideal scenario. The best solution by far is the KeyHandler event, however, I need to find a way so that when the keyHandler returns handled, that the keypress still triggers when being held-down.

Both SetPos and SetVelocity are jittery as hell... and that's just on a singleplayer client. As soon as you add in any kind of MP element, it's going to be entirely unreliable and just add a heap of bugs on it's functionality. The ability to force a vehicle to apply its brakes with a player driving is the only viable workaround where the engine handles the vehicles ability to slowdown where the trigger occurs... sadly bohemia haven't added that functionality via a simple scripting command, or the ability to press a key for a player (as far as I can tell). The KeyHandler was a stroke of genius, but as soon as the "true" is passed, the repetitive keystroke no longer occurs so it basically forces the player to remove their finger from the W key, and re-press it again to continue driving (which kind of defeats the object if I'm forcing the player to remove their finger from W, otherwise they'd just do it themselves anyway).

Short of modding the vehicle to allow more cargo space, can't you add the items to backpacks, and then store them inside the vehicle? I believe the backpack uses the same amount of space, irrelevant of it's own contents.

I solved this issue myself. I didn't know the locality of the vehicles changed upon a player entering the driver seat. 1. Vehicles only allow eventhandlers ("HandleDamage" ones anyway) to fire on the entity that considers the vehicle local to the client. I.e. if you create the vehicle on the server, and attach an eventhandler to it on the server, the eventhandler triggers. 2. As soon as you enter the vehicle's driver position, vehicle locality switches, which as a result means the eventhandler created on the server no longer fires when the same action is provided. 3. As a workaround, I added an eventhandler to player objects which handles the "getInMan" event. When the player gets in a vehicle as a driver, the eventhandler for the damage is created for that vehicle. 4. While this now rectifies the locality issue, it also means that unless you can specfically assign the eventhandler to a global variable, and delete this global variable on exiting the vehicle (which isn't what I needed), it means the event handler then defaults to the player... so, the Unit then receives the custom eventHandler, which means you need to write inside the onVehicleDamage script that if the _vehicle entity isKindOf "Man", to exit... allowing the standard "Man" damageHandler to apply.

diag_log format ["HANDLE DAMAGE: %1",_this]; ^ my handle (ton_fnc_onVehicleDamage) just to try get something back :( private ["_vehicle"]; _vehicle = _this select 0; _vehicle addEventHandler ["HandleDamage",{_this call TON_fnc_onVehicleDamage;}]; [_vehicle] spawn { _vehicle = _this select 0; waitUntil {!alive _vehicle}; _vehicle removeAllEventHandlers "HandleDamage"; }; ^ what calls it (Ton_fnc_addVehicleEH) ... _vehicle = createVehicle [_className,[0,0,999],[], 0, "NONE"]; ... [_vehicle] spawn TON_fnc_addVehicleEH; ^ the initial part after the vehicle is created. _vehicle is created on the server. The Event Handler code is executed only on the server - so surely this can't be a locality issue? What am I missing? Why isn't this "HandleDamage" eventHandler triggering? It worked with "Dammaged" EH, but that doesn't return the projectile, or the person who fired it (always <Null-Object>)

You're a diamond, mate! I've been searching for this for weeks to try and get some performance monitoring in place again over my headless clients!

Yeah, not going to lie... haven't a clue what any of that stuff is, or what QT is. Haven't you just got an executable you can distribute after the build?

Dwarden, any ideas about why the new C_Van_02_transport_F and C_Van_02_vehicle_F vans cause severe performance drops on servers? I've just done an update where players can pull these vehicles out now, and aside from the problem that if they touch another vehicle, it sends it flying and causes it to explode, but the server performance plummets to around 5FPS/CPS as well as all clients struggling. Haven't had an issue as severe as this one for a while.

I seem to have a massive issue on my server at the moment since the introduction of the new Vans from Laws of War DLC. For starters, this; https://plays.tv/video/59db9a6ee27b47b31e/boom If you so much as touch one of those vans with another vehicle, you bounce off and explode... ??? Second to that, one players in my server started realising you could use these new vans, and we got more than 4 out at once, absolutely MASSIVE performance drop. The server lagged, the clients lagged... everything lagged and fell on it's arse. Can someone explain to me how these made it into live with severe issues such as these?

The actual application you can monitor the servers with. I have all the other files (I just forgot to backup the executable off my old server), so now I have all the monitoring in place, just no way to actually view it! The ASM.exe file thats on the dayz9998jp location must be an old version, because it doesn't seem to be compatible with my current files. The information is skewed (it says I have 410,000CPS on a headless client).

I don't use 64-bit Arma, so it isn't for me :)

Hi, I was wondering if anyone knows how to disable an interface button from being interacted with by the "Return" key. I have a server in which players need to be able to type messages, while certain interfaces are open... but in doing so, when they hit "Return" key, to enter the chat, an action is made which shouldn't happen unless the player selects that button... I've tried adding a disabled button as the "Default" interface, but it seems as the button is disabled, the default returns to another button which then gets actioned...

Players disconnecting my server now leave a body behind. This never happened prior to 1.68, so I need to know what commands have changed that would cause a body to remain where it is. My server is modded so needs to remain using 32-bit since none of the mods are 64-bit capable and I have no idea how to make them 64-bit compatible. The following eventHandler is executed on the server when a client disconnects... _onDisconnect = ["SERV_onClientDisconnect","onPlayerDisconnected",{[_uid,_id,_name] call TON_fnc_clientDisconnect}] call BIS_fnc_addStackedEventHandler; The following is the "clientDisconnect" function... private["_uid","_name"]; _uid = _this select 0; _name = _this select 2; { _pid = _x getVariable["steam64ID",""]; if(_uid == _pid OR _pid == "" OR owner _x < 3) then { _containers = nearestObjects[_x,["WeaponHolderSimulated"],5]; //Fetch list of containers (Simulated = weapons) {deleteVehicle _x;} foreach _containers; //Delete the containers. deleteVehicle _x; //Get rid of the corpse. }; } foreach allDeadMen; //_uid spawn TON_fnc_houseCleanup; [_uid] remoteExec ["TON_fnc_houseCleanup",HC1,false]; As you can see, in the comments it says "Get rid of the corpse" using the "deleteVehicle" command, but either this no longer executes, or the eventHandler for onPlayerDisconnected no longer works. I don't really know where to start looking here as I've been through the patch notes and can't find what would have changed to cause this...

Any ideas on how we fix this? ASM is extremely useful.

So how do I create an invisible unit that gets in the vehicle and pushes the other players' corpses out?

SetPos command isn't working for me on any dead players in vehicles, but it works when they're out of vehicles. I've got the position calculations correct, and if I replace _x with player, when executing the command, the player moves to the location where the body should be ejected to. I've also used } forEach allDeadMen; as for my loop, and checked if the dead man is inside the crew so the object being selected is the dead body, and not the respawned player... The problem I have is, I cannot move the dead body... anyone able to help?

I'm running an Altis Life Server, and when the server has about 40 players in it, the scripts executed on the server pretty much flat-line it because there's simply too much going on for the server executable. I've now split the scripts, database commands and object amendments into three different headless clients, allowing the server to focus on what it should be focusing on, rather than running server-side loops etc... The problem I'm having is; the headless clients connect on start-up, they assign themselves to the headless client slots in a weird order... I've placed the objects in the editor as HC1, HC2, HC3. Yet the headless client that is first to connect will assign itself to any of these slots. So even the HC I've named as HC1, connects in HC2's slot, and then the database requests don't work because (Owner HC1) isn't looking up the right ownerID. In a nutshell: if (!isServer) then { switch (player) do { Case HC1: {//database code}; Case HC2: {//Object/Vehicle code}; Case HC3: {//Intensive Scripts}; }; }; The database request is then done with: [_uid,_side,_sender] remoteExec ["DB_fnc_queryRequest",(owner HC1),false]; ...to which the RPT logs then tell me that the Database specific variables haven't been declared on HC1, because the client (owner HC1) is actually HC3 13:33:51 "lifeServer Init || HC3 is Ready..." 13:40:18 "queryRequest || HC3 Running query request" ^ Pulled from the RPT log in the HC1 user directory. HC1 as a headless client is started 10 seconds prior to HC3, and 5 seconds prior to HC2. It should by all means be the first HC to connect to the server - so why is it connecting in HC3 slot? To clarify what I'm after here... I want to allocate HC1 to the HC1 headless client slot in my server, HC2 to HC2 slot, and HC3 to HC3 slot... this way, when the server powers on, regardless of how long each client takes to connect, they will connect correctly to the slots they are supposed to connect to so that the initial configuration is set up correctly and the HCs are always in their intended positions.