fourjays

There is a pretty serious flaw too. As a server admin, if you use #missions once a mission has been loaded, the difficulty gets reset to Regular and the ability to change it is disabled. Server has to be rebooted to change difficulty.

The M136 and SMAW that took 4-6 rounds were both the CUP versions (not RHS), but I'll give the RPGs a go. I'm less concerned about the number it takes to destroy the T-72 and more that it doesn't get disabled very easily. The HUD for the hull/turret/etc stays all white and typically only changes to orange or red just as it is about to cook. I'll test it some more. So our group has been trying to track down the cause of an unusual bug with the UH-1Y (transport and MEV variants only) where when it is first spawned via Zeus it will "freak out" with parts of the model contorting and jumping. We are having a very hard time tracking specifics as this only seems to occur the first time an individual player spawns the helicopter - all subsequent spawnings, even following game or server reboots, will function normally. If you get into an affected helicopter while in multiplayer (not singleplayer), the game client will also crash. I was going to submit it to your bug tracker (let me know if you'd prefer that), but due to the once-and-never-again nature of the bug, I've not been able to figure out if it is a pure-CUP issue or some sort of compatibility issue with another mod (we have none that directly interact with helicopters though). One of our members recorded a video of the bug, took screenshots and saved his RPT.

First want to say our group is really enjoying the CUP content so far, particularly the vehicle variety we now have. Just wondering, if anyone else is finding the T-72 a bit too strong? It is taking around 4-6 rounds (all rear shots) from an M136 or SMAW, with a disabled state being kind of rare (out of three tanks only the one I hit in the front had orange hull damage). For comparison's sake, if I use an RHS launcher against the CUP T-72, it takes up to 10 M136 rounds. Meanwhile RHS T-72s will be disabled in one hit and killed in three, regardless of whether it is a CUP or RHS launcher.

I've got the win64.dll in the Teamspeak 3 plugins folder. All pbos in the Arma 3/@acre2/addons folder (both server and client). Anything I've missed? Only other thing I can think of is we're running latest CBA (v2.3.1).

Yes, I've got it maxed out. Also tried adjusting various in-game audio sliders. It is the same for another member who tried it with me. I remember having a similar issue with TFAR, caused by not copying a bunch of sound files in the Teamspeak 3 plugins folder. Is there anything similar for ACRE (can't see any in the downloaded zip)?

Hey, I'm evaluating ACRE for our group to potentially replace TFAR. One obvious thing that isn't working for us right now is the beep/tone/noise that I believe should occur when the PTT is pressed and released (see this video for example of the noise I'm referring to: https://youtu.be/bO78fK2lauU?t=2m10s).The message is still transmitted, just no audio indication with any radio. Any idea on how to solve this? Thanks

When I start a mission using ALiVE and the latest CBA, no slots appear at the "slotting screen". Simply removing the ALiVE module from the mission allows it to function normally. Mission is made using the 3D editor (not tested a 2D one yet). Is this because of the previously mentioned incompatibility between latest CBA and ALiVE? Thanks

Already running with -noSound. Why it does InitSound with sound disabled is a mystery. :P But the issue behind this crash was solved by increasing the ulimit. The problem now is no clients can connect unless I reduce the number of files, as if there is a secondary limit in play.

Thanks for the replies, but unfortunately neither apply in this case. We already have signature verification off and whenever the mods are put on the server I run a small script that lowercases all of the files (doesn't even boot up unless I do this).

Ok, thanks. I thought it may be something I was doing wrong, so didn't want to post something to the tracker that I wasn't sure on.

It's just a macro for quicker/simpler config writing, as in the Arma documentation (https://community.bistudio.com/wiki/Arma_3_Characters_And_Gear_Encoding_Guide#Backpack_configuration). The config is quite huge, so put it on pastebin: http://pastebin.com/WBtDrTEa

Hey, I've got another potential bug for you guys but want to verify I'm not doing something wrong first. So I've been making some custom ammoboxes for our group to provide more "sensible" contents based on the size of the box. Everything so far seems to have worked except for a box containing the RHS RPG-7V2 rounds. Whatever I try, the rounds will not appear in the box on their own. They only appear if I add the RPG-7V2 launcher to the ammobox, and only then the rounds that seem predetermined to come with it (when checking the inventory) and no more. On checking the in-game UI for editing the ammobox contents, the RPG7V2's rounds are not listed and can't be added independently of the weapon. This also occurs with the RHS AFRF ammobox. I'm using the following config for the ammobox and believe all the classnames to be correct: class BWI_Box_Ammo_MAT_RU: IND_Box_Base { scope = 2; displayName = "[BWI] Medium AT Ammo (RU)"; model="\A3\weapons_F\AmmoBoxes\WpnsBox_large_F"; icon="iconCrateLong"; /*class TransportWeapons { MACRO_ADDWEAPON(rhs_weap_rpg7,2); };*/ class TransportMagazines { MACRO_ADDMAGAZINE(rhs_rpg7_PG7VL_mag,2); MACRO_ADDMAGAZINE(rhs_rpg7_PG7VR_mag,2); }; }; Any thoughts on a potential cause? Verified it occurs with the latest version of RHS as well. Thanks

Got one of our members to make a video of it. Can find it here: https://youtu.be/PhCVvnz8vKc Have posted a bug report to your tracker here: http://feedback.rhsmods.org/view.php?id=1822 Thanks

Thanks for the quick replies, will pass it on.

Done more testing of this. It happens on Statis too, again with RHS only. It doesn't happen everytime, but it happens most times. It behaves as if there is some kind of speed limiter or it is stuck in gear, because the truck hits about 20km/h and just won't go faster. If you go downhill it will struggle to get above 30km/h, after which it behaves as normal, until it next dips below 20km/h.

Hey, Our group has recently started using ALiVE for our missions. We're enjoying it a lot so far, but have had some difficulties with hostile AI reinforcements. Specifically, that anytime we use armor the enemy will suddenly spawn in a number of attack helicopters. According to our mission makers, they are placing the logistics module and setting the helicopters to not spawn, yet this keeps occuring. Any ideas on how to stop the helicopters being spawned in? Thanks

Tested on Altis roads just north of the main airfield. I tested it with just RHS and no other mods at all (I suspected it to be All in Arma, but it doesn't look that way). I'll double check again later today and try Stratis too.

Hey, Our group has had a long suffering issue with the RHS RG-33s (MRAP) and the US trucks. In the virtual reality they'll happily drive at 90km/h, and off road they can push 60+km/h. However, on road they're both topping out at around 20km/h, and struggle desperately up hills (it is faster to get out and run). I've tested it both with just RHS (no other mods) and with the newest version of RHS. It seems odd that nobody else seems to experience this, yet I can't find anything responsible for it beyond RHS itself. Any solutions? Thanks

We run both on a Linux server, but have not yet updated to latest RHS. I doubt there is anything new in RHS that would prevent its use on Linux servers. Check the file permissions (chmod, chown) and see what errors the server gives when it tries to load RHS.

Thanks for the quick response. It still wants to delete task_force_radio though. I'm using the Linux command line version and entering it at "Add folder path to exclude extra local content when sync (leave blank to pass):" which seems to be the corresponding command line option. I enter the path /home/user/test/userconfig, it then repeats the question and I press enter again. It then proceeds to build. But it is still wanting to delete the folder client side and none of them are marked (hidden).

Can anyone explain how to get the "Repository folders with excluded extra local when sync" option to work? I've got a userconfig folder that needs to contain asr and ctab. Meanwhile task_force_radio is being handled by the TFAR installer within Arma3Sync. What happens as things stand is the repo deletes task_force_radio, then the TFAR installer puts it back, the repo deletes it, TFAR puts it back, etc. I gather I need to exclude this folder via the above option, so on the repository server (Linux) I tell it to exclude the folder /home/user/test/userconfig/task_force_radio, however it still wants to delete task_force_radio when checking the repo in Arma3Sync locally. I've tried using relative paths, but it always says they don't exist until I specify a directory that actually exists on the server. If I tell it to "hide extra local content" on the clientside, it just resets itself to not-hidden as well. If it is relevant we are not using the auto-config URL and are instead doing a manual connection. Thanks

I've successfully setup the Linux Arma 3 server on our dedicated box (been working really well so far) and am now trying to get a headless client running on it as well. I can get a HC connected remotely (from my PC to the server) and it looks like I can get the HC running on the dedicated server (connect to a different server), but have so far been unable to get the HC to connect to the server on the same box. It appears the client can't connect properly because the ports it wants to use (2302-2304?) are already in use by the server instance of Arma 3, so the client can't even use them to connect. I get the following error: I am starting the headless client with the following parameters (127.0.0.1 has been added to the headless and local client config options): Any ideas?

Thanks for the quick work on your great mod, much appreciated.

Not sure if this is still in development, but it looks like the Nexus update has broken the vests along with those in other mods? In case you're not aware, the vests behave as if they don't exist and it only takes one shot to kill the wearer (the vanilla vests are unaffected). Just wondering if you have any plans for an update to address this? Thanks

So it seems the Arma Nexus update has broken vests across many of the mods we use including the ones in the 3CB pack. They basically behave as if there is no vest at all - one shot, one kill. The vanilla vests work normally, taking multiple shots. Is there any timetable for an update to fix this? Thanks