Jump to content

Goober

Member
  • Content Count

    43
  • Joined

  • Last visited

  • Days Won

    1

Goober last won the day on December 31 2015

Goober had the most liked content!

About Goober

  • Rank
    Survivor
  • Birthday 01/01/1965

Profile Information

  • Gender
    Male
  • Location
    Texas

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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 :)
  2. 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
  3. 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).
  4. Is your HC disconnecting and reconnecting? (or getting kicked and reconnecting?)
  5. 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
  6. 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: () Hang 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.
  7. 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.
  8. 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 name The 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.
  9. 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
  10. 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
  11. Sorry. Yes, I am jwo7777777. I suppose I simply didn't remember doing anything like that. Oh, well. I am getting old ... Goober
  12. 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
  13. 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
  14. 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.
×
×
  • Create New...