Could you please give an update on that ticket ?

I was unable to reproduce the issue. Please upload the RPT file from session where you had the issue.

Is there some way to change the UI back to vanilla while still having S.O.G. Prairie Fire enabled?

After more testing, the Radio Support Module Transport doesn't work on dedicated server whether it's the performance/profiling binary or the vanilla binary.

I had issues when using the performance/profiling binary. Which binary are you using?

Sirloin, I'm seeing issues with the Radio Support Transport module as well. Did you find-out anything more in your testing?

I've heard that getting downed, and then reviving also clears this bug... which isn't a fix, but a workaround.

Additionally, I have a white dashed circle just below my crosshair with a translucent grey background in the middle of it. It looks like a bombing reticle. It's part of the same system. I tracked it down to one of the first two functions in: .\config\ui\hudShared\shared.hpp I didn't have time to go through it with a fine tooth comb, but when I comment out any of the first two functions, it just breaks the game (as expected).

The video with two airframes is 34 seconds long. I only meant to show this one, but I uploaded the short one by mistake. Here is the correct video. NOTE: Both videos showcase the issue. The first one just shows it on the Cayuse.

Same issue: Mi-2 AI crew won't fire any weapons except the door guns, and seem to have trouble flying in general. Armed UH-1s are fine.

Can't be replicated.

Both M60s are firing but due to a engine limitation it's not possible to have duplex tracers on a machinegun turret on a helicopter (UNLESS we make them as gunpods, which means no gas fx and no shellejection fx which are more important for these guns than say the external swivelmount m134s).

The modified gas block on SOG:PF M14A1 is solely to have the sling appear attached to the proper swivel - real-life M14A1 uses same gas block as the regular M14, and the different part on the SOG model is in fact the clamp mechanism of M2 bipod, which fits both variants of M14 rifle. Solution number two (separate bipod entity for M14) would be preferred.

Since patch 1.2 added M14A1 rifle, it might be interesting idea to allow it to use same optics as the M14/M21. That's because M14A1 was also used in a sniper guise in Vietnam. Used in very limited numbers by LRP company of 4th Infantry Division these rifles ditched the heavy M2 bipod (replacing it with a M16 clamp-on bipod), and (as evidenced by one surviving example) had the front-grip assembly removed, with a more traditional sling swivel appearing in it's place. They still had the pistol-gripped stocks and characteristic muzzle devices.

Regarding the sight appearance, it's something that people requested when SOG was released. IMO it should stay.

I have to disagree. Yes, it does look iffy (especially on the Garand), but it's what people wanted when the DLC first came out. Current version, despite the looks, performs more like real-life sight - until devs implement some other solution to the ironsight problem it should stay.

That is unfortunate but thank you very much.

Unfortunately, it is not possible, BI function will always use weapons assigned to gunner and this gun is not a pylon so it can't be reassigned.

Yes that works great. Thank you for the clarification.

Sorry for the inconvinence, it's related to the Huey fleet update. BIS_fnc_UnitCapture does not save which turret fired the weapons, during the playback it always tells the vehicle gunner (gunner _vehicle) to fire the weapons. After the updates the vehicle copilot is considered the vehicle gunner (can be recognized by the icon in 3den).

Understood! Will adjust my missions accordingly, thank you!

It probably worked but not exactly as intended as you weren't able to adjust the score that way. It was always intended to be NAME of VARIABLE that holds the score. Not the score value, as per comment in config/wiki documentation.

Setting the cost_variable to "arty_score" and then adding "arty_score = 150;" to the init.sqf worked, before I was able to do it by just setting "arty_score" to "150" in the description.ext but I suppose that isn't possible anymore? Or else I was dreaming before..

Unable to reproduce the issue, make sure your variable contains number not some other type.

I'm running into the exact same issue when trying to host the server in a Docker environment.

As a workaround, running the Windows server in Wine works just fine.

Yep, that did the trick! Thank you!!

When delay_max attribute is missing from the main config it defaults to 0, thus instant fire support. Add it with default value of 90 and it should work fine. I will try to fix it for our next update, sorry for the inconvenience.

Can confirm that adding the magazines directly using setPylonLoadout works perfectly fine but in the Master Arm module things gets iffy.

In T166554#2338485, @Bob_Murphy wrote:

Thank you for your feedback! It will now be reviewed by a specialist in our internal QA system.

The radio module is well outside my mission area. As you can see in the video, the rounds drop before the dialogue is finished. The code in the description.ext is the code from above, and it's worked just fine until yesterday. Opening a new mission and putting down a radio module and not customizing the description.ext in any way, of course, works perfectly.