Jump to content
Bohemia Interactive Forums

fourjays

Member
 View Profile  See their activity

  • Content Count

    82

  • Joined

  • Last visited

  • Medals

Posts posted by fourjays

  2. Posted

    To those having issues with radios cutting out unexpectedly in an op, our group used to have this problem too. The fix, as someone already suggested, was to run with the terrain coefficient set to 0. However, since ACRE released the new "Signal Mode" option we have switched to the "Simple LOS" option which allowed us to set the terrain coefficient back to its default value. We've been running 20-30 player operations daily for a few months now with this mode and it has been fantastic. I posted our working CBA settings on the ACRE Github here: https://github.com/IDI-Systems/acre2/issues/264#issuecomment-598664706

     

    @ACRE_Team It looks like Teamspeak have released version 3.5.0 with a new plugin API version. Do you know if we need to wait for a plugin update?

    • Like 1
    • Thanks 3

  3. Posted

    Last night we did op preparation like we would any other night. Zero idle kicks. So looks like setting votingTimeOut, roleTimeOut, briefingTimeOut, debriefingTimeOut and lobbyIdleTimeout to -1 disables it. The odd thing is the kickIDs don't seem to match the documentation as I explained above. However, as we barely ever use admin kicks in our group we have that set to a short timer for now. Hopefully the kickIDs can be better structured in the future so that manual kicks can be made more permanent without them applying to the fairly common signature check failures too.

     

    Our final config is as follows: 

    kickTimeout[] = { {0, 60}, {1, 30}, {2, 60}, {3, 30} };
votingTimeOut = -1;
roleTimeOut = -1;
briefingTimeOut = -1;
debriefingTimeOut = -1;
lobbyIdleTimeout = -1;

    Hopefully that helps other groups out.

    • Like 1
    • Thanks 1

  4. Posted

    57 minutes ago, Dwarden said:

    @fourjays from what i gathered that are unforeseen consequences values 😉

     

    it may work but who knows what those breaks (i hope they work, saves me headache)

    This might be an unforeseen consequence, or a documentation issue, but it seems that signature checks are not being handled under "kickID 3" as the Wiki suggests but instead "kickID 1". With the same config as above, we just had a member (Cerven) join the server a while after a signature check failure, only to get the "until mission restart" kick. If the documentation is right this should be a 30 second timer with the above config.

      

    16:20:41  > Player [CPT.] Cerven connecting
16:20:42  > Player [CPT.] Cerven connected
16:23:15  > Player [CPT.] Cerven: Signature check timed out
16:23:15  > Player [CPT.] Cerven kicked off: 
16:23:15  > Player [CPT.] Cerven disconnected
17:14:28  > Player [RCT.] Polarium kicked off, Steam ticket check failed: Steam authentication failed.
17:14:28  > Player [RCT.] Polarium disconnected
17:14:32  > Player [CPL.] Caitlyn disconnected
17:19:58  > [CPT.] Cerven uses modified data file
17:20:02  > Player [CPT.] Cerven connecting
17:20:02  > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart
17:20:02  > Player [CPT.] Cerven disconnected
17:20:21  > [CPT.] Cerven uses modified data file
17:20:25  > Player [CPT.] Cerven connecting
17:20:25  > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart
17:20:25  > Player [CPT.] Cerven disconnected
17:22:56  > [CPT.] Cerven uses modified data file
17:23:00  > Player [CPT.] Cerven connecting
17:23:00  > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart
17:23:00  > Player [CPT.] Cerven disconnected
17:27:23  > [CPT.] Cerven uses modified data file
17:27:27  > Player [CPT.] Cerven connecting
17:27:27  > Player [CPT.] Cerven kicked off: Due to how the server is set up you are not allowed to connect until mission restart
17:27:27  > Player [CPT.] Cerven disconnected

     

    It could be related to the -1, but that side does appear to be working so far. Not seen any idle kicks at all since setting that. I've asked members to not avoid it tonight to try and make sure.

  5. Posted

    It looks like setting those variables to -1 might disable it. At least, we didn't experience any idle in our operation last night with the following settings: 

    kickTimeout[] = { {0, -1}, {1, 30}, {2, 180}, {3, 30} };
votingTimeOut = -1;
roleTimeOut = -1;
briefingTimeOut = -1;
debriefingTimeOut = -1;
lobbyIdleTimeout = -1;

    Could also be that it didn't occur because our members are now pushing through quickly just to avoid the idle kicks.

  6. Posted

    3 hours ago, Dwarden said:

    @Dedmen ,

    @LSValmont ,

    @churrofighter ,

    @Bosenator ,

    @Farantis ,

    @fourjays ,

    @.kju

     

    in server.cfg just increase the

    votingTimeOut , roleTimeOut  , briefingTimeOut , debriefingTimeOut  , lobbyIdleTimeout

    beyond default values of 60, 90, 60 ,45, 300

    e.g. to 65535 or 604800 seconds

     

    then also disable the kickTimeout (atm. i'm unsure if value of 0 works, needs to be tested)

    kickTimeout[] = { {0, 0}, {1, 0}, {2, 0}, {3, 0} };

    or use 1 second timeout

    kickTimeout[] = { {0, 1}, {1, 1}, {2, 1}, {3, 1} };

     

    those settings are also documented on the BIKI https://community.bistudio.com/wiki/server.cfg

    Setting the kickTimeout values to 0 does not appear to work. It results in the same as -2 (kicked until server reboot).

     

    We're checking to see if it is already implemented, but would be good if lobbyIdleTimeout, etc could be set to -1 to disable it entirely.

  7. Posted

    On 4/16/2019 at 4:07 PM, Dwarden said:

    1.90.145599 new PROFILING branch with PERFORMANCE binaries, v10, server and client, windows 32/64-bit, included linux 32-bit server+

    + more fixes for administrative features in previous build 1.90.145586

    ... for details about those see 1.90.145575 build post

    + new server.cfg settings votingTimeOut, roleTimeOut, briefingTimeOut, debriefingTimeOut, lobbyIdleTimeout

     

     

    https://www.dropbox.com/sh/582opsto4mmr8d8/3BSy9PdRGm

    https://drive.google.com/folderview?id=0B03-H4YIbhkFMUt5RzNqZjFlNGs


    available via STEAMclient/STEAMcmd as branch too,

    read https://community.bistudio.com/wiki/Arma_3_Steam_Branches#Arma_3_Server

     

    BIForum feedback: https://forums.bistudio.com/topic/160288-arma-3-stable-server-184-performance-binary-feedback/?do=getLastComment

     

    Arma anything discord:  https://discord.gg/arma

    Can the roleTimeout, briefingTimeout, debriefingTimeout or lobbyIdleTimeout be disabled in any way? While these settings are probably great for KOTH servers, they are already a major headache on our group's coop server. Our typical operation starts with organising members into roles on the slotting screen until all necessary roles are filled, then proceeding through to a spawn area where the mission is planned. These settings are kicking members who are just waiting for us to get ourselves organised.

     

    Additionally, is there any idle timer running once in-mission? A couple of our members have been kicked after going all the way through with messages indicating that it is again an idle timer. They probably were idle (people often go AFK at this stage) but this isn't something we want. Thanks

    • Like 1

  10. Posted

    First of all, thanks for another awesome 3CB mod. 👍

     

    Just wanted to give a small bug report - it seems the T-34 is not being drawn beyond 300m unless you zoom in (right-click zoom or magnified optics). Other tanks in the pack appear normally above 300m ranges.

     

    EDIT: Divaya beat me to it. 😅

  11. Posted

    I have been looking at VCOM AI (mod) for our group and am overall really impressed with it. I've had a few bugs with 3.1 that are fixed according to the changelog for the 3.2 pre-release, so I was eager to give that a go. However, while a load of options appear in CBA's Addon Options with v3.1, none appear at all with v3.2 (in editor, single player or while running on a dedicated server). Is this a known bug with the pre-release? Thanks

  12. Posted

    3 minutes ago, Sandro Saitek said:

    How can i downgrade my version to 1.86... ?

    Think you mean 1.84? But it would be:

     

    1. In your Steam Library right-click on Arma 3 and go to Properties.
    2. Go to the Betas tab.
    3. In the "Enter beta access code to unlock private beta" field enter: Arma3Legacy184
    4. Click Check Code. It should now say that the code has been accepted.
    5. In the select list above the code field, you should now be able to select "legacy - Legacy Build (1.84)".
    6. Click Ok. In the library it should now say "Arma 3 [legacy]" and it will begin downloading the rollback.
    • Like 1
    • Thanks 1

  14. Posted

    2 minutes ago, [hud]dorph said:

    wow if all modders needs to update their sigs we are in trouble for a long time ahead :[

    Yea. While our group doesn't use mods that are no longer maintained, I know a lot do, and there's a lot of mods that will never get new keys.

     

    Hopefully it is a small oversight on BIs end and will be fixed soon.

  16. Posted

    While our group really likes both NIArms weapons and JSRS, we don't use large quantities of the NIArms weapons and only have the (rather large) All-in-One pack for the JSRS compatibility.

     

    Is there any possibility of the NIArms compatibility PBO being broken up to match the individual weapon packs? E.g. compat_aks.pbo, compat_m4s.pbo, compat_g3s.pbo, etc.

     

    Or if that is not possible (I appreciate it may be a lot of effort), is the source code for the compatibility files available anywhere so I could build our own PBO with just the packs we use?

     

    Thanks

    • Like 1

  17. Posted

    Ok, solved it. Answer was that requiredAddons needs to have cba_settings defined. The UI errors are because of the way I have RscText, etc defined within the mod. Now have to figure out how to inherit RscText, etc instead, whichever for whatever reason has never worked the way I'd expect it to based on other inheritances in Arma. But that's nothing related to CBA.

    • Like 1
    • Thanks 1

  18. Posted

    I'm trying to add a custom CBA setting to handle something new I'm doing in one of our groups mods. I've followed the instructions here on how to add your own settings, yet they never appear in-game.

     

    In my config.cpp I have added the event handler like so: 

    class Extended_PreInit_EventHandlers {
    class bwi_armory {
        init = "call compile preprocessFileLineNumbers '\bwi_armory\XEH_preInit.sqf'";
    };
};

    With requiredAddons set as follows: 

    requiredAddons[] = {"A3_Modules_F", "A3_UI_F"};

     

    And then in the XEH_preInit.sqf file I have the following code: 

    diag_log 'BWI Armory PreInit...'; 

[
    "BWI_Armory_Test", // Internal setting name, should always contain a tag! This will be the global variable which takes the value of the setting.
    "LIST", // setting type
    "Test", // Pretty name shown inside the ingame settings menu. Can be stringtable entry.
    "BWI Armory", // Pretty name of the category where the setting can be found. Can be stringtable entry.
    [
		["A", "B", "C"],
		["A", "B", "C"],
		0
	], // data for this setting: [min, max, default, number of shown trailing decimals]
    1, // "_isGlobal" flag. Set this to true to always have this setting synchronized between all clients in multiplayer
    {  
        params ["_value"];

		hint format["Armory says %1", _value];
		systemChat format["Armory says %1", _value];
		diag_log format["Armory says %1", _value];
    } // function that will be executed once on mission start and every time the setting is changed.
] call CBA_Settings_fnc_init;

    The RPT has the diag_log message logged, so the XEH_preInit.sqf file is firing correctly. But CBA_Settings_fnc_init doesn't appear to be doing anything (no setting, no errors, no logs). All of the settings from ACE/BWA/STUI appear normally, so I don't think the problem is with CBA itself.

     

    I read in an issue that it could be caused by starting Arma with -world=empty, but I've always run with that and settings from other mods appear without issue. Tried it anyway, and it makes no difference.

     

    I looked through how bwa3_navipad handles it to see if I was missing something (as it's a much simpler mod to understand compared to ACE's macro mess). Other than the script_macro.h/script_component.h/xeh_prep.sqf files I don't see anything. I looked through the code in those files and all I see are constants defined for the UI elements and macros for logging errors.

     

    Checking in Extended_PreInit_EventHandlers in Config Viewer, I see no difference in the resulting init line that is being set compared to the ones for ACE/BWA.

     

    I tried the same implementation in a mission file instead (description.ext + XEH_preInit.sqf), and that works fine once the mission is run. The settings set via the mod still don't show though.

     

    Can someone offer any advice here? The instructions on the CBA site make it seem so easy, yet I'm getting nowhere and can't see what I'm missing.

     

    EDIT: Forgot to mention that adding "cba_settings" into requireAddons results in errors about UI elements as soon as the game starts. There's a lot, but they're like this: 

    14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.textureNoShortcut'.
14:08:37 Warning Message: '/' is not a value
14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'.
14:08:37 Warning Message: No entry '.left'.
14:08:37 Warning Message: '/' is not a value
14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'.
14:08:37 Warning Message: No entry '.top'.
14:08:37 Warning Message: '/' is not a value
14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'.
14:08:37 Warning Message: No entry '.right'.
14:08:37 Warning Message: '/' is not a value
14:08:37 Warning Message: No entry 'bin\config.bin/RscDisplayMain/controls/TitleSingleplayer.HitZone'.
14:08:37 Warning Message: No entry '.bottom'.
14:08:37 Warning Message: '/' is not a value

     

  20. Posted

    @Dwarden We've got to the bottom of what is causing our Zeus CTDs. It is one of our own mods, but I also believe it might ultimately be a bug in Arma. We have a "respawn template" that deletes dead bodies in the spawn area. This runs "onPlayerRespawn". It seems that the Zeus CTD occurs for any Zeus whose character's FOV sees the body of a Zeus get deleted. Non-Zeus player's do not trigger the crash at all.

     

    Hope that helps in some way.

  21. Posted

    On 16/10/2017 at 12:10 AM, dwarden said:

    @fourjays

    tried new profiling branch performance binary from last week ?

     

    also crashdumps will be useful

    Sorry for the delayed reply. I posted this just after the op where we discovered it, and mid-op I switched to the latest performance binary to see if that fixed it, but it did not. If there's newer ones I'll give them a go tomorrow.

     

    Might have more information from tonight's operation. The Zeus reported that it occured when anyone died within his characters FOV (not Zeus camera FOV). So if someone dies in Zeus camera, it is fine, but if they die within the FOV of his player character (even if it isn't in Zeus camera at the time), they get a CTD. We believe this also explains our prior issue where Zeuses respawning kicks the other Zeuses, as we were all standing close to each other.

     

    We'll test it further and try to narrow it down to just being base game Arma 3 as we run with a lot of mods. In case these are useful regardless though, these are the RPTs/crash dumps we have so far. One from myself on the 15th October (https://www.dropbox.com/s/bykp90roqfwxno7/fourjays_arma3_x64_2017-10-15_22-32-10.zip?dl=0), one from the Zeus who experienced the issue tonight (https://www.dropbox.com/s/1mqtumhebnhajuq/0mega_arma3_x64_2017-10-21_20-08-58.zip?dl=0).

    Thanks

  22. Posted

    Good that the Zeus crash on map opening was fixed, but our group is facing a new crash with the latest hotfix. If there's 3 or more Zeuses, and 1 respawns (via menu, script or plain old death), it will almost always result in the other 2 experiencing a CTD (not the one who respawns). Coupled with the still un-fixed Zeus-not-opening-until-they-respawn bug means that we can't have more than 2 Zeuses at all in our operations right now. :(

     

    Has anyone else experienced this or have any information to help narrow it down?

  23. Posted

    On 21/06/2017 at 11:48 AM, tRiKy_ch said:

    last night i've found a >700mb log on my server, then went to our FOB and i see someone has spawned a M113

    so i'm 100% sure that M113 is the cause of this spamming

     

    fyi, i sumbitted a ticket on rhs bugtracker http://feedback.rhsmods.org/view.php?id=3369

     

     

    Thank you! I've been trying to find the cause of this issue for months then stumbled across your post and confirmed this was what was causing it. All along I've been thinking it was something wrong with the server hardware or setup. Wonder if RHS will actually fix it.

  24. Posted

    Are the engines of the vehicles you are targeting turned on? Since 1.70 it seems that the thermal signature of a vehicle is actually taken into account, so cold targets aren't lockable.

     

    We're having a problem with laser locking though. Can turn the laser on, can lock onto it, but the missile will not follow the lock and instead goes straight ahead. Almost every laser-capable missile in Arma has the issue since 1.70 - in the case of RHS it is because the hellfire inherited from a class that was changed in the Jets DLC update (although the RHS helicopters can't even lock without a fix). Could it be something similar here?

×