Goober
-
Posts
43 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Articles
Posts posted by Goober
-
-
All,
I am making progress on a rewrite of this for vanilla 1.8.1 (which hopefully will translate to epoch just fine). It is premature to share the code yet, partly because I am having a lot of trouble with Steam's stupid operations getting in the way of running multiple clients from one account ... and also because ... well ... it just doesn't do anything yet.
I have gotten to the point that I have reviewed the zed generation chain and decided that because of the complicated mess that wild zombies + server-side loot + spawn rules (line of sight etc...) has created, the entry point for patching into the spawn chain will be moved to zombie_generate.sqf.
The decision to choose where to spawn a zed or loot and spawning loot will happen on the player clients (or server ... for loot). The actual zed creation and control will stay with the HC with fallback to player client if HC disconnects or burps.
I am also "de-spaghetti-ing" the code as I go along. (Try reviewing zombie_generate.sqf. It is a redundant mess. I could have put some sauce on it and had dinner).
Goober
-
I am well into a code review for Vanilla 1.8.1 and HC compatibility. There are lots of fun changes in the dayz code since initial publication of the HC scripts. There are a ton more references to "player" which is normally a problem for an HC controlled zombie because an HC zombie's "player" is the HC itself. There is evidence of one variable in particular that is indicative and that is 'dayz_canDelete' which is in z\Addons\dayz_code\init\variables.sqf.
So, it is no wonder strange things are happening.
To complicate matters, the dayz coding team are adding more and more function to the client like zombies attacking vehicles. That sounds nice, but means additional signaling between the HC and affected player as to when to tell the affected player that they have been ejected from the car.
These are examples of why this particular project isn't just a snap-on mod. We are changing the fundamental way the whole system operates and it is a custom fix every time dayz gets a version bump.
To complicate matters, Steam has made it even more difficult for development. I have to run my HC in a seperate memory space from my player client with which I test, and forget about multiple keys (I suppose I could get another Steam account).
-
Is your HC disconnecting and reconnecting? (or getting kicked and reconnecting?)
-
Any way to stop the headless client starving? he takes no damage and is rocking out the zeds/loot, but the poor chap seems to starve.. having to heal him is a pain :)
Is this perhaps a side effect of running the player_monitor for the HC? I read an earlier post that the HC was getting kicked from the server the original way that EHC had been setup. Taytay or david, is it still a requirement?
Goober
-
Big thanks to OP Goober for being a bro.
Hey ... I'm a bro ... who knew ?? .....
-
HW,
To get HC working you need an HC (headless client ... meaning a normal instance of the Arma2OA.exe) started using a command line that instructs it to act like a headless client. This should occur some time after you start your server.
An example from my initial post from wayback when: ()
my server startup options:
"Expansion\beta\arma2oaserver.exe" -port=2325 -cpuCount=4 "-config=instance_7_Lingor\config.cfg" "-cfg=instance_7_Lingor\basic.cfg" "-profiles=instance_7_Lingor" -name=instance_7_Lingor "-mod=%_ARMA2PATH%;Expansion;ca;Expansion\beta;Expansion\beta\Expansion;@lingor;@DayZ_Epoch;@DayZ_Epoch_Server;"
excerpt from config.cfg:
requiredBuild = 103718;localclient[]={"127.0.0.1"};headless client startup: (sorry, still some steam path stuff here ... but you should get the idea)"%_ARMA2OAPATH%\Expansion\beta\ARMA2OA.exe" -skipIntro -nosplash -showScriptErrors -noPause -client -connect=127.0.0.1 -port=2325 -nosound "-mod=%_ARMA2PATH%;EXPANSION;ca" "-mod=Expansion\beta;Expansion\beta\Expansion" "-mod=@lingor;@dayz_epoch" -cpuCount=2 -name=HeadlessClient -profiles=HeadlessClientHang in there. Learning all the horribleness of Arma server/client stuff is like learning to swim in shark infested waters, in the dark, without a life jacket. You will be so glad when you get to shore, but you will be exhausted.
-
Yes, i did everything like the tutorial. But it just doesn't work.
I don't know if i did anything wrong.. These are my files i've changed:
....
.bac (to start server)
@echo off start "arma2" /min "Expansion\beta\arma2OverPoch.exe" -port=2342 "-config=instance_11_Chernarus\config.cfg" "-cfg=instance_11_Chernarus\basic.cfg" "-profiles=instance_11_Chernarus" -name=instance_11_Chernarus;
Confirming:
You have three instances of Arma2 going on, right?
1) Arma2 server executable
2) Arma2 client executable setup as headless client
3) Arma2 client executable setup as player client
My advice: when things fail, go back to a setup that is exactly known working and change one thing or one file at a time. If you have to, make another full Arma2 directory to set up exactly as a tutorial or known good set of files from ppl who already have it working. After you have personal experience with a working HC system, you can add your own special sauce.
-
But my number of zombies is still limited to the default amount of zombies.
Don't forget that something like this needs to be initialized by the HC: I put it in my main mission init.sqf normally.
if (!isServer && !hasInterface) then { // headless client processing this dayz_maxLocalZombies = 80; // Default = 40 dayz_maxGlobalZombiesInit = 80; dayz_maxGloabZombiesIncrease = 20; dayz_maxZeds = 1000; }; // normal player clients will get a different set of variables with same nameThe variables are normally set in z\addons\dayz_code\init\variables.sqf :
if(isNil "dayz_maxLocalZombies") then { dayz_maxLocalZombies = 15; }; if(isNil "dayz_maxGlobalZombiesInit") then { dayz_maxGlobalZombiesInit = 15; }; if(isNil "dayz_maxGlobalZombiesIncrease") then { dayz_maxGlobalZombiesIncrease = 5; }; if(isNil "dayz_maxZeds") then { dayz_maxZeds = 500;So, if you leave them out of any custom HC initializations they will be initialized anyway to the default values in z\addons\dayz_code\init\variables.sqf
But you can override them before or after z\addons\dayz_code\init\variables.sqf because the logic used in z\addons\dayz_code\init\variables.sqf is "if value already set, then don't change it"
The way these variables work (I think ... *fingers crossed*) is never more than dayz_maxLocalZombies is allowed to be controlled by any one player client (I think I tweaked this for HC, but ppl may want to do a code review).
Then, the max number of zombies allowed in the game is dayz_maxZeds or (dayz_maxGlobalZombiesInit + (#of players - 1)*dayz_maxGlobalZombiesIncrease) , whichever is lesser.
Caution: if you just decide to make the numbers for the HC and also player clients very high, then if HC goes down, zed spawn switches back to player client spawn and control (or at least it does in my original code) and you can overload the player clients and/or cause worse network based lag than before your server went HC.
-
As goober pointed out it needs to be in the center of the map as the zombies loiter in its direction.
And see no noticeable difference to how the zombies behave.
Also if the headless client Goes offline that = no zombies spawning. (restart on crash is your friend and I would advise reserving a slot for it)
Center of the map is just a recommendation. It was generally necessary in the early days of HC because Bohemia had not coded high precision into position reporting for HC controlled AI. Basically this meant a zombie all the way across the map from the HC vehicle (body) had a lot of error information about its position and yours. This is generally fixed, but it is still good practice to centralize the HC position.
zombie_agentHC.fsm needs to be included in the package or you will get zeds all loitering towards the HC. I reworked parts of it so that they loiter around their last target position instead of the player client that controls them. It may not be very noticeable, but part of what makes DayZ special is that even the unalerted zeds slowly creep towards players, so you can't just sit still forever.
Goober
-
I have a fix in place for the headless client taking damage, spawning on the shore and not being invisible Just working on it now.
class Item2 { side="CIV"; class Vehicles { items=1; class Item0 { position[]={4078.8516,30.836605,4757.7241}; id=0; side="CIV"; vehicle="Survivor1_DZ"; player="PLAYER COMMANDER"; skill=0.60000002; text="HeadlessClient"; init="this enableSimulation false; this allowDamage false"; description="HeadlessClient"; name="HeadlessClient"; forceHeadlessClient=1; }; }; };From mission.sqm for epoch zombie HC code. The position[] is the middle of the map (this position happens to be Lingor 1.5 center).
init="this enableSimulation false; this allowDamage false"; <-- tells every machine that processes it (server, HC, and player clients) that they cannot hurt it AND it will be frozen (unmoving).
Don't remember the really neat way to make it invisible ... but I kinda like to see an indestructible civilian statue in full color in the middle of my islands. Weirdly, only sun and moon light sources will interact with it (a side effect of "enableSImulation false"). So don't stick your HCs in the middle of roads unless you like random vehicle destruction on dark nights.
Goober
-
So your not jwo7777777?
I was reading up about the port of dzai on opendayz and I assumed it was you same avatar etc jwo7777777 linked to the battleye kick and it was posted by jwo7777777 :)
Sorry. Yes, I am jwo7777777. I suppose I simply didn't remember doing anything like that.
Oh, well. I am getting old ...
Goober
-
Glad you guys are having fun. Couple of points:
1) I don't think I am the one who did the BattleEye kick thingy.
2) zombie_agent.fsm (a finite state machine) has internal script references to player position. This FSM file is part of what makes a zombie do stuff (see the execVM of the fsm in zombie_generateHC.sqf ). When in loitering behaviour, the fsm wants to make the zombie shuffle in the general direction of the player that spawned it. SO, that means all your loitering zombies will be basically heading toward wherever you put the HC in the mission.sqm file. This may be unintentionally hilarious, especially if you have put your HC in an odd place on the map (you typically want to put it smack in the middle of the map).
Check my original HC.zip for a modified fsm: http://www.mediafire.com/download/zyrzrs05x1um0mn/HC.zip
I used plain oid FSMEditor to change it. https://community.bistudio.com/wiki/FSM_Editor
Goober
-
So I understand how its supposed to work but is there any way to tell if they are loaded on the HC?
Not directly, which is the point to this. It is supposed to be seamless.
You could put some code in the zombie spawning scripts which writes something to the log files (or maybe even the HC console ... not sure how to do that) when it is an HC that is spawning them. Or you could put very low spawn quantities for default when a player client is controlling spawning and high spawn quantities when it is an HC.
As you have shown in an earlier post, you can get some crazy AI going on HC before you start causing server fps drop, but quantifying the improvement that HC zombie spawning gives is more difficult. It should have some positive effect on the player client machines and maybe some on server communications. But my theory is that if you have sufficient network speed and a properly tuned server config (CPU speed, affinities, file access speeds, # of guaranteed messages versus non-guaranteed messages, etc...) you will see little numeric server improvement.
SO why do this? Because sometimes lag problems are not a simple, single machine issue. Because player client spawning and control is far less consistent an experience than HC. Because it further showcases what can be done with and how to begin applying HC to DayZ coding.
(Thank you for tolerating my diatribe.)
Goober
-
David,
Good start. Check my very first post in this thread and see whether you want to add some additional files or change the folder structure.
You aren't hijacking the thread if you ask questions related to the subject of the thread, so don't worry about it.
-
Do we have permission to create derived work from this? If so, how should credits be credited?
Derived work: Of course! Hack away! I am hoping someone can use my proof of concept code and build something bigger and better with it. More than one person on this thread is very interested in offloading all kinds of server functions onto HCs.
Credit: I don't personally require anything, but common courtesy is to not strip out props located in file header comments or in code comments. Treat the contributors the way you would want to be treated and you will minimize anyone whinging about credit.
-
KoTaS is correct. There is no hidden server side code. Even though the server, HCs, and player client scripts are modified to make this work, everything is done openly through the mission file.
It was put in the server mods forum because it affects server code and there really wasn't another place for it.
It could be put into "@something" mod format, but ... well it just isn't (I don't have a simple reason).
-
justchil,
HCdo_spawnRCV.sqf is basically a modified player_spawnCheck.sqf from dayz_code.pbo
Also, please make improvements like you suggest (initHC and HC compiles.sqf). Some things I just bolted together while hacking this together originally.
If spawn_loot.sqf and spawn_loot_small.sqf needed to be changed, then I missed it.
EDIT: They don't need to be changed. building_spawnLootHC.sqf calls them and passes a (player independent) position to them, so it is an intentional dive back into the base Dayz code. Those sqfs are compiled as part of compilesHC.sqf.
Basically, in order to offload stuff from clients, I needed to replace anything that referred to the player with a reference back to the player's machine ID (for messaging) or position. (Now if I could only get the DayZ coders to do the same in all the base code and reduce the number of overloading sqf files in the mission addons folder...)
-
Okay figure how to make this working again
Tested and working with Epoch 1.0.5.1
Small problem does not work with loot system at all, cannot figure why. Here is error log
"spawned building_spawnLootHC" Error in expression <hance"]; _obj = _this; ... (some content deleted) Error typeof: Type Array, expected Object File mpmissions\__CUR_MP.Chernarus\addons\building_spawnLootHC.sqf, line 4
If anyone know how to fix this, please post it. Iam out of options here :(
Try changing:
_obj = _this;
to
_obj = _this select 0;
in your building_spawnLootHC.sqf.
This sets _obj to be the first value of the input array rather than being equal to the whole array. Computer programmers are weird people. They like to start counting at zero.
-
-
To those interested in the overall architecture of the HC stuff:
1) Server listens for regular interval ping messages from HCs.
2) Server registers any HCs sending pings. Server de-registers any HC that has stopped "pinging". (HC has crashed, overloaded, etc...)
3) Client machines (the ones people play on) do not generate zombies by default any more. Clients send "zombie generate" requests to server.
4) Server sends "zombie generate" request to random HC. ( Choosing a random HC is a crude method of load balancing if you have more than one HC in operation. )
5) If no HCs in register, Server sends "zombie generate" request back to same Client.
All I did was hack Arma2 HC registration scripts (written by smarter coders than me ... and I give them recognition in the header comments) to DayZ zombie handling.
One of the pitfalls is failing to recognize that the request handling mechanisms have to be stateless and fast. At any given moment, the Server, HC, and Client can be hit with hundreds of requests nearly simultaneously. The general approach to that is to have the request receiving code simply spawn (not call) another function immediately to handle the request. Hopefully this is straightforward and understandable.
Stateless is another matter. The functions spawned by the request receiving code can make no assumptions. You cannot just put all the message information in global variables because it could be overwritten at any moment by another request generation. This means the request has to contain all the information necessary for proper zombie generation. So the message information in the request has to be more than just "make zombie". (This is complicated by the fact that the arma messaging system actually does use a form of global variable, so again fast code that copies the message into a local variable is necessary to maintain statelessness.)
Whew!
-
KoTaS,
The code calling the function in building_spawnLoot.sqf is sending an array. Therefore "_this" contains [x,y,z,...] instead of just an object.
It is probably code within the mission folder that is doing this. Search for "building_spawnLoot" inside the sqf files in the mission folder.
Hopefully it is not within an FSM. There is no simple way to explain how they work, how to use the FSM editor, etc....
-
We got it to work, but we have this problem:
The Red Part is our Server and the Yellow is our Headless Client.
I also tryed to set on 4 Cores but seems to jump from core to core.
With original mission, configs and without the HC the problem with the core is still there.
We have installed extra this HeadlessClinet so that the server performance is better, but seems the whole work was in vain.
When the Server is full 30/30 and the HC is running then i have a Server FPS of 2-4.
Without The HC the Server FPS goes up to 11-14.
DeliciousAce,
Sorry that you are struggling with this. I have been a little busy, but I will try to help.
In an earlier post, you had this in your HC startup: " -localhost=127.0.0.1 -connect=localhost "
I am not familiar with the "-localhost" startup parameter for Arma2oa.exe. I just use "-connect=127.0.0.1". Maybe that is not causing a problem, but you can try anyway.
Make sure your server config.cfg has this line in it: localclient[]={"127.0.0.1"};
If that line is NOT in the config.cfg, then the HC will have a less accurate idea of where everything is located.
About FPS problems:
FPS problems with Arma scripting is a well known problem. More zeds and more players = slower server.
The way the HC tracks the number of zeds allowed is different than server-only scripts.
From init.sqf:
if (!isServer && !hasInterface) then { // headless client processing this dayz_maxLocalZombies = 80; // Default = 40 dayz_maxGlobalZombiesInit = 80; dayz_maxGloabZombiesIncrease = 20; dayz_maxZeds = 1000; }; // normal player clients will get a different set of variables with same nameWhen the HC is operating, it is generating a TON more traffic to the server because it may be generating and tracking a ridiculous number of zeds. This may be bogging down your server too much.
Try changing the numbers in init.sqf and see what happens. (But first make sure that " localclient[]={"127.0.0.1"}; " is in your config.cfg. That alone may explain your problem.)
When the HC is off, each player client is handling a much smaller amount of zeds, so the traffic to the server is less and it gets higher FPS.
This "addon" was never released as a supported install with instructions for server operators. The headless client is a kludgy hack that BI created and it affects gameplay and FPS in unexpected ways. For this reason, it is a feature that can be added to a mod, but requires good BI scripting skills to make it work in each circumstance. The Dayz mod team doesn't write code specifically with HC in mind and neither does the Epoch team (even if they do think it might be a neat idea) because writing for HC requires experience and discipline in writing for parallel-process environments with load balancing features, which is a recipe for nightmares.
I don't mean to scare you, but there is probably no easy way to make this a simple addon to a mod.
p.s. Ich spreche Deutsch, aber nur ein bisschen.
-
In your DZAI instructions it shows this:
if (isServer || hasInterface) then {call compile preprocessFileLineNumbers "\z\addons\dayz_code\init\compiles.sqf"; //Compile regular functions}; // headless clients are like isDedicated for some things. No compiles needed from dayz_code initShould it be && instead of ||?No. compiles.sqf is only necessary on a regular client or a server, not a headless client.
... i lose connectivity to the server as soon as the HC connects :(
Ummmm. If you are running your headless client off the same cdkey or steam account as your regular client, then you have to disable ArmA's and Battleye's checks for multiple logins with same key. I don't remember exactly what BE checks and how to fix, but in server.cfg it is kickduplicate = 0;
If you are serious about headless client in the long run, and want to run it on a production server, you may need to invest in another cdkey or steam account for each HC instance.
-
Assuming you have an entry for headless client in mission.sqm
Like the following from my mission.sqm:
version=11; class Mission { <other stuff blah blah............> class Groups { items=3; <other group items 1 and 2 .... blah......> class Item2 { side="CIV"; class Vehicles { items=1; class Item0 { position[]={4078.8516,30.836605,4757.7241}; id=0; side="CIV"; vehicle="Survivor1_DZ"; player="PLAYER COMMANDER"; skill=0.60000002; text="HeadlessClient"; init="this allowDamage false"; description="HeadlessClient"; name="HeadlessClient"; forceHeadlessClient=1; }; }; }; }; };The init="this allowDamage false"; can be expanded to include callouts to "this enablesimulation false; this hideObjectGlobal true" and other things that will affect the vehicle for the HC at the moment it is created.
Working Dayz Epoch Headless Client for Zed Spawn and FSM
in A2: Epoch Mods (1.0.5.1)
Posted
Hi guys,
Quick message to everyone who sent me a PM or posted here. I am sorry that I did not reply. That was my personal failing.
I had to get out of the Dayz/Arma scene because I was struggling intensely with the coding to the point of burnout. Which I basically did.
And now I remember almost nothing about the details of my work, but I am much more relaxed and balanced. I hope that you can have some fun and learn about the maddeningly difficult world of parallel computing and state machines using HCs, but I recommend stepping back when you find yourself banging your head on the wall over this stuff. I can think of no more difficult platform for this kind of development than Arma's weird script language :)