zx64

Right, but to be clear those units do still need to be named something (unlike pre-1.36). The headless clients create new profiles to match those target names, so if you were previously relying on having a known set of profiles for e.g. difficulty settings or profileNamespace data, you may run into issues with names changing between missions. Another thing is that headless clients do not immediately "ready up" from the briefing screen, so if you don't have an admin present during that stage, the game will not immediately advance from the briefing stage when all players ready up (eventually a timeout hits and the game starts).

Testing 1.36 RC, I notice that the headless client now creates/uses the profile "headlessclient". No big deal, just some settings migration, rename the unit for that first client. However, connect a second client, notice the " (2)" suffix: https://dl.dropboxusercontent.com/u/1542468/temp/hc_136_names.png Upon renaming the second unit to match "headlessclient (2)", you run into an issue: https://dl.dropboxusercontent.com/u/1542468/temp/hc_name_problem.png You can directly edit the sqm as a workaround: https://dl.dropboxusercontent.com/u/1542468/temp/hc_136_workaround.png

http://feedback.arma3.com/view.php?id=18365 is still an issue, so those using HC for their missions should double check the actual skill settings with skillFinal. You can work around this by conditionally using different values to setSkill.

Here's what tripped me up: with the changes on devbranch, the HC virtual units have to be named (i.e. text="blah"; in mission.sqm) identically to the profile names used. Sometimes I've seen it get autoassigned to a normal slot (possibly as a result of using joinUnassigned in the description.ext), but I'd write that down to a glitch than intended functionality. The reason this tripped me up is that, aside from making simple repro missions back in 2012, I've not needed to rely on naming units, so this step becoming mandatory was unexpected. Requiring 1:1 on unit names and profile names is going to be a pain for community missions since the naming scheme used by mission makers will have to be matched by server admins, instead of e.g. having the headless clients automatically take the first available virtual role.

Tried this for the last few devbranch updates with the same outcome - can't get the headless client to pick its special role, can't even assign to an arbitrary role to get it in game to test anything else. Loading a mission with a HeadlessClient_F object results in this being logged to the server rpt: Exe timestamp: 2014/10/08 00:00:27 ... Type: Public Branch: Development Version: 1.33.127639 ... 2014/10/08, 16:02:21 Unrecognized PlayerRole target side: 7, index: 3 Connecting a headless client results in this server rpt message: 2014/10/08, 16:09:57 Warning: Network server received wrong index from client (player role) or even: 2014/10/08, 16:11:20 Received 128, expected bool 2014/10/08, 16:11:20 Unexpected message data (message struct NetworkMessagePlayerRole, item leader) 2014/10/08, 16:11:20 Before (0x00000000): 11 00 00 00 00 04 d1 95 9a 03 90 9f be 90 01 c4 ed db 12 00 00 2014/10/08, 16:11:20 Current (0x00000015): 80 The rest of the functionality seems to be working - the server appropriately detects it, e.g. id=HC392, normal clients show/hide it as described. Indeed, the rest of the working functionality includes being unable to manually assign headless clients to arbitrary roles which brings me onto a request - include some way of re-enabling that "assign-anywhere" behaviour. I use the headless client for more than just AI hosting, e.g. as part of testing JIP or locality without needing to start more than one "main" copy of A3. Recently I made some changes to RscDisplayMultiplayerSetup and headless clients were invaluable for quickly testing that thanks to being able to just drag them to whatever roles I wanted (and the faster start up time, lower resource requirements etc).