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

    Hi,

    I'm working on a firing range area for our group and am using some big pop-up targets to create an AT practice range. However, these targets don't work with any AT weapons that require a thermal/IR/vehicle lock-on to fire (such as the FGM-148 Javelin in RHS) because they aren't a vehicle. Is there any kind of script, function or trick I can look at to make these targets be lockable by such weapons?

    Thanks

  3. Posted

    17 minutes ago, soul_assassin said:

    it might be true, but don't report it to the tracker. Mod supports only stable. Anything broken in devbranch or RCs will only be fixed after they become stable.

    Ok, consider that my report then. ;) I can't get any laser designation to work with RHS vehicles right now. Hopefully we don't have to wait too long for a fix as I love flying my AH-64.

     

    EDIT: If it is any help, the laser designation in other mods (3CB, BWMod) appears to be working normally. This appears to be RHS-specific and I've confirmed it with RHS alone.

  4. Posted

    Can anyone who has tried RHS with the 1.70RC confirm the AH-64 and AH-1Z self-designating laser still works? Don't want to report to the RHS tracker until I've made sure I'm not doing a dumb-dumb and missed something in all these changes.

     

    I designate a position with the laser selected, then switch to the Hellfire. The "square" appears only if I switch to the gun and cycle targets, but it won't appear unless I select the gun. And it won't lock-on regardless of what I do (pressing R or T causes it to lose the "square" indicator). Just tried a UAV laser designation and I can't lock on to that either.

     

    Am I missing a new step, or is this something broken by 1.70RC that RHS will need to fix?

  6. Posted

    On 09/03/2017 at 3:51 PM, HeroesandvillainsOS said:

    Oh no not Diyala too. :( The Kunduz thread on Steam is full with people reporting this. I haven't explicitly checked this on Diyala though.

     

    Does anyone know offhand if JBAD buildings in general have a new issue with doors? Are the new CUP JBAD ports doing it too (on Takistan, Zargabad, etc)?

    This is caused by Kunduz's version of JBAD and it affects any terrain that uses JBAD buildings. If you remove Kunduz, Diyala's doors should operate normally.

     

    On 03/04/2017 at 9:23 AM, sitrepo said:

    We are experiencing a bug where a single grenade can blow up any house. Is it just us, or does this happen to anyone else?

    Same issue here. Is there a fix definitely in the works? Whether that is Diyala switching to CUP or an update for JBAD?

    • Like 2

  7. Posted

    Hoping someone can clear up the Kestrel and its wind readings for me. I've been trying it out for use in Mk6 mortar calculations but one thing is confusing me.

     

    I switch to the headwind page and set the heading of a target (say, 235). It displays two values - the first is big and will be something like "5.3m/s" and the other is smaller and will say something like "7.3m/s @ 44". The way I understand this is the first is the wind speed along the heading I specified, and the second is the overall wind speed and direction it is going (this seems to match the Shift+K wind arrow). Am I understanding it correctly?

     

    The reason this is confusing me, is the values don't seem to behave correctly if I set the target heading the same as the wind direction. So if I set the target heading to 44, I'd expect it to give me a reading of 7.3m/s, as it is the same heading as "7.3m/s @ 44"? Yet it will say 5.1m/s or something.

  8. Posted

    On 20/03/2017 at 7:51 PM, diylani said:

     

    Yes, this means that the 32 and 64 bit enviroment is mixed up. Method 2 of this website solved it for me. Let me know how it works.

    It is Windows Server 2012 R2, so DirectX is apparently installed. No updates pending either. Ran both the .NET and C++ redistributables. I've ran Dependency Walker, and every dependency it says is missing for the x64 executable is also missing for the x86 executable. I've also reinstalled and validated the update through SteamCMD repeatedly.

     

    Still can't get the x64 version to run.

     

    Edit: Somehow got it working. All I did was run Dependecy Walker's "profiling" option which attempts to run the executable. It booted fine, and despite reboots is still booting fine. I've either somehow stumbled across the right combination of redistributables, or Dependency Walker somehow resolved the issue. Will monitor it for now and see if it sticks.

  10. Posted

    This fix didn't solve the issue for me. I've checked event viewer and it says there's a fault with ntdll.dll: 

    Faulting application name: arma3server-test.exe, version: 1.68.140.908, time stamp: 0x58ca59ec
Faulting module name: ntdll.dll, version: 6.3.9600.18438, time stamp: 0x57ae642e
Exception code: 0xc000007b
Fault offset: 0x00000000000ecdd0
Faulting process id: 0xb9c
Faulting application start time: 0x01d29fcc953fabb2
Faulting application path: C:\SteamCMD\steamapps\common\Arma 3 Test Server\arma3server-test.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: d43ac637-0bbf-11e7-80d0-08606e6952c5
Faulting package full name:

    Seems weird as the x86/32-bit server version is still booting just fine. Looked up issues relating to ntdll.dll and all I'm finding is a lot of things relating to Internet Explorer addons. It is a core Windows file as far as I can tell.

  12. Posted

    We have a few members in our group claiming that their ACRE plugin is crashing mid session. I'm trying to gather more information from them, but they are being stubborn and I can't yet rule out it just being difficulty in adjusting to ACRE (we just switched from TFAR). I've noticed pipe errors in the RPT when it crashes on mission load (a known issue that is already on your Github tracker), but not seen anything when these mid-session crashes apparently occur. If the ACRE plugin crashes mid-session should it be logging some kind of error to the RPT file? Thanks

  13. Posted

    Just want to clarify the situation with the CBA settings for servers because our group is switching to ACRE soon.

     

    I understand that the settings can be set client side, and that 3DEN mission settings can override the server settings. Are the server settings exported via CBA and then put in userconfig/cba/settings.sqf or is it going to be ACRE specific? And is there any way to prevent a mission from overriding the server settings?

     

    Thanks

  14. Posted

    There is a big difference between

    if (!local player) exitWith{ true };

    and 

     

    if ( !local _unit ) exitWith {

    hint parseText "<t color='#0000ff'>DEBUG</t><br/>EXITING - Unit not local";

    true

    };

    One is checking if player is local, another if _unit is local. so which one is it?

    Second one. First one was me surmising from memory and confusing matters in the process. It is for some reason returning as if the unit isn't local, when as far as I can tell it is only running locally (e.g. the hint it fires only appears on the affected machine). It's like the unit is momentarily not local?

     

    "local player" is true on every client, you only want the client that gets the loadout to run the script

    params ["_unit", "_loadout"];
 
if (!hasInterface) exitWith {};
 
waitUntil {!isNull player};
if (!local _unit) exitWith {};

    Will give this a go and see how it pans out. The main difference I see is doing isNull on the player instead of the _unit. EDIT: Believe that is working. Will see if it survives an op with a load of guys. :P

  15. Posted

    Hey,
    This is half mission/half mod question, so hope it's in the right place. I've made a placeable module and associated function that loads a loadout onto a given unit. The function is called via the unit's init line in the mission file, like so:
     

    [this, "pl_ptl"] call bwi_fnc_getPlayerLoadout;

    Basic stuff. This function (eventually) loads the loadout for the given role (pl_ptc) on to the unit. The problem is that before the function gets to any of the more complicated stuff (where the module comes into play) it is sometimes quitting out, resulting in a naked player.
     
    Very early on this occurred a lot due to me not properly checking if a player was loaded. This is now done using the following lines:

     

    waitUntil{ !isNull _unit };
waitUntil { player == player && time > 1 };

     

    However, this still occasionally occurs and I have tracked it back to a simple player locality check:
     

    if (!local player) exitWith{ true };

     
    At some point during the loading process, this is behaving as if the player is *not* local. However, all the information I can find seems to indicate this shouldn't be happening. This very same check is performed later in the chain, as it is included in the header of each loadout file (leftover from an older version) which seems to be giving the correct result.
     
    This is the full set of checks to determine that the player has loaded, and is local (when the nakedness occurs it exits with the "Unit not local" message):

     

    // Quit on dedicated server and HCs.
if ( isDedicated || !hasInterface ) exitWith { true };

// Wait for unit to load in.
waitUntil{ !isNull _unit };
waitUntil { player == player && time > 1 };

hint parseText "<t color='#0000ff'>DEBUG</t><br/>Player loaded";

if ( !local _unit ) exitWith {
hint parseText "<t color='#0000ff'>DEBUG</t><br/>EXITING - Unit not local";
true
};

     

    Can anyone give any insight into this behaviour? Thanks

  16. Posted

    Nice work on the F-15 firewill and really looking forward to using some of the other jets you're working on.

     

    Just wanted to let you know that the F-15 has some syntax errors that appear immediately in the RPT on game start:

     0:30:15 File FIR_F15_Cfg\module.hpp, line 229: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w2.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 230: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w3.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 231: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w4.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 232: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w5.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 233: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w6.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 234: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w7.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 235: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w8.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 236: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp2/values/hp2_w9.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 397: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp5/values/hp5_w2.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 398: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp5/values/hp5_w3.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 399: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp5/values/hp5_w4.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 400: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp5/values/hp5_w5.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 401: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp5/values/hp5_w6.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 536: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w2.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 537: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w3.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 538: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w4.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 539: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w5.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 540: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w6.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 541: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w7.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 542: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w8.value': Missing ';' prior '}'
 0:30:15 File FIR_F15_Cfg\module.hpp, line 543: '/CfgVehicles/FIR_F15E_Loadout_Module/Arguments/hp8/values/hp8_w9.value': Missing ';' prior '}'

  18. Posted

    Hey,

    It seems that TFAR is causing the main menu in Apex to get partially blocked, so only the edges of the left/right block can be clicked, and the center one is inaccessible entirely. I presume this is a relic from TFAR's prior menu enhancements. Any chance of an update removing it in the near future?

    Thanks

     

    Never mind, just noticed there's already been an update. Awesome :)

  19. Posted

    I'm interested in any information available on this (such as what needs changing in the config files). Seen it pop-up up a lot in our server logs while testing Apex, amongst many similar messages. It seems it is stopping missions from loading too. Although I've also seen some of these errors as a visible prompt on one of the vanilla MX's, which seems a bit odd.

     

    Any information from those in the know would be much appreciated though, so I can start trying to fix our mods and applying fixes to the less regularly maintained mods we use. Thanks

  20. Posted

    Can confirm we also have this issue since switching to 3DEN made templates. We have multiple Zeus slots, each named (z1, z2, z3, etc) and a module per-Zeus with the owner set to those same names. It doesn't matter which slot is entered into, if you're the first one Zeus will work. If you're the second or third person to take a Zeus slot, Zeus won't open. It can be fixed by respawning, at which point Zeus becomes functional again.

  21. Posted

    Launch your server -> login as admin -> type #missions to go to the mission selection screen -> click GAME OPTIONS button -> DIFFICULTY -> tweak to your needs -> save -> restart

    I will add to this that if you were already in a mission when you type #missions, it will be stuck on Regular difficulty and the Difficulty tab will be disabled until the next server reboot. I have discovered a workaround - select a mission and go to the slotting screen, then do #missions again and go back to the Game Options to see the Difficulty tab is unlocked again.

     

    What groups like ours really need is the ability to tell the server via the config or profile to always default to a single difficulty preset (custom or otherwise) and for it to optionally make the settings "read only". That would actually be an improvement over how it was previously.

     

    Right now the only solution I've got for members is a topic on our forums with the 23(!!!!!!) options they need to make sure are correctly set. This isn't a practical solution.

    • Like 2

  22. Posted

    You can add your own difficulty presets to CfgDifficultyPresets and then use them in the missions cycle in server config. Avoid using the name Custom for your classes, since this is a reserved one. Loading of own custom classes from the profile doesn't work anymore.

    What about those who run servers without any set mission cycle or who change missions using #missions? And if can't use the name "Custom" how do we actually set a selectable difficulty profile? Having a mission cycle is out of the question for our group, and I'm sure many others.

     

    Our group allows any member to make missions. These are loaded via the mission selection screen. For us these changes mean we can no longer set a defined difficulty because members can just randomly change/edit it. And now people need to be able reboot the server frequently because once a mission is loaded and you go back to the selection screen with #missions, you get stuck with Regular difficulty.

     

    Under the old system, we had all difficulties set the same. There was effectively "one" difficulty, members loading missions couldn't change it or break it, no reboot was required between missions. This new system, for us, has brought nothing of use and removed every tool that allowed us to control difficulty settings.

  23. Posted

    Have you had any luck in finding a solution?

     

    At a glance, we seem to have run into the exact problem you had except without the crashing. When the full presets active, clients and neither see the server in the server browser or connect. Removing any mods at random will allow both to happen.

    Not really. Unfortunately the only solution was to splash out on a license for Windows Server and use that (and it functions flawlessly with the same mods). I am certain Linux has a hidden file limit. :(

  25. Posted

    This v1.58 update seems pretty disastrous from a server admin point of view so far and also has a pretty major flaw/bug that basically requires the server be rebooted to change missions and retain a difficulty.

     

    Prior to this update our group has each difficulty set with the same custom settings in the server profile. This was done as mission makers frequently forgot to set the difficulty. With 1.58 this no longer functions on anything but the "Custom" difficulty, set via the DifficultyPresets class in the server profile. Ok, so that's a minor backwards step and people just have to remember to set it again.

     

    Except now they can also edit those settings and they get saved to the server profile. Meaning if someone makes a change (by accident or otherwise) that change is permanently saved to the server profile. I have yet to discover a way to disable this because there is no documentation on what options there are for configuring the new difficulty system for the server.

     

    The biggest problem though, and I am sure this is a bug, is that once #missions has been used from within game the difficulty options are disabled and the difficulty set to Regular. This means everytime the map is changed I have to reboot the server to have a difficulty other than Regular! If I could set what options are used for Regular difficulty like before this wouldn't be an issue, but that option was apparently taken away!

     

    How can I fix this mess? All I want is fixed options, that can't be edited and are retained between missions. The old system provided it, while the new one has turned difficulty options into a free for all server rebooting mess. Sorry if this is a bit rant-y, but I'm pissed off after spending two hours trying to guess what options I have because Bohemia doesn't document anything, and discovering what seems like a pretty huge and obvious flaw that should have been uncovered by Bohemia themselves.

×