Jump to content

(GSG) Az

Member
  • Posts

    70
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by (GSG) Az

  1. Ill update the git with complete working code. I had issues with WAI's server side code converting it across to HC side with PV's for the vehicle saving. I got stuck on this and didnt really progress much further. The issue I was having was the HC would spam PV's until it lagged out and dropped. A nasty side effect. 

     

    The base code works flawlessly though. I was going to do a complete rewrite and account for some other factors I didnt consider but I havent as of yet. I will release this AS IS for the time being - It supports most of the basic features already. Zombie spawning was another difficulty I had, but it was more the time I had dedicated to it - I simply need to put more effort in. 

     

    Ill update this thread when the git has been updated with the new code (the code on the git is VERY old). 

  2. Getting this as well. Under the assumption that I havent changed anything other than the antihack, its safe to assume it might have something to do with that. I'm working on a fix, but its always best to use the latest version (there are 4 new versions in a matter of days). The latest is AH0330d

  3. Well... A slight technical set back. 

     

    I need a new server :(

     

    The HC keeps getting strange parity errors in the RPT resulting in a crash, the files are all fine - I reinstalled them 2 times to make sure. It must be a RAM issue or perhaps some wierd consequence of using public variables for critical functions. Either way, I need to test it on a new (and higher power) server before I will let it land on anyone elses server (and potentially create a heap of drama).

     

    Progress though, but a step backward this time it seems. 

  4. Happy to help test mate. I already run some headless AI, but nothing as fancy as what you describe!

    I won't grant RDP access, but could roll logs to a FTP/Dropbox/other location.

    TS3: 85.236.100.27:17647 poke a purple badge person if I am not on TS at the time or message me here.

    If it passes some basic tests happy to roll this with live players (most evenings 50 players), and have 2 dedicated non-hyperthreaded cores for exclusive HC use.

    Unfortunately I require some form of access so I can modify the HC on the fly if bugs are experienced and update it. I also need to ensure that it is I that sets it up to avoid error on anyone else's behalf as an issue. Bug testing and finding out someone else didn't follow instructions is frustrating.

    I'll hit Cen and Ruben up over the weekend.

    And... Another update!

    So an unusual bug appeared. The headless was getting kicked to lobby silently and reloading, causing it to wig out like crazy and lag the entire server to a halt. Turns out if the headless compiles the regular functions but doesn't load the player monitor, it gets stuck at the loadscreen and times out. It still executes all of its duties though. But when you have it load buildings, this becomes a real issue. Some of the WAI scripts I have been using for testing require some of the basic compiles, so it became necessary to define these manually.

    After solving that, it runs like a dream. 40AI on the headless, 49FPS on the headless. The server still has comparatively low FPS when it reaches max players (3FPS) but it is better than where it was (well below 1FPS, probably closer to 0.1FPS). We have lots of cores but only 2.8GHz per core so that's why the values are so low. We are upgrading to better hardware soon (3.5GHz here I come!).

    And Apache over at ARC has created a nice launcher for the server that waits until the hive log streams data before connecting the headless. This means it will not join until a player does and loads the mission. This was the one caveat of this system, and he deserves a massive shout out for his work :)

    Now that these strange glitches are resolved, I can move onto JIP compatibility and then fine control. After that I will integrate the client side functions and the FPS manager. After that, it's the final stretch!

  5. Another quick update...

     

    Most server side AI solutions use server specific functions to publish vehicles, do certain tasks etc. This means I have had to make a modular plug-and-play framework for each AI solution. It will be released as a single compile, and will overwrite default functions used by the AI systems to make them PVC/PVS compatible. Simple change, little set back.

     

    Otherwise, the HC has been running excellent on my dev environment (Until it tries to publish vehicles to the database and wigs the F out) so all in all this round of testing has been a massive success. My friends over at ARC have been testing the framework and have had really strange and mixed results. A bit more live testing on their side is needed. 

     

    I would like to extend an invitation to those interested for the next round of live testing.

     

    I will need RDP access and a unique account so I can grab some logs from time to time (and I might even be able to optimise your scripts while I am there, I'm a perfection whore). If you would like to take part, please post below with a teamspeak address I can contact you at. Please bear in mind that I will have to modify your current files. Please ensure you have a backup of ALL files before accepting the invitation for alpha testing. I cannot be responsible for breaking your server (I wont, I promise).

  6. Ok so an update!

     

    Live tests were semi successful.

     

    A few notes

     

    • No more than 1 headless client can run on the server. After a clarification from Bastion over at Battleye (Thanks for the quick reply!), only one instance of the BEClient.dll can run on the machine at a time, resulting in "Corrupt Data #5" kicks when you try and run more than one HC on the server. This can be resolved by using VM's or external clients, but is still a setback indeed.
    • BE filters are not as standard as I was hoping to make them. You will have issues with these, especially if you have customizations. I will put up FULL instructions on how to correctly do your filters and the common issues encountered but overall it does detract from the simplicity of the framework I was hoping for.

    After all was said and done, there were some random crashes (caused by a script error I promptly fixed), and some massive network congestion (Might be related to the script error). Either way, it will be a few more days of live testing before I will be willing to release anything - I don't like releasing broken software.

     

    The JIP functionality is also not functioning. After some more tests I will fix that.

     

    Signing off! 

     

    Az

  7. I was unbanned immediately by Bastion, issue was unrelated to the HC.

     

    I will update the git so its actually clean and not a mess of code as it is now :P

     

     

    What's your git name, very interested in taking a look at your fork. Have done a fair bit with HCs.

     

    Starting the next round of live testing now!

     

    Currently server side scripts are working excellently, but client side specific scripts are having strange issues. I plan to release the alpha after this round of live testing (and subsequently the git) and then work on implementing client side (Zeds, etc) back into the HC after the fact. I think I need to rethink my strategy with regards to communication frameworks. 

     

    You found a solution how to stop other players joining to HC slot in the lobby?

     

    That was the easy part! Two chunks of code, one running on clients with an interface, one without. Simply checks whether a real client (Not the HC) is not CIV and if so, kicks using a PV. DSCHA's solution also works - but it was only a few minutes of testing that an actual player clued on and changed his name to "HeadlessClient" and slotted in. The framework works on a "strict" code ethos. This means that no code can execute outside of its frame of reference (players loading as HC, HC loading as player etc). 

    And the best part of all....

     

    I will be releasing BE filters to accompany my release. 

  8. Would this ever have Linux DayZ Server compatibility?

    Sorry Dean, allow me to rephrase that. It was late and I wasn't thinking clearly.

    It will absolutely work with Linux as it only requires PBO's to run but it would be a challenge to run the Headless client on the server. The HC could run remotely and connect but I will have to get a key for the headless PBO (as it runs on the HC only). This carries with it it's own set of challenges, as bandwidth then becomes a real issue. I would be interested in setting up a test server on your box to test the viability of this if you are interested?

    Worst case scenario I may need to recode some of the basic functions involving network messages, and optimise the reliance on a response in a timely fashion - but most of these features are already there. It's just a matter of testing whether they actually do what I think they do haha!

  9. Quick update.

    Ill be uploading benchmarks and teaser footage by late tomorrow.

    So far I havr had massive success with this project. I am not normally one to gloat but thr DZHC works with things I didnt think possible.

    A quick technical overview for those interested. The HC now works via its own PBO. Files are still needed in the mission file and server pbo but these are just compiles and variables. All HC handoffs can run via the HC pbo which means TINY mission files and protected scripts :)

    I have currently ported zombie spawning and WAI with absolutely no technical difficukty. Took 5 minutes to modify them to work.

    And perhaps the most awesome and unexpected news of all:

    Buildings running PURELY on the HC only. Clients seem to recieve it in a stream. The advantages so far are a 25% improvement in client FPS and much quicker load times for players.

    Im currently running tests with 100's of AI and zombies statically spawned. I will also run tests using non-static spawns and report back FPS details.

    I have also forked the epoch git and I plan to integrate the system into the base code following the coding practices currently employed by the dev team (init variables to enable/disable etc). If your interested VB, ill send a link to that fork once I am confident it will work.

    Signing off for the night gents and ladies!

  10. The first error is a malformed server_functions.sqf. Start with a clean copy. The modifications you have made to it have caused this. Make sure to use the 1.0.4.2a files. The second error is because you have overridden the default variables with your own and have forgot to KEEP the original. 

  11. Hi,

     

    Will this allow you to run different factions and define their behaviour on different headless clients ?.

     

    i.e.

    2x HC for Zombies

    1x HC for AI bandits

    1x HC for Trader City PMC guards.

     

    I can put the last in via the editor but would rather have their management off-loaded.

     

    Also, when you say it will use all of your CPU, my understanding is that ARMA is not multi-threaded and will only use a single thread / core.  Is that incorrect / have you got around this limitation or will it max out a single thread / core per HC ?.

     

    I run on a dual X5570 server so would be very interested in being abl to use all the cores rather than having most sitting idle.

     

    RB

     

    Controlling different factions will be easy. Offload each separate AI instance to the HC's you desire. The automation will do this for you as long as they all have the highest priority, and the priority is the same for each. 

     

    There is a lot of misunderstanding surrounding ARMA multithreading and generally the advice you find is bad and inaccurate. ARMA does in fact utilise 2 threads, not 2 cores. But the caveat here is intel's hyper threading technology. I have seen in perfect consistency tests showing arma utilising 4 threads, 2 are obvious and native, 2 are subtle and load distributed by the HT tech. The limiting factor here is the compiler and its efficiency to communicate effectively with HT. This is why disabling hyper threading will give you a MASSIVE boost in performance. The engine will not have to rely on load balancing to utilise the ghost threads created by HT. That being said, two threads maxing alone will create enough heat to challenge most desktop CPU's and their stock coolers. Hence the warning. 

     

    There is a way to get ARMA to use more than 2 threads natively, and I have semi-succeeded in doing so. It involves exploiting branch prediction. It is buggy, messy and almost always results in simulation diversion IE critical thread violation exceptions. If you know enough, you might succeed, but I highly doubt it. 

  12. Small Update:

     

    Code coming along nicely. Did a complete rewrite after a stupid ARMA quirk stopped the HC from connecting and broadcasting. I currently have it logging, communicating and ATTEMPTING to offload tasks. I am going to do a rather clever hack tomorrow (Think the server passing an array of strings to a client, then think formatting these as code on the client and compiling and running them). But rest easy! Soon this project will be ready for release!

  13. I'm really interested in trying headless clients on my server. A few questions in preparation...

    • Does each headless client need a copy of ArmA 2 OA to run?
    • Can multiple clients be run on the same PC?
    • Ideally, I want the HC(s) and my player client to run on the same box.

     

    Thanks! I'm looking forward to trying this and see how it affects my server performance.

     

    1: Yes. There are ways around this, the server doesn't actually need a legit key - BUT the headless client does. 

    2: Yes. Ideally you will want to run the headless client on the server, and connect locally (on 127.0.0.1) but you can run multiple clients on a single PC by using a reg file to change your CD Key when you start the HC, wait for it to connect and load (about 1 minute) and then run another reg file to change your key back. You would need a key for each client you run.

    3: There are many reasons why this is a bad idea. The HC is designed to literally suck every bit of performance out of your CPU. User beware, you will need DECENT hardware and cooling to run a client remotely. 

  14. I've been switched on to the idea of running headless clients for a while and have watched a few of the efforts in this forum with great interest.

     

    I hope you post something more concrete, a demo or some video perhaps.

     

    I love the idea of offloading z's to other servers in my datacentre and running ridiculous amounts of them.

     

    All I have left to do is a few handoff functions and actually testing it on a live server. Expect git links, video and examples to come within a few days :)

  15. Hi all,

     

    I just wanted to post to share a project that I am almost finished and get some input/suggestions as to the degree of features and flexibility I will add.

    I'll start by providing a current overview of what this can and cant do, and leave the floor open for criticism, suggestions and the like.

     

    I started this after becoming frustrated with the lack of decent modifiable headless clients available for ARMA and ARMA mods alike. Each HC was designed with a particular purpose in mind and was not easily configurable. I then decided that the HC's available simply were not going to cut it and set out to write my own - But with a few differences.

     

    Key Features

    • Standalone framework
    • Multiple headless client support
    • Server controlled headless clients
    • Start/Stop headless clients in realtime.
    • Assign priorities to headless client tasks
    • Server/Client/Headless handover support
    • Client framework for client specific variables
    • Headless client automation system
    • Minimal network usage
    • Easy set up and configuration
    • Object Orientated design for performance (To come, this one is HARD)

    AND my personal favorite;

    • Dynamic response to low client/server FPS.

    Ill go over some of these in a little more detail;

     

    Standalone framework

     

    None of the code is reliant on DayZ, Epoch or otherwise. It should easily be compatible with any ARMA server or modification.

     

    Server controlled HC

     

    The HC is controlled 100% by the server. The server issues commands, monitors the HC's connection status, issues the override commands and terminates any appropriate threads. I made it this way because there will be circumstances where interaction with the HC might be desired by the admin and automation of tasks required it. This will mean that you can override a particular HC's default function from within the game environment. 

     

    Start/Stop HC in realtime

     

    As a consequence of the above, the ability to control HC's is paramount. The HC already has an inbuilt automation system (see below) but allows for manual override at any time. This means admins actively monitoring their performance can kick in a another HC and offload a task currently assigned to another HC to it. If your HC is maxing its threads, you can manually hand-off some code to another HC to cope with the load. 

     

    Assign priorities to headless client tasks

     

    Each hand-off is deemed as a HC task. You can assign priorities to these tasks to ensure peak performance at all times. If a HC is struggling with load, it will dynamically seek to remedy the issue by offloading lower priority tasks to either the server, client or another HC.

     

    Client framework for client specific variables

     

    A set of event handlers designed to handle client specific variables (player etc). This is so even client scripts could technically be handed off to a HC for processing and only the end result gets processed on the client. This should result in massive FPS improvements for clients and server alike. 

     

    Headless client automation system

     

    Each HC is controlled by the server and the server is designed to dynamically allocate tasks to available HC's. It also makes sure that they are still connected and responds appropriately if a HC disconnects without warning. It knows exactly what tasks the HC was running and tries to reallocate these tasks to an available HC, and if none are available, it hands them back to the client/server and waits for a HC to connect. Once there is a HC available, its will reallocate these tasks back to the HC. 

     

    Dynamic response to low client/server FPS.

     

    Perhaps my favorite idea, this means that the server and clients actively monitor their FPS in bursts. If these values fall below their thresholds (configurable), then the server/client will kick in and request a HC hand-off. Both clients and server will have to assign which scripts are capable of an override and assign priorities to them, but the idea is simple. When the client/server suffers - offload everything it can to an available HC.

     

    Minimal network usage/optimisation

     

    All network messages sent and received are strict - they are only issued to the machine that actually needs them. The HC system is also smart enough to know when a message is being sent by a headless client and will queue other messages until it is ok to send them. This results in far better performance and minimises the risk of duplicate messages/threads being initialised. During periods of network congestion (Perhaps an ill fated basic.cfg) it will respond by reallocating the task back to the client/server (to prevent network lag at the locality the script belongs to).

     

     

     

     

     

    Things that I want to implement;

     

    Secure script system

     

    The ability to encode your current scripts that are mission side (Buildings/AI/Whatever) so that they are harder to be stolen without your server.pbo. This will work based of UID's of the server (unsure if possible yet, its just an idea). 

     

    Online Headless Compatibility Wizard

     

    A wizard that allows you to post your current code and check for compatibilty issues with the headless framework (variables like player, addMagazine etc) and provide suggestions for how to fix the issues. 

     

     

    Github link (Coming soon)

     

    So guys and gals.... What do we think?

  16.  

     

    2014-04-11 18:41:03 infiSTAR HackLog | [EcG-B] G27 (92076998) | TP: [14233.7,17095.3,0.0014286] to [14183.5,17140.3,4.96371] (67m) | FR_OHara_DZ |DayZ Instance: 11|

    2014-04-11 18:41:04 infiSTAR HackLog | [EcG-B] G27 (92076998) | TP: [14183.5,17140.3,4.96371] to [14137.6,17182,0.0013876] (62m) | FR_OHara_DZ |DayZ Instance: 11|

    2014-04-11 18:41:05 infiSTAR HackLog | [EcG-B] G27 (92076998) | TP: [14137.6,17182,0.0013876] to [14105.6,17209.1,0.00130749] (41m) | FR_OHara_DZ (BANNED) |DayZ Instance: 11|

     

    This is a bug I have as well with the anti-teleport system. If you jump out of a chopper, it will ban you. 

     

     

     

    014-04-11 10:23:12 infiSTAR HackLog | kventin (158684102) | Exceeded Item Limit #1: 26 - (Soldier_GL_PMC @[8243.29,15505.4,0.250062]) |DayZ Instance: 11|

    2014-04-11 11:25:16 infiSTAR HackLog | jackattack (233501254) | Exceeded Item Limit #1: 27 - (TK_Special_Forces_EP1 @[6773.4,16950.3,2.64839]) |DayZ Instance: 11|

    2014-04-11 14:03:10 infiSTAR HackLog | colin (115595654) | Exceeded Item Limit #1: 26 - (Soldier_GL_PMC @[8243.29,15505.4,0.250062]) |DayZ Instance: 11|

     

    These are pretty straight forward. Change your maxcargo setting in your AHConfig.sqf. You can also try turning off anti-teleport (This didnt prevent the bans for me).

  17. In your init.sqf;

    if (!isNil "playersLoaded") then { playersLoaded = [];};
    

    In your script that executes the sound;

    if (!((getPlayerUID player) in playersLoaded)) then {
        //play sound code goes here
        playersLoaded = playersLoaded + [(getPlayerUID player)];
        publicVariable "playersLoaded";
    };
    

    In your publicvariable.txt add to the first line (The one that has 5 "");

    !="playersLoaded"
    

    This SHOULD work, but is untested as I just wrote it now :)

     

    ALTERNATIVELY!

     

    You could also optimise this to be more friendly on network traffic by using publicVariableServer calls.

     

    In your server_functions.sqf;

    if (isNil "serverPlayersLoaded") then { serverPlayersLoaded = [];};
    
    fnc_HandleLoadedPlayers = {
        private ["_vars","_uid","_owner"];
        _vars = _this select 1;
        _uid = _vars select 0;
        _owner = _vars select 1;
        if (!(_uid in serverPlayersLoaded)) then {
            serverPlayersLoaded = serverPlayersLoaded + [_uid];
            serverHasUID = true;
            _owner publicVariableClient "serverHasUID";
        };
    };
    
    "serverCheckUID" addPublicVariableEventHandler fnc_HandleLoadedPlayers;

    In your script that spawns the sounds;

    if (isNil "serverHasUID") then { serverHasUID = false; };
    
    serverCheckUID = [(getPlayerUID player),owner player];
    publicVariableServer "serverCheckUID";
    
    if (!serverHasUID) then {
        // play sound
    };
    

    This will make sure that the server only sends the network message to the client requesting it, instead of all clients simultaneously. Dont forget to add this in your publicvariable.txt;

    !="serverCheckUID" !="serverHasUID"
    
×
×
  • Create New...