Couple of Headless Client Issues

[macdog]

Hi,
 
Just wondering if anyone can help with one strange, and one less strange issue I've been having with a headless client implementation.
 
First, the strange one that has be completely stumped.
 
The headless client works as expected, doing exactly what I want.  Then, after an indeterminate amount of time it kinda disconnects from the server.  I say kinda, because it doesn't actually get kicked from the server (battleye disabled for debugging this), but I do get the following message in the server rpt:

11:02:43 "DISCONNECT: HeadlessClient (158029510) Object: HeadlessClient, _characterID: 0 at loc [0,7.96885e-038,52.8183]"

You then see the headless client re-run its mission init.sqf.  This is from the HC's rpt:

"DEBUG: loadscreen guard started."
"Res3tting B!S effects..."

It generally seems to be preceded by the following in the client's rpt:

Group C 1-1-A (0x19c90100) - network ID 2:6412
 - no main subgroup

but I sometimes see the above message without a disconnect happening.

 

From what I can tell, the HC is being kicked back to the lobby and the rejoining the game, with any AI that was under the HC's control being passed back to the server.

 

I believe I have the HC configured correctly, with localclient[]={"127.0.0.1"}; in the config.cfg (yes the HC is on the same server) and its correctly slotting into the civ slot.

 

At the moment I have the HC's scripts being run from the mission pbo.  I have used a custom signed mod, which works, but again gives the issue above.

 

Any ideas why I am seeing these disconnects, or if not, any extra debugging I can do to isolate the cause?

 

My second issue is a lot more straight forward, and I am surprised I haven't been able to find the solution.  I have moved animated heli/c-130 crashes successfully to the HC and everything works great apart from the loot spawn.  The HC doesnt seem to know about the variable helicrash which is used to define the loot spawn.  There were a few other variables it didn't know about and I managed to find them in the server pbo and make sure they got defined on the HC, but I can't for the life of me find where helicrash is defined in either the server pbo or the dayz_code pbos.  Any idea?

 

Thanks!

 

 

[axeman]

Have had my HC randomly killed for no apparent reason. HeliCrash is a class. https://github.com/vbawol/DayZ-Epoch/blob/05e0df06aa94837e81bb702e969c2927f429ee97/SQF/dayz_code/Configs/CfgLoot/CfgBuildingLoot.hpp

[macdog]

thanks mate.

 

helicrash loot: could i sworn I checked that, but obviously missed it somehow.  as its in dayz_code, could have expected the HC to know about that as the mod is loaded on the HC.

 

HC getting killed: hmmm, doesn't appear like the player is actually getting killed although the behavior is similar.  You don't get the xxx is killed message, so its seems like its getting "kicked" back to the lobby for some reason.

[axeman]

I would look at other addons, chatting in sidechat has got me booted to lobby before, could the HC get booted mistakenly by server admin tools ?

[macdog]

unlikely - have just deployed on a vanilla epoch and started slowly adding changes.  literally only added infistar, dynamic traders and the AI missions packs themselves and started to get this. I had ruled out infistar before but I guess it could be multiple things, that or the AI packs themselves of course.  Its a pain, as I need to leave each config going for an hour or so to verify if its affected.  Better debugging options would certainly be handy!

[axeman]

Unlikely to be addons as you have only added two and an antihack..? I admire your confidence :)

Best kind of debugging is the kind you add yourself.

[macdog]

haha yeah, obviously i rolled back the AH and the traders, but if I'm honest I haven't left the HC connected without the AI packs running - (although have isolated each to see if one was the problem).

 

My own debugging to date has been logging states of things that I have been messing with.  I guess I should start logging other parameters in general.  Thanks for the help;advice.

[macdog]

fixed it, was the fact I wasnt running the player_monitor on the HC.  Running it causes other problem, but should all be fixable.

[justchil]

Any tips on what type of changes you had to make to your HC's player_monitor? I've been searching for information but no luck.

I have the same problem :(

[macdog]

well, just to get the HC connection stable (ie, no disconnect) you can just run the player monitor (ie, dont condition it out via hasInterface checks).

 

Doing this will mean your HC's character will spawn as a normal player, on the coast, visible and able to take damage, etc.. (regardless of what you do with the mission.sqm). so redirect the HC to run your own player monitor.  I havent got a full config yet, as I havent finished tweaking it to what I want, but basically edit the FSM (you need the BI tools for this) and look for the various checks where enable damage is made.

[axeman]

I like the idea of removing human player specific functions from the HC, never tried that. Anything that reduces the load has to be good.

Have also followed the guides to make the HC invisible, can always see him though. Found that removing all means of killing a player or unit doesn't beat a headshot or zed munching on you, which comes back to clientside.

HC is still the way to go for offloading, working out the locality is a minefield.

[macdog]

 

 

ave also followed the guides to make the HC invisible, can always see him though. Found that removing all means of killing a player or unit doesn't beat a headshot or zed munching on you, which comes back to clientside

I found this was all fine when the player monitor wasn't being run (but got the disconnect issue).  You could look at adjusting the player monitor server side routine to stop it disconnecting clients that haven't properly authenticated and that way exclude any type of player monitor being run on the HC without issue.  At least in theory that seems to be an option.

 

I've already started down the custom player monitor for the HC, so will finish tweaking that, but do prefer the idea above longer term.

 

 

 

HC is still the way to go for offloading, working out the locality is a minefield.

 

Well, its the only way to go.  Ideally arma server would be able to offload AI tasks to a discrete thread (like it does with IO handling I believe) and we could avoid all this "fun".

 

Locality is also fun, find myself constantly having to define server-side variables/functions on the HC, but to be expected really.