distractor2004

Providing an update and possible closure on this topic. I posted the feature request to BI's tracker and was kindly provided the following feedback: "The majority of Arma's performance issues are not rendering related. Lowering resolution very rarely has any impact. We thought about FSR/DLSS and found it to not be worth the effort.". Im not sure if implentation could still be possible through modding as it may be outside that scope & licensing, but I do not believe the Streamline tech would be officially implemented at this point by BI for Arma 3. Fingers still crossed for Enfusion though. Here is a link to my post for any future reference and to minimize duplicate requests: https://feedback.bistudio.com/T163936 Thank you.

Ah I see there's a "Feature" selection in the Severity category. I'll repost this topic today. I was thinking that site was only for bugs but thank you for pointing it out!

Greetings, I would like to request ARMA 3 developers review the Nvidia Streamline plugin framework for possible implementation into ARMA 3 and Enfusion. If there is a better channel to make this request than a general topic then I'm all ears. 🙂 Nvidia has recently announced its open-source Streamline technology. Based on my interpretation, the plugin would allow DLSS, XeSS, and FSR to run on any Direct X 11 or DirectX 12 game. Here is the link to Nvidia's site: https://developer.nvidia.com/rtx/streamline The actual framework has been posted by Nvidia on github for anyone to review: https://github.com/NVIDIAGameWorks/Streamline And a guide on how to implement DLSS into a DirectX 11 or DirectX 12 game: https://github.com/NVIDIAGameWorks/Streamline/blob/main/docs/ProgrammingGuide.md While I am unsure how much work would be required to integrate this plugin, it appears to require much less efforts and minimal cost than recoding of game libraries for DLSS or FSR 2.0. Also according to Nvidia, the plugin can run with games based on DirectX 11, which I believe is what ARMA 3 uses. I am hoping this sounds like a feature request that would not only benefit ARMA 3 performance but may also be included in the Enfusion engine too for future releases. The caveats so far is that this plugin only works with Nvidia gpus at the moment, but this appears to be due to the tech just releasing and can be expanded to non-Nvidia gpus due to its open-source nature. Original Source: https://www.pcgamer.com/has-nvidia-just-become-the-good-guy-in-the-whole-dlss-vs-fsr-vs-xess-debate/ Thank you.

Addon/Feature Request: Lingering Battle SFX Greetings amazing ACE mod team (or anyone else who would care to take a look and create a separate addon)! Request is also posted to ACE GitHub Feature Request comments. I am requesting/proposing a feature that would generate battle effects created from varying degrees of gunfire and explosives. The inspiration comes partially from a feature in the Arma 2 SLX mod suite that generated lingering ambient dust based on the volume of gunfire in a certain area. Further inspiration would also come from the smaller fire effects created by mods such as BlastFX and the Ace mod itself when a vehicle is destroyed. I refer to the area that particles are determined to be generated as a Sphere Of Action, or SOA. The amount and lifetime of the particles would adjust for performance based on the size of a particular SOA and overall number of SOAs. All particles would be attached to non-interactive objects, such as buildings, terrain, and wrecks, which will compliment any particles generated by interactive objects, such as vehicle engine smoke or ammo cookoffs already present within the Ace mod. The fire particles would be visual/non-damaging only, while possibly only some of the dust would block the view, or be so thin that it is also just for visuals. PARTICLE TYPES AND EXAMPLES OF USE: All particle lifetimes and sizes would be based on the volume of gunfire in a short amount of time and small space or various types/multiple explosions. Various amounts of lingering dust (volumetric maybe?) that varies in size and lifetime. The dust would be spread out between larger SOAs and be removed altogether or not generated at all from smaller SOAs if they are within the area of larger ones. Lingering small fires and smoke pillars. These could be assumed created from single grenades or a high volume of bullets within a small are, and would also be the last lingering effects of HE explosions. Large smoke pillars. These would be generated from heavy explosives, such as HE artillery and tank shells, IEDs, satchel charges, RPGs, or a high volume of grenades within a confined area such as an alleyway or interior. Low volumes of non-HE gunfire below a certain caliber would not generate particles, so precision shots from snipers or single fire pot shots may not generate anything, but unloading an AR or MG, or even mag dump from an SMG, within a small area, or a single shot of large caliber incendiary/HE ammo could cause small fires and smoke. A high volume of non-explosive bullets from a fireteam may cause a small fire or two, but would definitely stir up dust around the area of impact. SUGGESTED SCRIPT PARAMETERS AND USER CONFIGURABLE PARAMETERS: Similar to other features in ACE, a user should be able to tweak various parameters that adjust between best performance and best visual quality. Some suggested parameters may include but are not limited to: Lifetime of large smoke pillars. Lifetime of lingering dust. Lifetime of small smoke. Lifetime of small fires. Max amount of each effects generated. Max amount of SOA's generated containing effects. A flag or adjustment for maintaining a minimum amount of particles throughout there respective max lifetimes within the combined number of SOAs. An adjustment for dust density, density dissipation lifetime, and whether dense dust will affect AI visibility. To maintain ambience when the maximums limits are reached, I think it would be best to reduce particles among all SOAs rather than just delete an entire SOA of particles, and that the highest volume of new particles would be generated within the newest SOA near a player or team. There should also be a prioritization of which and how many particle types are deleted first. Perhaps a method of prioritization would be for smaller/newer/nearer SOAs to take particles from larger/older/more distant SOAs, and for larger/newer/nearer SOAs to take particles from smaller/older/more distant SOAs. EXAMPLE SCENARIO: For example, let's say part of a town is shelled prior to a player's team moving in. The initial SOA, SOA1, would generate all types of particles, so there would be large smoke pillars, lingering dusk, and numerous small fires with there own small smoke pillars within the blast radius. When the team moves into the village, they encounter an enemy team and a firefight ensues, creating SOA2. Some of the small fires from SOA1 are removed and concentrated into the smaller SOA2 created by the firefight due to bullets and grenades. The ambient dust dissipates from SOA1 while concentrating around the smaller SOA2. At one point, an RPG is fired through the window of a house, creating SOA3. Depending on the amount and type of remaining particles in SOA1 & SOA2, the resulting explosion may borrow at least one smoke pillar from SOA1 and borrows some small fires/smoke first from SOA1 and then from SOA2,while adhering to the minimum lingering amount of particles in each SOA and overall. The enemy then counter attacks with its own artillery over a much larger area of the town than occurred in SOA1, creating SOA4. The amount of particles generated by SOA4 require it to borrow from the prior SOAs. Due to SOA4 being larger and newer, it takes a few fire particles first from SOA3, then SOA2, and lastly from SOA1 if the SOA1's minimum has not been reached. Since the one smoke pillar generated in SOA3 is the minimum limit, SOA4 will either borrow from SOA2 or SOA1, or not generate another smoke pillar at all. Due to SOA4 being the largest SOA, the ambient dust is spread out over SOA4 and merges with the radius of SOA1. Since the area of SOA1 & SOA4 encompass the areas of SOA2 & SOA3, then the dust would dissipate quickly in SOA2 & SOA3 due to the overlap. SPOILER FOR NON-ACE MEMBERS, DO NOT READ THE NEXT PARTS IF YOU HAVE NOT PLAYED THE INFANTRY SHOWCASE OR MAIN STORY CAMPAIGN YET IN ARMA 3 Thank you for reading and I hope I was able to adequately explain my vision for what I believe could be a killer app feature within ACE. If there is any interest, I would be glad to further clarify any of the above details. I am not an expert coder, but I could possibly also create videos using the Arma 3 editor that could visualize the above scenario as well.

Thank you for this info. I'm going to apply these tips and report my findings as soon as possible. Update: It worked! Thank you so much for your advice. I do not have my own custom model to show yet, but once I do I will post screenshots to go along with these basic steps. Per your advice, here is how I was able to produce a secondary muzzle flash for an under-barrel weapon: 1. I pasted the physical model of a muzzle flash into the 0 LOD (to be clear: NOT a proxy) and named the selection "muzzleflash2". 2. I went to Geometry LOD and created a new Property named forceNotAlpha with a Value of 1. 3. In my model config, I added the "muzzleflash2" selection to "SkeltonBones[]" and "sections[]" and list it as a selection within a "class zasleh2_hide" Animation, as shown below: class CfgSkeletons { class Default { isDiscrete = 1; skeletonInherit = ""; skeletonBones[] = {}; }; class customPlasmaRifle_base : Default { SkeletonBones[]= { "trigger","", "magazine","", "zasleh","","muzzleflash2",""//muzzleflash2 model added as a bone }; }; }; class CfgModels { class Default { sections[] = {}; sectionsInherit=""; skeletonName = ""; }; class max_plasma_rifle3 : Default { skeletonName="customPlasmaRifle_base"; sections[] = {"zasleh","muzzleflash2","Camo"};//muzzleflash2 model added as section class Animations { class trigger { type="rotation"; angle0=0; angle1=-0.5235988; axis="zbran"; memory=1; minValue=0; maxValue=1; minPhase=0; maxPhase=1; source="reload"; sourceAddress=0; selection="trigger"; }; class zaslehrot { type="rotationX"; source="ammorandom.0"; selection="zasleh"; axis = ""; sourceAddress="loop"; centerFirstVertex=true; minPhase=0; maxPhase=4; minValue=0; maxValue=4; memory=0; angle0="rad 0"; angle1="rad 360"; }; /*class zasleh2rot //Hiding second muzzle's rotation for now. Will work on keeping it centered later. { type="rotationX"; source="ammorandom.1"; selection="muzzleflash2"; axis = ""; sourceAddress="loop"; centerFirstVertex=true; minPhase=0; maxPhase=6; minValue=0; maxValue=6; memory=0; angle0="rad 0"; angle1="rad 360"; };*/ class zasleh_hide { type="hide"; source="reload.0"; selection="zasleh"; sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; hideValue=0; unHideValue=0.5; }; class zasleh2_hide { type="hide"; source="reload.1"; selection="muzzleflash2";//muzzleflash2 model added as selection sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; hideValue=0; unHideValue=0.5; }; }; }; }; 4. After compiling, the secondary muzzle flash shows up in Arma 3, at least in 3rd person. I'll try to figure out proper rotation and viewing the muzzleflash in 1st person (maybe need to add another LOD?) and post further updates as I progress. Thanks again for all the info!

Hello all, I have been trying to create a weapon with different muzzle flashes depending on which muzzle is selected but have been unsuccessful. A version of the Promet contains a underbarrel shotgun that illustrates what I'm trying to do: https://imgur.com/a/Q4OctaW However, I cannot seem to create a similar muzzle flash for the secondary muzzle. I have tried creating "zasleh" and "zasleh2" muzzle flash proxies and copying the ARX model.cfg using ammorandom.0 & ammorandom.1. I have used the exact same proxy/memory points in my model and the exact same code shown below: class CfgSkeletons { class Skeleton { isDiscrete=0; skeletonInherit=""; skeletonBones[]={"trigger", "", "zasleh", "", "zasleh2", ""}; }; }; class CfgModels { class customPlasmaRifle { htMin=0; htMax=0; afMax=0; mfMax=0; mFact=0; tBody=0; skeletonName="Skeleton"; sectionsInherit=""; sections[]={"zasleh", "zasleh2", "camo"}; class Animations { class zaslehrot { type="rotationx"; source="ammorandom.0"; selection="zasleh"; sourceAddress="loop"; minPhase=0; maxPhase=4; minValue=0; maxValue=4; memory=0; angle0=0; angle1=6.283185; }; class zasleh2rot { type="rotationx"; source="ammorandom.1"; selection="zasleh2"; sourceAddress="loop"; minPhase=0; maxPhase=6; minValue=0; maxValue=6; memory=0; angle0=0; angle1=6.283185; }; class zasleh_hide { type="hide"; source="reload.0"; selection="zasleh"; sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; hideValue=0; unHideValue=0.5; }; class zasleh2_hide { type="hide"; source="reload.1"; selection="zasleh2"; sourceAddress="clamp"; minPhase=0; maxPhase=1; minValue=0; maxValue=1; memory=0; hideValue=0; unHideValue=0.5; }; }; }; }; but my weapon only seems to only create the "zasleh" muzzleflash when using the primary muzzle but does not create a "zasleh2" muzzle flash when I switch to my secondary muzzle. Has anyone figured out how to show multiple muzzle flashes from different barrels for an infantry weapon? Thanks in advance!

I use Microsoft Sticky Notes myself in the same way, but it would be nice to have something that is more baked into the Launcher itself, and also something that could migrate to the Steam Cloud so it stays in sync if you ever forget to backup notes for a new system. That would be great as well, I would also propose that your feature be part of the Arma Tools as a sort of Mod Debugging tool. Maybe even expanded even further to be part of a specialized IDE for making Arma mods, with a built-in notepad similar to ones that can use extensions to highlight Arma syntax, and when it compiles it automatically goes to a .bin format. Basically combine 3 separate tools into one official tool. I remember a similar was mentioned a few months back called ArmA.Studio, but I don't think it was officially released.

I would like to propose adding a section to the Mod Launcher that allows you to enter user notes for each mod entry, or a similar way to highlight mod incompatibility. The best use I would have for this feature is to help remember which mods are conflicting with other mods when running many different ones in the same session. Sometimes I will forget which mods do not work, and I have to go through the arduous process of elimination when using many mods at once just to find the one (or even worse, several) mod that doesn't want to play well with others. Multiplayer server Administrators may find this feature useful too as servers often run carefully vetted mods for maximum compatibility, so keeping track of which mods are acting up or which mods can be retested after being updated would be useful. I hope this type of feature is on the minds of many other players as well and thanks for reading.

Ah I remember that one now, I'll give it a try and thanks. Update: That works! =) Thanks again for the hotfix.

Here you go: http://pastebin.com/p1YMQPtd I don't post files to the forums too often, so if you need the info a different way, just let me know and thanks for the reply.

Can the ammo count be hidden for Iron Front units? At the moment you cannot apply Ace UI settings with Iron Front units, like hiding the ammo count, or you will get a "cannot modify a forced user interface element" message. Thanks for reading and great work on getting two of my favorite mods to work together.

Would it be possible to add variations of the Y-32 in a future update? I have been brainstorming a few configurations for it: - A Taru-like variant that can attach and detach pods from the rear with the same pod types that the Taru has, plus a pod that can be used as a bomb bay. - A light strike/anti-air/scouting variant that ditches the rear passenger section altogether so it has a sleeker profile and more maneuverability - An anti-tank/ground suppression variant that also loses the rear passenger section, but has a single seat, extended pylons for more hard-points, and a fixed cannon like the A-10 Thanks for reading and I look forward to feedback on my feedback =)

Thanks for the torrent link. I am downloading and seeding as well, at 50% so anyone below that at least should benefit. Could the mod developers post upload this to the Steam Workshop for easier access? Thanks and keep up the great work!

The latest fixed version on Armaholic is now working perfectly for me =)

I tried to use this mod v1.51 with different combinations (download from Play WithSix, download from Armaholic, combined with ACE, using non-beta and beta Arma III versions), but the action to attach the pod does not appear in the menu or ACE actions. Apologies as I don't have anything else to point out what might be going wrong, and I'm not using any other mods except when using ACE. Otherwise mod looks great. Thanks!