Is this likely to be a locality issue? Vehicles in multiplayer are local to the driver, in this case would that mean that if the virtual AI in the driver slot were local to the server this would make the UAV local to the server even when the player is in the turret position?

Ah obviously not the same issue we had, sorry I couldn't be more help.

We had a similar issue when we started using the VA to handle our gear on our public server. Something we discovered was that for the purposes of saving and loading gear:

A) the arsenal considers a weapon class name that comes pre-attached with accessories (e.g. "arifle_MX_GL_ACO_F", MX GL with ACO scope) to be distinct from the base class with the ACO accessory added later (“arifle_MX_GL_F”, basic MX GL) and...

B) ONLY base classes can be white-listed and thus loaded from the arsenal.

For example if a player spawns with "arifle_MX_GL_ACO_F", they will be able to edit and save their gear in the VA but then they will not be able to load their saved loadout because "arifle_MX_GL_ACO_F" cannot be white listed in the arsenal. If you edit the players starting loadout to have the base class “arifle_MX_GL_F” and then add the accessories (in this case the “optic_ACO”) separately the player will be able to save and load their loadout even though on the face of it the two loadouts should be the same. Important to remember that pistols also sometimes come with silencers and optics pre-attached, it is important to use the base class for those also.

If you think about it makes perfect sense to only deal with the base classes of the weapons in the arsenal, if you were able to white-list the variants with pre-attached accessories then these classes would appear as duplicate/separate entries in the weapons list. This would unnecessarily bloat your arsenal lists as the very nature of the arsenal makes selecting a base weapon and then added accessories to it much easier.

Another thing to note is that the it makes sense for BIS to create these additional weapon classes with accessories as it allows them to quickly and easily load the various different unit classes without the need for extra scripting commands to add the accessories separately.

All in all it’s a bit annoying that all the default BIS units come with theses weapon classes that are unusable in the arsenal and annoying that this incompatibility isn’t more widely documented but the reasoning behind both the multi-component weapon classes and the fact they are not accessible or visible through the virtual arsenal makes sense.

Sorry for the massive wall of text, it’s a slow day at the office. Hope some of my rambling helps with your situation.

Updated description with another video demonstrating TrackIR issue. This should probably have been the main focus of the ticket as it is by far the most troublesome. When using free look it is easy to manage the issue (simply don't use free look), however when using TrackIR it is necessary to disable (pause) TrackIR functionality to be able to reliably align the sights. This is the more serious issue although admittedly it impacts fewer users.

No, if you're still freezing after downloading a fresh copy of a mission file then it's not the same issue I was experiencing. I wouldn't recommend deleting you arma 3 app data folder.

Is it always on the same server? I had a similar problem caused by a corrupted mission file for a server I regularly played on. I would be able to play for a random length of time. Deleting the mission file from the mpmissions cache in the arma 3 apps data folder solved it for me. It would also make sense that the issue persisted after a full reinstall as the apps data folder isn't necessarily deleted even after a uninstalling the game.

One question: How would you handle the 40 second timer on explosives? This is a context-action BUT I don't like the idea of just double tapping space and accidentally setting the 40 second timer without realising it. I realise this is a very specific and potentially isolated case but it could very easily happen when placing explosives near other context sensitive objects like cars, doors, lootable objects, etc.

Can confirm, have expirienced this on my groups public (no mods) and private (mods) dedicated servers. Each time it was when I joined in progress and the vehicle was in veiw range of where I spawned, happened with a wipeout so was very apparent with the engine sound flickering along with the vehicle. Proceeded to crash to desktop.

I also have this issue, I am unable to modify the status or delete tickets that I have submitted. I am able to edit but when I submit the changes it simply says access denied.

This happens even when the Zeus role is occupied by a player. It would apear to be intended functionality of the Zeus game master gameplay mode module to add a respawn position for each participating side when no Zeus player has joined the game. However since the latest patch (1.34) it now happens regardless of whether the game starts with a player in the Zeus role or not.

Also it should be noted that this only happens if you add respawn points manually using scripting (BIS_fnc_addRespawnPosition). If you place a respawn module in the editor it will be recognised by the game master module and the random respawn point will not be placed. This is a good work around but it is still potentially limiting compared to using script function.

I experienced this issue, if I refresh the server browser multiple times it would become unresponsive and I would loose DNS connection, things like teamspeak would remain connected but I would not be able to refresh the steam server list or load up any websites in my internet browser.

The issue was caused by "IP flood protection" on my router detecting the steam server list refreshes as a DDoS attack. Disabling the IP flood detection in my router settings solved the issue. It may be worth looking at the documentation for your router to see if it has any similar security features which could be causing the issue.

Ah ok thanks for clarifying.

Yeah, I've just noticed. Don't think I have the ability to close this myself unfortunately.

Confirmed.

For now a workaround you can use is to place a rifleman and then edit the mission.sqm, replacing the unit classname "B_Soldier_F" with the classname of the pilot "B_Pilot_F".

I think this may have been fixed! I was playing about on Zeus and the flash lights weren't penetrating walls or even H-barriers. Try it out.

If it is it pretty much disproves my previous post xD

I was also talking about static map placed objects, was simply using zeus to test it.

I got Zeus, gave a dude a flashlight and pointed him at stuff. Here are some screenshots:
https://www.dropbox.com/s/8djdz3puc6qzli9/2014-07-16_00001.jpg
https://www.dropbox.com/s/tm1ux3ahjh7v6vv/2014-07-16_00002.jpg
https://www.dropbox.com/s/m20ndgseu30gen8/2014-07-16_00003.jpg
https://www.dropbox.com/s/nse7iqrl28kkyai/2014-07-16_00004.jpg
https://www.dropbox.com/s/7mkh8m3ugrw8osa/2014-07-16_00005.jpg
https://www.dropbox.com/s/daq79pnzvyznjme/2014-07-16_00006.jpg

From the looks of it you're right, light still penetrates walls but for me it's much less noticeable than I seem to remember it being. It's not a true shadow though, they simply reduce the range/intensity of the light when shone at objects that should block it so some light still gets through.

Does this look like an improvement or do the screenshots basically illustrate what you are reporting?

Also this is a duplicate of http://feedback.arma3.com/view.php?id=4180.

Having objects cast shadows from dynamic (moving/not static) light sources is possible and has been done in other games.

However, the performance cost of implementing it into Arma 3 would be huge simply due to the shear number of dynamic light sources it is possible to have in a single rendered scene (think 40 soldiers all with flashlights storming a town at night). Forcing all objects in the game world to cast shadows from multiple dynamic light sources is simply not feasible with current graphics hardware. The only options left are to either reduce the number of light sources rendered in any one scene or render them all but not allow them to cast shadows.

The current approach is actually a combination of the two but the number of light sources possible to be rendered at once is dramatically higher than it would be if the engine were forced to calculate shadows for each individual light.

It's unfortunate but I believe its more a limitation of current generation graphics hardware processing power not a bug in the Arma engine itself.

Hmmmm, I'm stumped then. I don't experience this issue and I can't think why the osd text would be particularly demanding. Anyone else got any ideas?

This doesn't sound like the issue you describe is actually caused by the OSD text. Sounds more like your game is simply lagging on first mission load (which is common) as this is when the system is under heavy load as it initialises all the AI and scripts for the mission and loads textures.

The OSD text often coincides with large amounts of data being loaded as it is commonly displayed at the start of a mission or after a large transition from a cut scene, common times your system will be experiencing higher than normal load.

Confirmed. +1

Can confirm. In my experience the issue is only present when hosting missions on dedicated server. Client hosted MP missions are able to use the predefined mission parameters. I assumed it was due to the idiosyncrasies of setting up a dedicated server. Our dedicated server uses arma3server.exe.

Ah thanks. I've not revisited this in a while, I'll test when I get back home.

Can confirm this is true of all binocular type items (rangefinder and laser designator). Have tried combinations of the following; removeItem, unassignItem, removeWeapon and removeWeaponCargo.

If the texture files are still present buried in the game folder simply making them officially supported allowing less script savvy mission makers access to them in the editor by default would still be very much appreciated.

100% agree, would really like to see this implemented.

Thanks ever so much Iceman! Really glad this bug has been resolved.

So erm... what exactly were you trying to simulate when you discovered this bug?

The animations reflect what 99% of the players will expect to see in terms of a soldiers stance and his movemen, which is all they are required to do.

You may well be right but it's no really the point.

Additionally to better low impact crash simulation, high impact crash simulation should also be improved. Nothing breaks the immersion more than watching a jet hit the ground and seeing the wreck bounce 10 meters back up into the air. I think at a certain impact force (if it's possible to calculate) the wreck model should simply not be spawned and instead in its place a large fire effect should be left. This would go some way to better simulate complete disintegration of the aircraft upon impact without the need to spawn complex parrticle effects or to model smaller wreck fragments.

This issue has been present on my unit's server for at least 3 months but it only ever affected people entering the copilot seat when the engine was running. Even then it is intermittent. I believe it went unreported because we run a large number of scripts which makes it difficult to diagnose.

Just in case this information would be useful for testing the issue, our server that we experience the problem on is "[S.O.S] Tactical Gaming".

SilverDude, judging from the layout of the medical module variant of the new CSAT helicopter (http://i.imgur.com/RjV1JKj.jpg) this feature is looking very promising for a future release. Fingers crossed.

I've no doubt in what you're saying about the ticket not being actively monitored but I'm still fairly sure they're aware of the issue at large.

It's status is reviewed because this is a very common complaint that they've addressed time and time again. They've openly said in the past that the action menu is here to stay and that they're not looking to do such a major overhaul of the interaction system (don't have an up to date source for this but I think it's mentioned in the video above).

It sucks but it is completely up to Bohemia to decide what they can and can't achieve with the resources available and what is in or out of scope for thier project. They've just pushed out one of the most requested and highest up-voted tickets on here, that being the bipods, so I think it's fairly obvious that they take the feedback they get seriously. But look at how long it took them to achieve that and you get a sense for what they're up against, in terms of resource and prioritising large tasks.

On the plus side, they've started to make moves in this direction, freeing up keybinds that were previously hard coded a o fingers crossed the action menu may be in thier sights for the future IF they see it as doable and worth doing. Hopefully they do.

One question: How would you handle the 40 second timer on explosives? This is a context-action BUT I don't like the idea of just double tapping space and accidentally setting the 40 second timer without realising it. I realise this is a very specific and potentially isolated case but it could very easily happen when placing explosives near other context sensitive objects like cars, doors, lootable objects, etc.

Correct me if I'm wrong but this feature is at least partially implimented already on both variants of the hellcat. The copilot has control of a camera pod which also has a searchlight which points wherever the copilot is looking. To activate it the pilot simply activates the external lights using the action menu.

Yeah me and my friend were sniping together with lynx's. We were on opposite sides of a valley about 300m apart, I could hear him reload louder than I could hear his shots. Kind of broke the immersion.

Upvoted. Even simply adding red/green/yellow variants for all existing weapons would be extremely welcome. Currently there are only tracer variant for the 5.56 weapons, oddly enough almost all tank cannons and vehicle mounted weapons have red/green/yellow tracer magazines even though they are very seldom used.

This would give players a bit more freedom to use weapons outside of the games established cannon but still match the tracer colours to their side. For groups/clans and mission makers the freedom to choose is never a bad thing, can't see any downside if it's simple to do.

I'm up voting this because I aggree that it's just stupid trying to predict someone's movement and hit them at extreme close ranges, something that feels like it should be the easiest thing in the world.

However, I can't imagine of a way for BIS to improve this without making it clunky and frustrating to control. It'll always be a trade off between realism and fun in this case I believe. The arma 3 movement system feels so clean and crisp when compared to arma 2 system, it would be a shame to sacrifice that.

Any news on this ticket? This would be a really, really nice feature to have access to.

Any news on this issue?