Okay, after lots of testing, here is a patch that fixes all vanilla flare issues:

class CfgAmmo {
	class FlareCore;
	class FlareBase:FlareCore {
		intensity = 500000;
	};
	class Flare_82mm_AMOS_White:FlareCore {
		intensity = 1000000;
		effectFlare = "FlareShell";
	};
};

40mm flares inherit from FlareBase. From my tests 100k intensity (that RHS has) is nowhere close to OA or early A3 GL flare brightness, I tested 500k and it seems to be too bright it seems to be close to whatever original A3 had:
original A3:

Here is what RHS does it:

class rhs_ammo_flare_m485: F_40mm_White
{
    intensity = 100000;

and vanilla config only has intensity defined in 2 classes, checked with

"'intensity' in (configProperties [_x, 'true', false] apply {toLower configName _x})" configClasses (configFile >> "CfgAmmo") apply {[configName _x, getNumber(_x >> "intensity")]}

In T172751#2467536, @dedmen wrote:

Revision 150736 now deleteVehicle also works on them

(allMissionObjects "#track") apply {deleteVehicle _x} will now delete all tracks (its not instant, they disappear next simulation cycle)
(allMissionObjects "#mark") apply {deleteVehicle _x} will now delete all footsteps

thank you guys :)

Update: Noticed that zooming in with the 3x-9x pulls the reticle out of center and down into the right.

Oh the Video seems to be encoded using Av1

but you will have to execFSM with allowTerminate param

We will add a "Auto" ultra-wide option. That should take care of you.
Its the same as the old Auto but it disables triple-head.
Dev branch tomorrow. maaybe profiling branch

ignoreForTargeting _unit or _unit setKnowledgeLimit 0 would be nice as well

Looks like removing all action "preprocessings" was a bit too much and it breaks some actions. I'll have to go case by case

Yes exactly.

Terminating FSM would mean removing it from scheduler on the next simulation so it would just stop running at unknown part of its execution. Is that what you are after? Isn't it better to have controlled FSM exit rather than "eject"?

Hey there!

The integration of an exposed weapon or some form of weaponry into the HMETT holds the promise of augmenting its capabilities for a more versatile and impactful role in military and tactical operations. Nevertheless, careful consideration and adherence to ethical guidelines are paramount to ensure responsible and lawful deployment.
https://en.wikipedia.org/wiki/Heavy_Expanded_Mobility_Tactical_Truck rails

try this https://community.bistudio.com/wiki/Arma_3:_Unusual_Process_Exit#0xC0000135_-_STATUS_DLL_NOT_FOUND

You can always set an FSM variable that would direct your FSM to the exit state.

AFAIK forgetTarget is only temporary - aka when the enemy is still within view/distance/can be noticed again, the enemy will become known again

Revision: 151327 setHitxxx commands extended

Hi. Found this exactly same problem when set "map factor" bar setting left.
In vehicle you open and close map many times, all 3D sounds get silence and not reset back.
After this problem, if you set "map factor" bar right, 3D sounds volume work opposite when open and close map.

I tried with the two EHs but this code did not prevent the tigris from shooting my pawnee:

Revision: 151324

In T178591#2559564, @dedmen wrote:

Newtarget is not feasible.
Target is already detected before its known. NewTarget triggers, while nearTargets still returns empty list.
Then when unit becomes known, it appears in nearTargets, but NewTarget wouldn't trigger, because the target has already been in the list, it was just updated. And for that we already have KnowsAboutChanged.
Looks like a won't do.

This is being added in 2.16 for deleteVehicle. Makes sense to add it for other types too.

Follow https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Newtarget is not feasible.
Target is already detected before its known. NewTarget triggers, while nearTargets still returns empty list.
Then when unit becomes known, it appears in nearTargets, but NewTarget wouldn't trigger, because the target has already been in the list, it was just updated. And for that we already have KnowsAboutChanged.
Looks like a won't do.

We'll try to research and provide some documentation on the timeouts of different WP types.

ENDLOAD cheat code. Does the same as the internal key combo
Next week dev branch

The LG shells for some reason work as Guided shell i.e. fly to the screen centre

• Guided shell must work this way
• LG not

I'm sure Arma 3 LG artillery should work like this: LG shell fired and fly like general (ordinary) HE shell but on target approach projectile must seek for a laser and correct his fly to the target
As like it do vanilla LOAL bombs (e.g. GBU-12)

@dedmen Thank you for checking!

That message isn't easy to expand.
Also this is not problematic. It means it ran past our pre-allocated storage. The array will just expand dynamically and work fine. It just means we allocate twice.
Unless it spams that message, its not actually a problem that needs solving.

next week dev branch, and 2.16

That is because view distance is based on the center of the object. And the beams center is in its center, so far away.
Though max beam length is 1000m, so it really should be 500m.

In T178591#2558121, @dedmen wrote:

You're writing about new command. But all I see is new eventhandler?

You're writing about new command. But all I see is new eventhandler?

No repro on latest internal build.
No repro on latest profiling branch.
No repro on 2.14 stable.

Here is another video of the issue, completely destroying FPS and stuttering when shooting near these large rocks, this time in Gabreta.
https://youtu.be/4lgHVz2HGQM?t=272

Here is another video of the issue, completely destroying FPS and stuttering when shooting near these large rocks, this time in Gabreta.

https://feedback.bistudio.com/T177742 because Magazine is also a WeaponSlotItem

Arma 3 fix will be in 2.16 update.
DayZ Team has been informed. Thank you!

thanks

Happy to report that dedmen Utils.dll fix did indeed work, the Arma 3 Launcher on Steam Deck recognized the location of the mods. Bravo!

Revision: 151304

Revision: 151304