As the categorization has been already in progress, this should hit the dev branch today. Could You, please, check the new categories.
As far as the weapons under equipment part of request goes, this is impossible as there is just two levels. And having all the weapons together would be a bit harder, I would say, than having them as a separate category.

Thank You for good points. I would dare differ on the hatch part as hatches are usually part of the main tank turret. Which means their movement should be dependent on it rather than on rotation of commanders MMG, but feel free to correct me if I'm wrong.
As for the gunnerView memory point, You are perfectly correct. It should be out with next update of samples, thank You once more. Could You, please, give it a try afterwards and close this issue if it is as it should be?

@TOMMEH Please do so, the worst possibility is that it's going to be a duplicate report on BattEye side, which is still better than none ;)

The issue is a bit more complex than it seems (as already the additional note proves) - when You start a mission, there go several changes of faces:

1. Setting the face according to the soldier model
2. Setting the face according to identity type
3. Setting the face according to identity (scripted setIdentity goes here)
4. Setting the face according to profile
5. Setting the face according to mission scripts (including execVM)

That means we may possibly change the faces using execVM, but that could possibly collide with all mission scripts and provide strange results (including for example the East Wind campaign).

Just a side note, it worked well in A2 because story characters had their own head models with no selections to change the face on.

This is actually a bit different than it seems - the addon is ui_f_data.pbo indeed, but the header has a bit different prefix.

Try to open the addon in notepad in example and you may see that the prefix is "a3\ui_f\data". That means any folder and file inside has this prefix from game point of view. That results in \gui\cfg\Ranks\private_gs.paa (the actual file inside of PBO) being seen as a3\ui_f\data\gui\cfg\Ranks\private_gs.paa and that is the correct path defined in config.

I hope it makes sense.

Thanks a lot for intel, at least the GMG has been fixed.

Thank You for pointing that out! It was a pleasure to cooperate.

I have actually fixed even the bigL_R one, I'll take a look at the rest tomorrow, but good point, thanks!

The rest has been fixed today => it should make it to dev tomorrow, hopefully. Thanks a lot for intel.

Good point, thanks a lot, it seems like the rusty ladder has been well hidden. It should work just fine now, that means tomorrow in the dev branch. Could You, please, give it a try and close the issue if it works?

I have checked the vanilla content and have not found any class using neither randomize_civ1.sqf nor clock.sqf, tom_48_97 has already purged the civilian randomization and cars use different system for clocks for some time. Could You, perhaps, try to verify the game integrity?

Thanks a lot for letting us know, the issue was only for VR Entities which were undergoing some deeper changes. It should work correctly even for them.

Thanks a lot for intel, this has been addressed with clock scripts removal for a different solution, there should be no more scripts running for clocks. Could You, please, confirm that on dev / RC branch and close the issue?

Thanks a lot for letting us know, we have deployed a hotfix that should address the issue. Sorry for the inconveniences.

Thanks a lot for letting us know, I have adjusted the zeroing ranges and ti should be available in dev branch tomorrow. Could You, please, give it a try and close this issue if it works correctly?

I'll share that with the rest of the team, thanks a lot ;) And no need to feel bad, it happens to everyone, including myself :)

Weapons described as not being shown are actually gunner weapons which are defined in O_Heli_Attack_02 >> Turrets >> MainTurret >> Weapons[]
It is perfectly correct that they are not defined as pilot weapons the same way as for AH-99 Blackfoot. Does it help You?

There is a good solution described on the forums by Tilion: http://forums.bistudio.com/showthread.php?185166-Missing-Helicopter&p=2811738&viewfull=1#post2811738

Could You, please, give it a try if it's what You need and close this issue if it is so? Thanks a lot.

Good point, thanks a lot, it should be fixed tomorrow in dev branch. Could You, please, give it a try and close this issue?

It is actually as designed because the flare slugs shot by the pistol are meant to be not accurate.

This is actually correct because all the cargo seats are ready for Firing from Vehicles feature. That means they are not regular seats but turrets config-wise, You may see it by the number of turrets of said vehicle. Does that explain the issue enough? If yes, please, close this issue, otherwise let me, please know.

This is as designed, Your note has been taken into consideration, thanks a lot.

The description is correct - this feature was never meant to work with inherited classes. The goal was to create a simple tool to work add into array with unknown previous values (e.g. Throw muzzle with various grenades) and it works just like that.
There is currently no plan to change the feature, it may be possibly done in the future, but I cannot promise anything.

Thanks a lot for feedback, we are taking that into account.
Having open-able doors for more vehicles is quite a huge performance hit according to our testing, mainly because of more complex PhysX shapes required. We have decided to allow use of ramps specifically, because there is just a handful of them and it mitigates bigger performance impact most of the times. We are going to keep investigating possibilities, but I cannot promise any change in a near future.

The change from 28.11 dev branch actually adresses this issue as the scripted weapon holder inherits standard weapon holder with all the proxies, not juts the single one.

My bad, I have even used a wrong field as I can see, I am sorry for the confusion :( And a good news, it should make it to the next main branch update soon (TM)

I have added the property to class Weapon_Empty, it should be available tomorrow in the dev branch. Could You, please, give it a try, if it works according to Your needs?

Thank you for letting us know, the memory points should be in proper selections and it seems like it behaves correctly. Could You, please, give it a try tomorrow on a dev branch and close the issue if it works?

This is actually a correct behaviour - dead driver is ejected from the vehicle. Thanks for the feedback, we'll take in into consideration while thinking about better display of ejecting.

Thanks a lot for letting us know, the issue should now be fixed in the development branch. Could You, please, confirm that and close the issue?

As author said, Thanks a lot for intel!

Thanks a lot for the information, it seems like I made some wrong selection in the models. It should be fixed in todays dev version, could You, please, give it a try and close the issue if it works well?

This is correct behavior as soldiers tend to equip their diving goggles and diving fins only if they are actually in the water. There is a small pool in the corner of Virtual Reality world designed for this purpose.

I suppose sooner than You would expect ;)

It is in the development branch of the tools, feel free to give it a go.

Thanks a lot for letting us know, there is a bug in copying the PBO into target directory that should be fixed with the next tools release. The PBOs are correctly packed in the temporary location, which is set in the options, you may find the output there in the meantime. We are sorry for the inconveniences.

Thanks to Tom_48_97

Thanks a lot for intel, it seems like this has been already fixed. Could You, please, give it a try and close the issue if it works?

Good catch, thanks a lot, I'll take a look.

The issue should be already fixed in dev version, could You, please, give it a try? Thanks a lot.

I'll take a look, thanks a lot for letting me know.

I have fixed that issue, could You, please, take a look in dev branch today and close it if it is OK? Thanks a lot.

Sir, it seems like this one is Your cup of tea, could You, please, take a look?

I've been told by the reporter that this has been done long ago, closing

Thanks a lot for the intel, I'll try to talk with responsible persons to ensure some improvement and fixing, but no promises yet.

Thanks a lot for the feedback! It seems like the issue has been already fixed, could You, please, give it a go and close it if it works correctly for You?

Thanks a lot for a great observation skill, I have fixed the issue just as it has been suggested. Could You, please, test it out in dev branch later on today and close the issue if it is OK?

I have fixed the issue, thanks a lot for letting us know. Could You, please, try it out in today's dev version and close this issue if it is OK?

This has been already fixed with the FFV for commander introduction, thanks a lot for letting us know.

It should be released even to the standard distribution together with the second part of the campaign, could You, please, confirm the fix and close the issue if it works? Thanks a lot.

I don't think so, the main branch would require re-validating all the data again :(

Thanks a lot for letting us know, I have fixed that and it's going to be part of dev branch udpate either today or tomorrow. Could You, please, check it and close it if it works?

Thanks a lot for intel, I have fixed the high speeds. Could You, please, test it with next development build?

Thanks a lot for letting us know, the issue should be fixed on Monday in dev branch. Could You, please, try it and close the issue?

The issue should be already fixed, could You, please, confirm that? Thanks a lot for information

The issue has been addressed by our programmers, the only problem remaining is that you need to "Export" fbx from empty file in Oxygen to get to import screen. At least it works, we will try to solve the formal part.

We are investigating the possibilities, but I cannot promise anything until we have a solid tool to release. Thanks a lot for letting us know.

This is related to the outdated tools, there is going to be a new tools package hopefully soon enough. Thank you for letting us know, things are being worked on, stay tuned, please.

It should be OK with the release of new Arma 3 Tools, could You, please, give it a try and close the issue if it works correctly?

This has been already fixed with changes in 1.24, could You, please, close the issue after giving it a try? Thanks a lot for letting us know!

Could You, please, try script command:
player addItem "muzzle_snds_H_SW";
That should do the trick and add the suppressor into Your inventory.

Thanks a lot for letting us know. I have fixed the issue and the fix should be available tomorrow in the dev branch. Could You, please, confirm the fix and close the issue?

It might be some issue related to this script being called after setObjectTextureGlobal when You JIP. We are addressing the issue with programmers and it should be probably fixed soon. Thanks a lot for letting us know.

It should be fixed in today's dev branch, could You, please, test it and close the issue if You see fit? Thanks a lot.

May You, please, provide me with some more information about the issue? I have tested this script on network without any issues, what exactly is wrong and how does it look like?

I would propose to see some user reviews on the gun or give it a try if possible. The handle is in such shape that reducing the recoil is more difficult even despite the lower chamber.

Thanks a lot for intel, it seems like we had some mismatch in data. It is going to be fixed tomorrow in development branch, could You, please, verify it and close the issue accordingly?

I was unable to reproduce that on any version, but the QA is going to take a closer look with different setups to be sure. Thanks a lot for letting us know.

Thanks a lot, closing.

The actual effort was tiny thanks to Your splendid description, most of the effort was wasted on some paranoid double-thinking that it would require localization and stuff :(

Heck, I got it wrong all the time, I am sorry :(
I have added the new ammo, could You, please, check it again tomorrow with the update of dev version of the game if it works as You intended? Thanks a lot.

Thanks a lot for information, I have adjusted the view for both iron sights and standard view to be of a naked eye. The fix should be probably available on Monday in development branch, could You, please give it a try and close this issue if it works correctly?

Thanks a lot for information, I have adjusted the view for both iron sights and standard view to be of a naked eye. The fix should be probably available on Monday in development branch, could You, please give it a try and close this issue if it works correctly?

It is the same for all tracked vehicles at the moment. The fuel is consumed by driving but at a extremely slow rate (check "fuel vehicle player" in watch in pause menu). I shall investigate that further, thanks a lot for letting us know.

Thanks a lot for confirmation, I hope it helps

Thanks a lot for letting us know, it should be fixed and the fix should be available in the development branch tomorrow. Could You, please, confirm it and close this issue?

I have tried turning on place in current build and backtracked data to 1st of July, nothing has been changed on the matter. I would suspect it is some kind of placebo effect. Could You, please, describe steps to reproduce to double-check the issue? Something like this:

1. Insert flying AH-9 and start the mission
2. Start the clock
3. Hold X to turn counter-clockwise
4. Stop the clock after making full circle

Results with this repro were the same for each data set back to 1.7. 2013 (game version 0.71 - 07150)

This has been already fixed some time ago, thanks a lot for letting us know.

I have tweaked the sway, could You, please, give it a try tomorrow in a dev branch and let me know? Thanks a lot.

It's still work in progress.

Thanks a lot, I should take a closer look

I have adjusted the access, it should be available in dev version probably tomorrow. Could You, please, take a look then and let me know if there is any further issue? Thanks a lot.

It is possible to configure flares that way, it should be rather easy for the community to do such mods, but the design for all vanilla A3 vehicles states that they are not going to use any different flare fire mode than burst. That is the design decision, not a bug.

I have investigated it again and it seems like the correct hint is displayed in the mission now.

Sorry for the fuzz, it has been fixed, but it got somehow reverted meanwhile, it should be fixed again soon :(

The hint has been adjusted some time ago that it fits all BI-made helicopters, I just forgot to update this issue. Thanks a lot for letting us know.

Thanks a lot for letting us know, it should be fixed with todays dev branch update. Could You, please, confirm the fix and close the issue?

This should be fixed by today's update of development branch. Could You, please, confirm that and close this issue? Thanks a lot for letting us know.

The issue has been addressed in current development branch update and should be in next Arma 3 Beta update. Could You, please, confirm the fix and close the issue?

Door actions have been removed from all vehicles long time ago, still, thanks a lot for the feedback.

Nope, the update of development branch is staged for tomorrow, probably, without any promises.

See http://forums.bistudio.com/showthread.php?149636-Beta-Development-branch-changelog&p=2424351&viewfull=1#post2424351 - it should be fixed now. Could You, please, confirm the fix and close the issue? Thanks a lot for letting us know.

The issue has been fixed and the fix is staged for next development branch update. Could You, please, confirm that and close the issue?

I fully agree with Your reasoning, but looking into the model itself proves something else. It may possibly be an error on side of the artist who did the vehicle, I should check that out. Thanks a lot for reporting the issue, we'll try to work on all the parts as possible.

I would just like to point out that the periscope is the other stick out of SDV, not the one mentioned in the picture. And it is correctly aligned with water surface.

Thanks a lot for letting us know, introducing of Advanced Flight model brought in manual controls of the landing gear. Could You, please, confirm that it works as intended and close the issue?

See http://forums.bistudio.com/showthread.php?149636-Beta-Development-branch-changelog&p=2424351&viewfull=1#post2424351 - it should be fixed now. Could You, please, confirm the fix and close the issue? Thanks a lot for letting us know.

As mentioned - problem expired. Thanks a lot for letting us know.

It should be fixed in current development build, could you, please, confirm that and close the issue? Thanks a lot

There have been improvements in this way on engine side that made real values usable in game. Could you, please, confirm the fix and close the issue?