Thank you for your report. This issue is currently being investigated.

This is not a bug. If you are running on the lowest difficulty (recruit), you have as player a special type of armour called "extended armour". In difficulty options, you can turn it off and explosive will harm you much more.

There is a problem with inheritance, indeed. We have some models, that don't have defined hiddenSelections in their p3d (e.g. "V_PlateCarrier1_rgr") and other that do so (e.g. "V_TacVest_khk").

If you have defined hiddenSelection in itemInfo of a model, that does not have camo selection definition in p3d, when dropped on ground, this model becomes invisible (engine reason).

Hence we have splitted the base class of vests to two:
Vest_Camo_Base and Vest_NoCamo_Base

In the next alpha (/beta) release, this issue with color should be fixed.
Please modify your MOD's classes accordingly.

Splendid work. We will certainly look into this. Thank you for your feedback.

@SaMatra:

Uniforms and vests are not vehicles as backpacks and weaponholders are, unfortunately. Thus you cannot add easily weapons and magazines to vests and uniforms by a script. Vests are considered as weapons by engine (i.e. in cfgWeapons config), uniforms are a little bit different type, but their config is also in cfgWeapons, from the perspective of a container.

They contain Supply#NUM in iteminfo, that is reference to a weaponholder (vehicle) with capacity #NUM (it has scope 1 - private and you can find it in cfgVehicles). This weaponholder is empty and gets filled up by items specified in definitions of unit loadout (params magazines[],weapons[],items[], etc) on start of the mission by engine.

Configurability of vests in the same way as any weaponholder would require rewriting the current code (more so if we wanted also uniforms to be dealt with addMagazineCargo - commands) and it is unlikely to happen at this stage of the game development.

I dont see any easy workaround how to define currently a content of a vest without having that vest worn by some unit.

Splendid work. We will certainly look into this. Thank you for your feedback.

To report progress:

BUG # 2, BUG # 3 and BUG # 5 is fixed.

One and four are reported and will be fixed as soon as possible.

Thank you for your feedback.

We cannot restrict player of wearing such equipment. It is, as mentioned above, theoretically possible to wear it.

What we can do is penalize such loadout by faster fatigue increase, so such soldier will hardly sprint and his running will be slow and with all sorts of side effects (bad aiming, heavy breathing, blurry vision,..).

This solution is currently being examined.

AT mine reacts to weight above 7 tons in our game. Mh-9 loaded with crew weights approximately 2 tons. Still not enough for the trigger (which is combined magnetic/pressure trigger mechanism). If you place SLAM mines, the chopper blows up right when it touches the ground, as expected.

Is available and working better.

Yes, Penetration of bushes was set somewhat too low. Adjusted. Thank you for noticing! Will be available in next steam dev build.

AhA! Finally I can see the same behavior. Yes, it has been reported. Thanks for noticing! Will be fixed soon.

repro (for future check):

1. insert rifleman
2. write in unit's initialization "this enableFatigue false"
3. sprint in game -> you get tired after a while and start to run only

Type: Public Alpha
Branch: Development
Version: 0.57.105210

Fixed in this version.

Yes, <unit> enableFatigue false should do the reseting to zero. Are you using correct syntax? When you type 'player enableFatigue false', is it still calculating the fatigue?

If yes, than please specify which version are you running. Also which branch (stable or dev).

(You can press left ctrl+/ to get to clipboard information about version)

Please let me explain:

There is only one fatigue, the number between 0 and 1 measured by getFatigue and setFatigue commands.

There are some systems, that turn on/off at certain levels of fatigue.

Example: With fatigue over 0.5, you are unable to sprint (if you hit sprint buttons - W+Shift - you run, not sprint). At level of fatigue equal to 1, there are certain effects we plan to place in game (currently still WIP). What you should see is a post process of a small blur, that fades away when fatigue drops down (you have to stay calm for that to happen). Also, your aiming imprecission is increased when fatigue is high, further you should hear heavier breathing, the animations are slower, etc.

If I understand it right, what you complain about is the strength of these effects, that is that you can hardly notice any difference. Am I right?

Edit: I realized that some of these effects need to turn on post processes. You can have them disabled in video options -> rendering.

Seems working :(
step 1.:
Please write this to the debug console:

• spawn {while{true} do {sleep 0.5; hint str getFatigue player}};

Press "Local Exec" button. In the right corner of the screen should start to appear some number, when you run / sprint, this should increase.

step 2:

Open the debug console again and write in
player enableFatigue false;

Press "Local Exec" button and see, that the number stopped changing and was set to zero.

Now sprinting/running does not affect this number and thus also the fatigue.

Do you observe the same?

MXM has 6.5 round ammo as the MX rifle. The error has been fixed and will be available in next dev steam build.

Marksman rifle "EBR" ("srifle_EBR_F") has "20Rnd_762x51_Mag" - 7.62 ammo.

This ticket is duplicate with: http://feedback.arma3.com/view.php?id=7522

Thank you for your report. Bug was reported and will be solved as soon as possible.

Unable to reproduce.

Can you, please, verify, that it is still happening?

If yes, I would appreciate if you attached the mission you were running.

Internally fixed, will be steam-available soon.

Unable to reproduce.

Please retest with this script in console (open by pressing Esc, write in "execute" field)

_null= [] spawn {while {true} do {sleep 0.5, hint format ["Player's fatigue: %1", getFatigue player]}}

Do you see a value changing? You should see it from 0 reaching 1 eventually (full exhaustion). The breathing does not seem to affect this change.

Can you confirm?

Unfortunately, described functionality is occuring in OA, as well. We cannot change this behavior and it will remain for the time being in the game.

Reasons:
a] mine is not a vehicle (it is a simplier structure from the engine's point)
b] on mine creation, the object translates to become object of type ammo (ammunition). That is why all attached scripts in initialization field are lost.

This issue has been fixed.

Thank you for reporting. This bug has been processed and will be resolved soon.

This feature is described as follows:

Normal units:

• explode on mines no matter if they have detected the mine or not, no matter how they approach the mine
• can use mine detector (a special item) to detect nearby mines automatically
• can detect mines by their sight on some terrain and light conditions, this detection ability is variable along unit types and exact conditions of the mission
• cannot deactivate detected mines

Explosive specialists:

• they detect automatically mines with mine detectors (item in their bags)
• explosive specialist dont detonate a mine if:

a) they know about it (detection by mine detector or by a unit)
b) they crawl in the activation range of the mine's trigger

• expl. specialists deactivate mines if they have toolkit item in their inventory

These are design decisions and mechanics present in the game. So it is not bug but a proposal for change of the functionality.

TODO: I challenge you to convince me that the current system is unacceptable ;)

This is a desired state as described in the comments.

This is intended.

It is a gameplay feature: explosive specialists simply dont detonate mines, that they know about if crawling around them. Also, if AI is ordered to deactivate a mine, it will crawl the last few meters to the mine (see in game).

Crawling reduces the speed of such movement so we hope it is not exploitable.

@wolfstriked We are surveilling this issue. Armapirx's list is a good try to tackle the problem. However, we are still considering the pros and cons of changing masses of items.

@armapirx - good job with the list. As you indicate, the mere transformation of mass into weight is sometimes not so fitting. The nice example is calculating the weight of a helmet from its mass. As you said, it would be too heavy.

The reasoning why helmets have that big mass is that they are too bulky : try to put more than two helmets into a backpack ;)

The same goes otherway around with the rifles: they don't fit to uniform/vest (they are not allowed to be stored there entirely), so their mass corresponds to balance between their shoulder weight, weight (and space) in backpack, and weight in hands. What you see is a compromise of all these differently percieved weights of the same thing...

a) Fatigue is affected by stuff you carry (=it is implemented in game)

b) the weight (in models) is not used when calculating the load of items

c) the parameter you are referring to is called "mass" and it is a combined factor of weight AND size (a light but unwieldy A0 cardbox will have a big mass in game, similarly small, but heavy ball of lead).

d) the capacities of backpacks were calculated after experimentally filling real-life backpacks with real-life magazines, I am very reserved to change them in any drastic way.

If you lay down several painfully obvious examples where we are VERY off the reality, we may consider setting these capacities differently.

Bug has not been confirmed by the reporter. It is not observed in game.

It does explode when you reaproach the spot again.

Repro:

1. set minefield of bounding mines with an empty heli (named "BIS_heli") on top of it, a player unit somewhere else, but in the init field of the player, write "player moveInDriver BIS_heli".
2. set autohover on
3. start the engine and get some altitude
4. land back on the minefield, mines should explode

Explanation: on the init of the mission, mines start working after all friendly units leave the activation radius. In this case the game understood that the mines "belong" to the heli and thus they remained deactivated while the heli was still close to them.

Please confirm, if you observe the same.

How do you recognize which detonators belong to which bombs? See how messy action menu is when you list all doors...

I understand. What I had in mind was this technology:

http://en.wikipedia.org/wiki/Insensitive_High_Explosives

http://en.wikipedia.org/wiki/TATB

Designed behavior:
As ViiK pointed out, satchel (demo) charges do not detonate from nearby explosions. Since we dont have destructible models of items, they are indestructible in the game by nearby explosion. Compare them to the range/mechanic triggered mines (such as APERS mine) that do explode with nearby explosions/projectiles.

So, let us separate issues here:
a] do you want the C4 charges to be affected by nearby explosion such that they touch off if destroyed?
b] do you want the C4 charge to get destroyed by nearby explosion and become unoperational?
c] do you want to be able to synchronize explosions by having detonator of each charge as an item? (http://feedback.arma3.com/view.php?id=3558)

Not a Bug but a feature. Explosive specialist detect mines if equipped with mine detector.

Thank you for your feedback. We are currently investigating possibilities in this matter.

Described feature (emmpty key preset) has been added to the game.

Please specify your left-hand preset. We can add it in the game.

Moored naval mines are very heavy mines that do not detonate below ships of certain small tonnage. That is the case of your rubber boat.

Simply put: this mine is not inteded for such use.

Fixed in version 0.57.105007 (Dev), addon version: 46977.

UW Magazines reduced to 3, Non-UW magazines increased to 3.

Touch off priority reduced.

Thank you for your report. It is a bug and it will be looked into by our team.

Please specify the conditions of your test.
Namely:

• were both runners controlled by a player?
• was the running straight (=no turns)?

It is fixed some time ago.

Ok, sorry for the confusion. So I suppose we can close now.

In current version (0.59.105679) I have tested above on airfield:

Nato Rifleman:
distance: 941.23 m
time: 3:46.2
Speed: 14.9 km/h

Nato Rifleman without gear (in his init written: "removeAllweapons this; removeAllContainers this; removeAllAssignedItems this"):
distance: 941.23 m
time: 3:35.8
Speed: 15.7 km/h

This difference is considered acceptable.

Are you sure that your tests went other way around? Which testing units you used?

Did a re-test on the current version and the times are along the same lines as what you have recorded.
Blufor Rifleman
1000m:
3.57 ---> 15.18kmph --->9.4mph

Manually remove gear
1000m:
3.49 ---> 15.7kmph ---> 9.75mph

How come that the latter is sooner on finish (3.49 minutes vs. 3.57), yet he is slower? Some calculation problem?

Also: there is a difference if you let AI run and you control the character. The AI pathfinding can do all sorts of tricks & delays that screw up the measurement...

AT mine explosion delay adjusted. Should be fixed in version 0.57.105007, version of addon: 46987.

This bug has been resolved in the newest build.

Yes, we know about this and it is reported as a bug.

What is your opinion about current penetration values? They have been changed.

Thank you for your feedback.

The described test very much depends on other conditions: civilians are more vulnerable than combat units due to the vests and uniform armour. Also our game calculates deflection of bullet when passing through a material. So it can very well happen that you don't observe bullet-impact mark on a close-by wall simply because the bullet has exitted the body in a different place than direct line. This behaviour is considered desirable and happens in real life, too.

I have made several tests and I was able to shoot between 1-3 civilians (sorry:) standing behind each other with the EBR weapon.

In coming alpha releases, general bullet penetration has been revised and tuned. Probably we will have still some other iterations of penetration tests and it may change (slightly) again.

I will remain assigned and inform you about coming changes.

Notice that Hunter and Ifrid are MRAP (=Mine-Resistant Ambush Protected) vehicles.

But I admit the explosives still can have some balancing. I intend to set the endurance somewhere to 2-3 AT mines.

Please provide a mission with the described behavior or test it using knowsAbout as explained above.

This behavior can be tested using command knowsAbout https://community.bistudio.com/wiki/knowsAbout

The value set by explosion of mine of unknown target is 1.5, which is different from 4.0 when enemy knows all about you (including your position). In game this equals to the AI knowing about someone planting the mine but not knowing where exactly that someone is. You can check it visually by looking at the enemy near the explosion area: they will start searching the bushes not go towards you (if you are hiding behind some far away obstacle).

Please check if you observe the same behavior or attach a mission where you prove me wrong.

The injury is fatal on higher difficulty settings.

The bouncing anti-personnel mine has unrealistically low damage value. You can even walk after one has exploded 2 meters away from your torso, even if you didn't have any protective gear on you! In reality, the victims within instant proximity should die immediately or at least become critically wounded.

• Which difficulty you were please running the game? Recruit has special armor bonus that fences off most of the explosions. Please specify.

Please specify the difficulty (recruit/regular/veteran/elite). You find them under Main menu -> Options-> Game -> Difficulty. Property that affects this feature is called "extended armor". If it is enabled, explosives are weak, as you describe.

A unit must be an explosive specialist (in terms of config parameters have flag "canDeactivateMines" true) and have an item called "toolKit".

A normal soldier (including team leader) can set the explosive, touch it off, set timer, but cannot deactivate once set charge. For deactivation of any explosive you must use explosive specialist, sorry.

This is considered a feature and will not be changed in A3.

A design decision is that all containers (such as backpacks, vests, uniforms) will not stack anywhere, no matter if they contain something or are empty. This rule is simple and error-prone.

The rules when to stack them seem simple, but are code-inefficient. If you place 500 backpacks in a create, then you get indeed 500 items in the "crate" list.

If it was stacking, you get a mess of some backpacks stacked (because they are empty) and some not (because they contain different items), next player asks why all containers are not stacking and we get nowhere...

Try to live with it.

This issue can be reviewed if you mention a real game-braking situation, when the stacking is essential.

This issue is fixed.

Confirmed status -> acknowledged :)

Confirming this issue. It has been reported as a bug.

Issue was clarified

As @wallside mentions this is how it should be working:

a) Sprint - that key works together with another key and it is a temporary key - action is performed as long as this key is held. It makes no sense to bind it to 2xW because you cannot hold the W key and the same time press it twice.

b) sprint toggle - that is a key that works as a switch between running and sprinting. You need to press it only once and then you sprint when ever you would normally run (i.e. after pressing W for moving forward).

c) fast forward - that is an action you probably had your "2xW" combo mapped to. This action is identical with pressing SHIFT+W. We removed it from default keys because we want to avoid double tap keys as much as possible (there is a significant engine delay between your double-tap of a key and the action response simply because engine has to detect between three possible key presses: two-times W, double tap W and hold W).

In default arma 3 key presets, the sprint button is on SHIFT and sprint toggle is not used. It underscores the fact that sprint is now designed as "short-term" action with exhaustive effect that should be used only temporarily.

Can you please describe in steps how your sprint actions don't work? What do you do to see that they got stuck/work improperly?

Please describe in steps how to reproduce.

a) Exact action names would help (or descriptions in options->controls) "Turbo" means "Sprint"?
b) Could you, please, write a repro in steps? Describe how to reproduce (more than sometimes, if possible), we find out why it happens.