3LGStevo

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'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 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 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?