Yup can comfirm this. It actually saves the "state" of the vision mode for each fire-rate setting individually.

As SaOk mentioned above, and I confirmed, it does indeed seem to be fixed. So I believe this can be resolved, yes.

Thanks again for getting at this (or getting Steam at this) issue so quickly!

Have a nice week! :)

I can confirm this. I just updated my mission and re-added the voice-acting work. Downloading of the mission now works as planned.

Seems this issue is fixed! Great work all round guys!

So, there appear to be multiple limitations that have been placed since the 12th of September or thereabouts:

Limitation 1: No audio files in the missions.
Limitation 2: No missions above 2MB.

Edit: Can we please get a Dev to confirm this?

Yeah, thanks for letting us know! :D

Hmm, in testing my mission went from about 1,376MB where it worked to 1,484MB where it didn't work (adding two .ogg files).

So I don't think there is a 2MB file-size limit... Anything else you may have removed, other than .jpg and .sqf files to bring the file-size down?

Hey guys, spent an hour or two trying to nail this issue down some more, here are my findings:

When you remove all your .ogg files, the mission is downloadable from Steam again.
The number of files or size of the mission doesn't seem to have an influence on this.
Changing the file-extension from *.ogg to something else (e.g. *.sqf) still causes the issue.
Converting your .ogg files to .mp3 causes the same issue.

It is my guestimate that Steam is blocking all missions with an audio-file in it, as to cover themselves from possible copyright-infringment lawsuits caused by idiot people uploading missions with copyrighted music in them. This is too bad for us that just use the custom sound features for voice-acting and the like.

Here is my mission on which I tested all this, see the change-notes:
http://steamcommunity.com/sharedfiles/filedetails/?id=178547195

Here are some other feedback tickets with the same issue:
http://feedback.arma3.com/view.php?id=14400
http://feedback.arma3.com/view.php?id=13034

Jup, same issue here with http://steamcommunity.com/sharedfiles/filedetails/?id=178547195

So, after testing (see http://feedback.arma3.com/view.php?id=14440) there appear to be multiple limitations that have been placed since the 12th of September or thereabouts:

Limitation 1: No audio files in the missions.
Limitation 2: No missions above 2MB.

I have same issue.

Hey guys, spent an hour or two trying to nail this issue down some more, here are my findings:

When you remove all your .ogg files, the mission is downloadable from Steam again.
The number of files or size of the mission doesn't seem to have an influence on this.
Changing the file-extension from *.ogg to something else (e.g. *.sqf) still causes the issue.
Converting your .ogg files to .mp3 causes the same issue.

It is my guestimate that Steam is blocking all missions with an audio-file in it, as to cover themselves from possible copyright-infringment lawsuits caused by idiot people uploading missions with copyrighted music in them. This is too bad for us that just use the custom sound features for voice-acting and the like.

Here is my mission on which I tested all this, see the change-notes:
http://steamcommunity.com/sharedfiles/filedetails/?id=178547195

Here are some other feedback tickets with the same issue:
http://feedback.arma3.com/view.php?id=14440
http://feedback.arma3.com/view.php?id=13034

Yeah, noticed this too.

Problem is that it's the horizon line that is moving, rather than the W shape. And also it's moving inversed to how it should.
And yeah, duplicate of http://feedback.arma3.com/view.php?id=13259

This is a duplicate of http://feedback.arma3.com/view.php?id=13259

But yes, annoying issue. Flying IFR with this is very difficult...

Don't want to unnecessarily drag this ticket up when it is already marked as "reviewed", but what does "reviewed" mean exactly? That they are yet to assign it? Or that they didn't feel it needs fixing? Or what?

Please fix this, flying IFR is veeeery difficult with this...

So, after testing (see http://feedback.arma3.com/view.php?id=14440) there appear to be multiple limitations that have been placed since the 12th of September or thereabouts:

Limitation 1: No audio files in the missions.
Limitation 2: No missions above 2MB.

Hey guys, spent an hour or two trying to nail this issue down some more, here are my findings:

When you remove all your .ogg files, the mission is downloadable from Steam again.
The number of files or size of the mission doesn't seem to have an influence on this.
Changing the file-extension from *.ogg to something else (e.g. *.sqf) still causes the issue.
Converting your .ogg files to .mp3 causes the same issue.

It is my guestimate that Steam is blocking all missions with an audio-file in it, as to cover themselves from possible copyright-infringment lawsuits caused by idiot people uploading missions with copyrighted music in them. This is too bad for us that just use the custom sound features for voice-acting and the like.

Here is my mission on which I tested all this, see the change-notes:
http://steamcommunity.com/sharedfiles/filedetails/?id=178547195

Here are some other feedback tickets with the same issue:
http://feedback.arma3.com/view.php?id=14400
http://feedback.arma3.com/view.php?id=14440

I'm having the same issue with my mission: http://steamcommunity.com/sharedfiles/filedetails/?id=178547195

I already tried republishing (deleted the old mission from Workshop), but still no-go.

Is this on our side? (e.g. naming of the mission, downloading from specific Cloud server?) or is this on the Steam side? (e.g. corrupted Cloud, bad links, etc.)

Please tell me how to fix this!

Noticed this too

Confirmed, but I also seem to remember this wasn't the case in a previous version... Perhaps it broke somewhere along the development line...

Dude.... Note the difference between MISSILES and ROCKETS.

The ROCKETS in the AH-9 are unguided, which is why the HUD doesn't stray.

The MISSILES in the AH-99 are guided, which means the HUD does stray, so you can lock on and fire-and-forget those beauties.

The missiles are fine, but the Gattling gun is seriously underpowered (especially against infantery).

Right now you need to hit infantery dead on in order to hit them. Realistically just the round whipping past them would knock them unconscious, let alone the explosion next to them when the round hits the ground.

The gattling gun's rounds need a splash damage effect for infantery. Doesn't need to be insta-kill, as long as it does SOME damage.

When you create your own render with
camera1 = "camera" camCreate (getPos player);
camera1 cameraEffect ["INTERNAL", "FRONT", "myRenderName"];
"myRenderName" setPiPEffect [0];

then the setPiPEffect works. You can name your own renders using the third argument in cameraEffect. (This is currently undocumented on the Wiki).

Note that doing:
camera1 cameraEffect ["INTERNAL", "FRONT", "rendertarget0"];
actually overwrites the PiP in the vehicle and shows you your camera-view. But it seems to overwrite back randomly, works on all vehicles simultaneously, and is overall completely randomly breaking. Definitely unintended behaviour that can sometimes be exploited. I tried to do so for a mission I am working on, but it seems to work differently for MP vs SP as well. The whole thing is weird, but then again, not really intended as such either.

The best would be if the devs would add some more memorypoints to all vehicles, for the various MFDs. That way you could just use setObjectTexture on them.

so for instance:

heli setObjectTexture [0, "#(argb,256,256,1)r2t(myRenderName,1.0)"];
currently renders your camera on the entire outside of a heli.

Would be great if:
heli setObjectTexture [1, "#(argb,256,256,1)r2t(myRenderName,1.0)"];
would render on the left MFD of the pilot

heli setObjectTexture [2, "#(argb,256,256,1)r2t(myRenderName,1.0)"];
would render on the right MFD of the pilot

heli setObjectTexture [3, "#(argb,256,256,1)r2t(myRenderName,1.0)"];
would render on the left MFD of the gunner

heli setObjectTexture [4, "#(argb,256,256,1)r2t(myRenderName,1.0)"];
would render on the right MFD of the gunner

But these memorypoints aren't in the models. The only point available is [0, ...], which renders to the outside (cameo).

I think the volume levels are fine. And you can manually adjust them, so I wouldn't change a thing.

How do you enter spectator mode after you die?

There are other games that use this technique, but have different texture overlays for different locations. So a 'field', a 'forest' an 'urban' an 'indoor' etc.

Also, for the helicopter reflection there should really at least be different ones depending on weather. If is is stormy the reflections still show a bright blue sky.

I also vaguely remember it being fixed at some point, but it quickly reverted back. Not sure though...

At any rate, it indeed appears like the "camera" for the player (display 46? not sure it works that way...) stays in the same location when you enter the map, whilst it should follow the location of the players character. As stated in the ticket, is is immediately obvious that the sound "stays behind" when in a vehicle.

But also as stated, when in the map for a significant amount of time, and you travel a far enough distance away in that time, when exiting the map, the rendering needs to catch up with the new world terrain and objects that have suddenly come into render-view.

A minor issue, but probably a minor fix as well, and certainly worth fixing.

I understand what you mean, but you explain it in a weird way.

Basically what is happening is that when you open the map, all sounds stay relative to the location you were when you opened the map. So indeed if you were in a helicopter, and you opened the map, you would hear the helicopter flying away from you.

This would be a simple fix. In psuedo-code:

"Update audio-receive-location to equal location of player" is not running whilst in the map, as there is no 'camera' for the player.

Jup saw this behaviour too in my mission making. Tried for days to find a work-around. In the end just used unitCapture and unitPlay to force the choppers to land where I wanted them to.

I noticed this when it was raining. Sat on an ATV and the rain sounds stopped. The game engine assumes all vehicles have a roof I think... In my experience the environmental sounds didn't start again after a while, but didn't double check that.

If you go into 3rd person view of course the sounds do start again.

I also noticed the flickering, but never stuck around long enough to notice performance degradation.

I agree with the original ticket, the TI could use some more visual "clutter" to increase the challenge somewhat.

I can confirm this. Seems the material is set to 'dirt' rather than 'metal' or however this impact system is driven in the engine.

@Raoul1234
Yes, but careless also infers a certain speed and other behaviour such as landing lights on etc. It overwrites things like stealth- or danger-behaviour. Currently there is no way of setting the unit to stealth-behaviour, but have them ignore enemies. Understand?

Same problem here. Tried literally for days. Thankgod I finally found this so that I could give up. Gonna try if setting the chopper to captive helps.
(As in: bluHeli1 setCaptive true; )

EDIT: setCaptive works, it's lame and boring, but at least the pilots land now. I'll set it up like this and edit my missions later when this bug is fixed.

What bothers me most is the fact that the KA-60 cockpit windows are bullet-proof.

Having a parked KA-60 and letting a squad with just machine-guns attack it, the pilots are pretty much safe from any harm. You can shoot all your bullets into the window without even a scratch... I get that they are designed to be bullet-proof, but bullet-proof windows in real life are really just 'bullet-resistant'. After several rounds they will give way. And so they should in the simulation.

Noted this too (in multiplayer).

Your own flashlight is very bright (perhaps a bit too bright) whereas anyone elses is very weak. Conversely from their perspective their own flashlight is the only bright one.

Perhaps this is a limitation of the engine limiting the amount of dynamic lights vs mapped lights or something.

Would love it if all flashlights were equal.

Could we get a dev to explain this decision, or is it actually a bug?

On a separate but related note: Devs, do AI see us better/earlier at night when we have flashlight/laser on vs off?

Great troubleshooting and testing, awesome job!

I don't think you seem to understand that this is a realistic simulation of weapons handling, not an FPS shooter. The general result of most real life combat shooting is to suppress rather than kill. Especially for automatic weapons and LMGs.

Try changing the fire mode of your weapon to semi-auto and take your time lining up a shot. You shouldn't need more than 1 or 2 hits to kill a target, so certainly not more than 4 or 5 bullets fired down range.

fenix395, can you double-check your version number then, because it's fixed in my build...

*EDIT* Ok, great! */EDIT*

Yes, confirmed it is fixed in Alpha (Development) 0.53.103478.

Thanks!

I can confirm this.

It seems with the death-screen they fade out all environmental sound to show this 'UAV-like' death screen with computer-sounds. When you then team-switch into another unit the computer-sounds remain and you cannot hear the environmental sounds from the perspective of your new unit. Radio-chatter works normally.

Definitely a major issue for people playing single-player sandbox in the editor.

This is no longer an issue. The "sharpness" of the sound is gone, and the volume seems to be normalized a lot. Perfect! Thanks, this issue can be closed. :)

This is fixed.

Ah... I may not have had them in my main inventory... Thanks!

When a helicopter crashes into water in real life it doesn't always explode in a fiery ball of explosions. (Unless Michael Bay is on scene).

In my case I shot the tail-rotor and the pilot lost rudder controls and was able to crash land safely rather softly into the water. The engine turned down slowly.

Play it again and you might have a completely different outcome. That is kind of the joy of replayability in ARMA.

Got same problem with Windows7 Ultimate 64bit - Radeon HD5850
Got everything texture-related on Ultra (including the distant/shallow-angle rendering option)

I'm not 100% sure what you mean, but in my mind double-tapping K to bring up the compass, double-tapping O for your watch or right-CTRL+M for bringing up your GPS all simulate you using your off-hand to keep track of additional information constantly.

I can confirm this for low-prone at least. Haven't tried the other variants yet.

Great testing, suggesting and information. Kudos!

Number 1: has already been reported and is actually in the Known Issues list already.

Number 2: That's strange...

Number 3: This is the standard walking animation. You can perform this with any soldier by double-tapping left-ctrl to bring down the weapon. I believe it is the standard walk to simulate readiness (for grabbing sidearm), not total casual walking.

Number 4: I believe this is known issue as well.

Number 5: There are two types of Rocket Propelled Grenade launchers in the mission. The one you most likely were holding was the one that locks on to ground targets. There is an Anti-Air (AA) specific RPG in an ammunition box on the roof of one of the command buildings in the enemy camp.

Hope this helps!