baermitumlaut

Arma usually never maxes out on all cores since some things are not multi-threaded, for example the AI. That's why with a lot of units usually one core will max out while the others stay at around 20-40%. You can try using a headless client (or multiple) and optimizing your basic.cfg to get more performance.

Found a bug report that fits if you want to vote: http://feedback.arma3.com/view.php?id=22914

Dwarden, any idea if the headless client + signaturescheck=2 not working is a configuration issue or an actual bug?

Works fine for me. Make sure you don't have them disabled via the basic.cfg.

That unnofficial hotfix worked for me too. Thank you very much.

I assume selfmade missions then? 4gb should be fine.

CPU: A good quadcore CPU is enough, maybe more cores if you want to use a headless client. RAM: 4gb should be good. How many players do you expect?

I have no influence on how TFAR behaves when you die, I'm only using its built in function that is made for spectator scripts. Same for ACRE. For TFAR, it also depends on if you use its hardcore mode or the normal mode. I do not block chatting, could do that though.

A3G Spectator Cam This is a simple camera script that you can put in any mission, regardless if you use any mods or not, however it was originally made to be used with AGM. Features tags units of all factions marks unconscious units with a circle instead of a dot (if you use AGM) 3 camera modes: free, 3rd person, 1st person 3 vision modes: normal, nightvision, thermal vision displays condition of units (fatigue, blood level and pain) compatible with Acre and TFAR close groups get marked individually, distant groups are shown with a group symbol displays how many players are left alive and how many are unconscious (useful for admins!) automatically ends mission when last player dies Usage download the ZIP file from my GitHub copy the description.ext and the a3g-spectatorcam folder in your missions folder if you already have a description.ext open the spoiler That's it! Once the camera starts up a help dialog will show you how to control the camera. There might still be some bugs and I will continue work on this, but it works quite well already. If you have any suggestions or feature requests let me know, your best bet would be creating an issue on Github.

I'm not sure if this was answered before, but I didn't really find anything. I'm trying to run a headless client on a Linux server. If I disable PBO signature verification, the headless client can join the server just fine. However if I use "verifySignatures = 2;" the HC cannot connect anymore because some PBOs not being signed according to it's RPT file. But the bisign files are definitely there, and as a player I can join the server just fine with the same files.

You get switched to a spectator channel, so if you talk only other spectators can hear you. You can also still hear players ingame, at least for TFAR, but I don't remember right now if it is directional.

What should happen if they die in that part? You can use setPlayerRespawnTime and set it really high in that part then lower it again afterwards.

The camera looking at the ground is just because it is so close to it. I could add a minimum camera height which would fix that. I should also add underwater support, didn't even think about that, thx!

Again, it's currently not possible due to the way how AGM does the visual effects for pain, bleeding, etc.

So you would return to player view once woken up again? No this is currently not possible. AGMs visual effects run in a loop, so to disable them while in spectator mode I would have to heal the player first. I don't think there is a way around this right now. I also really don't like the idea of looking around while unconscious to see where the enemies are. The idea of being unconscious is not knowing what is happening around you, so this would really make unconsciousness not punishing at all or actually beneficial.

You can definitely do that. I would recommend making a "initPlayerLocal.sqf" in the mission directory and using something like this: if (side (_this select 0) == civilian) then {[_this select 0] execVM "a3g-spectatorcam\initCam.sqf";};

If you look into a3g-spectatorcam\initCam.sqf you can see I have event handlers for keyUp and keyDown, within that event handler I check which key was pressed. You can change those key codes to anything you like, all possible codes can be found here: https://community.bistudio.com/wiki/DIK_KeyCodes#Alphabetic_sort Just make sure that you assign a different key to switching players because that is assigned to the arrow keys right now. If you need any help with that let me know.

You can use addon groups too, I would recommend using the config browser to get the exact config path.

You can use BIS_fnc_spawnGroup. This creates an OPFOR infantry squad and executes the loadout.sqf for each unit: func_spawnEnemy = { _spawner = true; while {_spawner} do { _markers = ["SP1","SP2","SP3","SP4","SP5"]; _spawnpos = _markers call BIS_fnc_selectRandom; _pos = getMarkerPos _spawnpos; if(_pos distance player < 10) then { _markers = _markers - [_spawnpos]; } else { _group = [_pos, enemy_side, (configfile >> "CfgGroups" >> "EAST" >> "OPF_F" >> "Infantry" >> "OIA_InfSquad")] call BIS_fnc_spawnGroup; { [_x] execVM "loadout.sqf"; } foreach units _group; _spawner = false; }; } }; As you can see the changes are minimal, instead of a unit it creates a group, then goes through each group member and applies the loadout.sqf.

I experimented a bit and it looks like no matter what, the event handler doesn't trigger. I suspect this is related to it being a map object (you can't detect it with cursorTarget for example). I would recommend you to do a workaround, for example the "classic" exploding barrels. You can find suitable barrels under Objects (Containers). You could now add an event handler on the barrel instead if the transformer, for example like this: this addEventHandler ["HandleDamage", { if (_this select 2 > 1) then { _charge = "APERSMine_Range_Ammo" createVehicle (getPos (_this select 0)); deleteVehicle (_this select 0); transf1 setDamage 1; transf2 setDamage 1; _charge setDamage 1; { _x setHit ["light_1_hitpoint", 0.97]; _x setHit ["light_2_hitpoint", 0.97]; _x setHit ["light_3_hitpoint", 0.97]; _x setHit ["light_4_hitpoint", 0.97]; } forEach nearestObjects [transf1, [ "Lamps_base_F", "PowerLines_base_F", "PowerLines_Small_base_F" ], 1500]; }; }]; Alternatively you could park a fuel truck nearby and let that explode in a similar way. I also turned the lights off within that event handler, so you won't need a while loop and save some resources.