Jump to content

ColinM9991

Member
  • Posts

    9
  • Joined

  • Last visited

Posts posted by ColinM9991

  1. @ Colin, i still have no idea wtf you're on about with cousins and disabling Bec, it's not the way forward.

     

    If you still don't know what I'm talking about then read the second sentence from my message, otherwise let's just forget about it as I don't plan on wasting time explaining the main story/excuse for script kiddy behavior on the internet.

     

    Tango; if it's because of mods you're being kicked for then activate those mods, go in to the in-game editor on any map and run this code in the debug console, then simply paste over the existing WhitelistedPatches array

    _cfgPatches = [];
    _binConfigPatches = configFile >> "CfgPatches";
    for "_i" from 0 to count (_binConfigPatches)-1 do {
    	_patchEntry = _binConfigPatches select _i;
    	if(isClass _patchEntry) then {
    		_cfgPatches pushBack (configName _patchEntry);
    	};
    };
    
    copyToClipboard str(_cfgPatches);
    
  2. Here's a thread to post in also

     

     

     

    ^ ^ Ignore everything Colin said :rolleyes: disabling Bec, what would that achive ? no working AH for starters, no scheduled restarts either ....

     

    I'm sure you're aware of everybody's cousin, you know, the guy that always hacks & cheats in servers; well as I said in my first message that "if it's a true autoban" - "simply disable bec"  ;)

     

    Although for clarity sake because I don't think you may get the full message, "if (without saying it) it is a genuine ban from script-kiddy behavior then disable BEC & possible BE because what script kiddy would want Anti Hack in the first place?"

  3. The problem is not any pathing, the problem is exactly as you say, PublicVariable restriction, I can bet its a server version rejection.

     

    Update ALL server side files including .so files (If they're available & presuming you're not using Wine)

    Along with this, try posting your PublicVariable.log file here

  4. EDIT: Please use -nologs on the server It can fix all sorts of stuff and even extend (!) the possible uptime of the server relating to the issue

     

    This simply isn't true at all.

     

     

    the server will waste CPU power and maybe even disk usage to write additional lines to the RTP or .log

     

    I'm not trying to personally attack or anything with this continuous quoting and please don't take this the wrong way, but this isn't the '90's or anything.

    How exactly will logging "waste" CPU power and disk usage? Unless of course OP is using 1xSingle or Dual core processor at 1GHz or less with a 20GB IDE Hard Drive.

    Yes; it'll 'use' CPU power (Barely a noticeable difference) & it will use Disk Writing, but "waste"?..

     

    Just for clarity sake, I do recommend disabling the netlog because that file is absolutely useless anyway since it NEVER seems to update itself and stays at 0kb.

     

    Firstly: OP, you have resolved the issue already but to mention here for anybody who has this issue during ANY update, ENSURE that you update ALL files in the latest patches.

    @EpochHive\* (All files)

    @Epoch\* (All files)

    MPMission\epoch.*.pbo (Where * here is your map name)

     

    Be sure to update all DLL files also. Otherwise you can update the files by what has increased in size, but it's best to just replace everything and don't get too edit-happy with a mod/mission like this.

     

    Secondly, -nologs fixes absolutely no errors at all, it simply disables log output.

     

    There's a 50/50 on enabling-disabling it because if you disable it then yes, you get a performance gain, but you also get no logs telling you where an error is occurring.

    Along with this it looks like you're running on a dedicated environment so is there really going to be THAT much of a performance decrease on a game that barely utilizes a full core and that can't even squeeze the most out of RAM so it stays with 2GB max?

     

    If you are adamant on setting the -nologs parameter then you could always download a logging extension and swap all server & mission side diag_logs out to use log files instead; but that would mean using callExtension more often which also means that as long as the pipe is open then you can't do anything with the server script-wise. Yes, the pipe in this case would only be open as long as the logging job needs, which may only be a few milliseconds; but this would bring a slight performance decrease too where it has to redo Epoch making calls for the Redis database.

     

    So the point here is, don't get tied down on server performance with ArmA. It's a horribly optimized game which we all know, and trying to get the best performance is going to drive you crazy when everything you do is going to decrease performance more and more.

     

    P.S; I can see that your RPT has Warning Messages and what not; while it doesn't fix any issues, it is usually best to resolve these or clean out any content that isn't being used anymore for 2 reasons.

    1: Who doesn't love clean logs? - Posting for help with a 'dirty' log will throw people off and prolong the "investigation" or the fix

    2: Kind of said it in #1, but clean logs make things MUCH easier & quicker to diagnose & resolve if there are issues

  5. Could you please submit a ticket on our tracker if you haven't already?

     

    The problem here isn't the public variable PLAYER_REJECT_ServerVersion, although that shouldn't have to be whitelisted.

    PLAYER_REJECT_ServerVersion is happening because it's recognizing the server files as out of date.

     

    I already have a fix for this, however I'll need you to submit a ticket so I can grab your account details.

     

    I you have submitted a ticket and I have responded already to mention that I've fixed it then disregard this.

×
×
  • Create New...