Viba

I've run into some problems with my headless client since the newest 1.63 patch (1.63.125548). Server is running Windows Server 2008 R2. Scenario A: If I start the HC through steam and include the startup parameters in steam it won't initialize properly. It won't join the correct slot as specified in the mission.sqm, init.sqf runs normally and any scripts onward from there, but publicvariableserver has no effect on the server, server never detects the pubvar being sent from the HC. I even tried to make a loop that pushes the pubvar with 10 second intervalls, still nothing. This is fixed if I restart the headless client manually again, then suddenly it starts working again. Scenario B: If I start the HC through the new file ArmA2OA_BE.exe with same startup parameters it works fine on the first try, BUT after a random amount of time (usually between 1hour to 10 hours) the HC starts to clog up the whole server. Bandwidth usage is spiking up and down, server is unresponsive for most of the time with ping spikes of up to 10 seconds, TeamSpeak and RDP etc. are unusable. Killing the headless client process normalizes the situation immediately, I verified this with WinMTR running on both the server and my home computer, when the HC started acting up both started having problems connecting each other, terminating the HC process normalized the connection immediately. I have disabled the headless client for now due to these problems, would still like to have it up and running again because of this: :p I've had no problems with the headless client pre 1.63 & Steam. Anyone else had similar problems? Any input from the developers about this?

At least in 1.32 setvelocity didn't affect brakes.

Yes my point exactly, why include BIS_fnc_MP unnecessarily when you can just use the publicvariableserver and addpublicvariableeventhandler.

Why not just use publicvariableserver and addpublicvariableeventhandler?

Ah, should've read the post a bit better :)

#define getHPdmg(hpname) _veh getHitPointDamage hpname _veh = _this; if !(typeName _veh == "OBJECT") exitWith { diag_log "ERROR getHitPoints, _this is not an object"; []; }; _vehCfg = configFile >> "CfgVehicles" >> typeOf _veh; _hitPointsVeh = _vehCfg >> "HitPoints"; _turrets = _vehCfg >> "Turrets"; _hitpoints = []; for "_i" from 0 to ((count _hitPointsVeh)-1) do { _hpname = configName (_hitPointsVeh select _i); _hitpoints pushback [_hpname, getHPdmg(_hpname)]; }; for "_i" from 0 to ((count _turrets)-1) do { _hitPointsTurret = (_turrets select _i) >> "HitPoints"; for "_j" from 0 to ((count _hitPointsTurret)-1) do { _hpname = configName (_hitPointsTurret select _j); _hitpoints pushback [_hpname, getHPdmg(_hpname)]; }; }; //Returns [["hitpointname",damageasinteger],["name",integer]] _hitpoints;

Yup doesn't help having AI or actual player inside the vehicle, brakes are still on.

Looks good, could've certainly used a guide like this when I started scripting. A quick thing I could think of would be to include missionNamespace, uiNamespace and profileNamespace, if you are willing to update and improve the guide even further :)

Yes ofcourse attachTo has been used for a long time and is really easy to do. But wasn't the point of this thread to actually tow using the ropes? :) Edit: Just re-read your post, haven't actually tried that. Maybe best I'll go to sleep.

Practically a loop is not going to cut it. You can probably simulate the correct physics but it takes alot of work and performance wise in a multiplayer game it's not ideal. The loop method was used pretty neatly in a towing script for aircraft in A2, can't remember the correct one but it looked pretty realistic. Instead all we need is a way to not have the breaks applied 24/7 on the vehicle :)

Nope, you really need alot more fiddling around to simulate correct physics :) Looks pretty funny:

_moneyPile = createVehicle ["Land_Money_F", getpos player, [], 0, "CAN_COLLIDE"]; //This syntax is way faster than the old one _playermoney= player getVariable ["mymoney",0]; //Now _playermoney is 0 if the variable doesn't exist _moneyPile setvariable ["mymoney",_playermoney]; //Didn't quite get what you were trying to do, double the money amount the player had or just have the moneypile have the same amount?

Been struggling with this one too. Lowering the center of mass made it possible to drag the vehicle without flipping, ofcourse the brakes are still on. A loop might get the job done with some fiddling but is really not a feasible solution at all. What we need is this: vehicle setHandbrake true/false

Far easier to just check what .p3d filename ATM:s have and do some string searching from the nearestObjects results with no classnames.

Nothing, since the cursortarget doesn't return anything.

Objects with no classnames, like ATM:s on the map, are not showing up with the cursorTarget command. Hence why I made the nearestObjects comment :) The cursorTarget command only works if you have manually created ATM:s on the map.

And if the ATM:s don't have a classname you need to use nearestobjects with no classname and separate the atm machine by it's p3d filename.

You could still try _nObject enableSimulation false;

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

I believe the downloading of the mission file has a bit bigger impact on most of the servers regarding the red-link problem during joining, so maybe not "specifically" :) But yes, publicvariables, global setvariables and so on need to be synced upon clients joining the server.

Hmm this tradeoff ofcourse depends on the situation. Either you are using the servers resources and less network bandwidth for the saving, or vice versa. If you have only a few simple and fast checks that need to be done to gather the information then process it on the server. I'd rather send a preprocessed string/array from the client that's a few characters longer to the server if the checks are a bit more requiring. Simply put I don't like the idea of having 60-100 clients poking the server each in x min intervalls, "save me and process all this stuff for me before it". And if you process the information on the client you can opt to have anything "custom" local to the client, for saving you can then utilize local setvariables and global variables, no need to broadcast them through the network (setvariable with true flag for global). Optimizing is interesting and it can often be hard to say what solution is actually the best, it's good to hear other options and opinions regarding it. Testing something like this would require some effort to get accurate results as the effects would probably not even be that noticeable :) Edit: I just had to check, as a string for one typical save in my mission it would be around 400 characters. I'm not that familiar with how ArmA handles packets or even generally about network packets. But say there's some overhead and thus the packet size would be 500 bytes/save. So with saving at 5min intervalls and 100 clients we'd get a bandwidth cost of the following: 1/3 saves per second * 500 bytes/save = 0.167KB/s of network traffic, if the information would be processed and sent from the client to the server. With more information about setvariable broadcasts it could be interesting to compare this to, say about 5-10 global setvariables on each client repeatedly broadcasting through the network to everyone. Maybe puts it more into perspective with calculations like that, someone correct me if I'm horribly wrong with these figures :)

https://community.bistudio.com/wiki/addPublicVariableEventHandler myVariable = "my string"; Now myVariable is a global variable on the "node" (client or server) where this part of a script has been executed. With publicvariable, publicvariableclient or publicvariableserver you can broadcast this global variable to everyone, a specific client or only the server. A publicvariable eventhandler is triggered for the specified variable when the client/server that has the pubvar eventhandler receives a broadcast when one of the three commands above has been executed on another node. So say we do this on the server: "myVariable" addPublicVariableEventHandler { diag_log myVariable; }; Now the server has an EH specified for myVariable. If a client publicvariables myVariable with some information the server then immediately diag_logs that information. Client: myVariable = "my text"; publicvariable "myVariable"; -> Open up the servers .rpt log and you should find "my text" from there. This is used to request and send information to the server on demand, otherwise you would need to have somekind of loop checking for changes to a variable. About the saving loop, I mean every client should have the loop running locally for them. Upon saving time the clients themselves gather all saving information and just passes it onwards to the server that then saves it.

Unless one suspends the script after the EH for a long time, then there's no problems.