Exacte. 1 of those spares probably land in a weapon.

1 Mag + 1 AT loaded in weapon ?

finally the ability to control ai head movement. very welcomed

Is this really going to happen?

Very excited about this. Will it be a command for the config. Something like allowHeadMovement = 0?

would this be a command for the config or an ingame command, like, _unit disableAI "headMovement", I wonder?

I should point out that this ticket is more about disabling head movement for animations. You know, when you play an animation on an AI, and their head is swinging left, right, up, down - looking all over the place but at the player the AI unit is meant to be looking at / talking to.

That said, the hand wiping can be a little distracting. Might be worth setting up a second thread for idle anims?

Cheers :)

Hell yeah! So many of the animations involve AI moving their head all over the place. Please BIS, don't forget about this one :D

;)

@Benargee

I know, that and how TrackIR is working. From my own experience, there is a big difference, if you just look on your monitor from distance (with TrackIR) or you have the feeling, to be in the game (with a HMD). Every shaking or swiping hands infront of your view would be distracting or can cause nauseated feelings.

This is assigned? WOO! :D Very, very exciting news!

You can really see the difference by setting damage to 1 on an AI character and then playing a cutscene animation. No head movement - it's brilliant! Trouble is, you're stuck with a dead unit :P

A feature to disable head animations would be great. Especially if Bohemia Interactive decides to support the virtual reality head mounted displays. Nothing would be more anoying than a shaking head and a hand, that wipes your virtual sweat from your forehead.

@Koala

Arma 3 already has head tracking in the form of TrackIR. This would also currently be an issue for those users too. Headtracking would be handled the exact same. If it is not giving TrackIR users issues, then it won't affect VR goggle users either.

Totally agreed.

Yes, yes! A thousand times yes!

Thanks for the Info, than this ticket can be closed

The most famous sentence:"It's a feature not a bug!"

That is a feature called weapon resting, not a bug.

+1 you should be able to refer to the weapon's memory points (perhaps using some prefix, or memory point names should have a rethink (to avoid cases where you'd have two "eye" memory points for example) but that could just come down to intelligent use of naming conventions).

Otherwise as Alwarren said having "eye" memorypoint in the scope isn't really feasible; the current implementation should be improved.

*sigh* Do you even know what I am talking about?

I *am* a modder. I did, among other things, the CUP Weapon pack. In that pack, we have a number of eastern weapons like AK's, Bizon, Saiga12k and others that all use Dovetail side mounts. Dovtail mounts are made in such a way that you can still peek underneath them to see the weapon's original iron sights. These optics do not have a backup sight, since the original weapon's iron sight fills that purpose.

Now, the problem is, a Dragunov is very different from an AK-74 or a Bizon. Putting a memory point in the memory LOD of the optic is out of question, it will never align properly with the iron sights of the weapon. Therefore, it would be nice if modders could specify that the original 'eye' point of the weapon's memory LOD could be used instead, making such sights usable AND accurate.

I hope that makes my point clear

You should contact creators of the mod not ArmA staff about that. Vanilla ArmA 3 has scopes with alternate sights.

Of course you can, but by that argumentation, you don't need backup sight. I don't want to have to remove the PSO-1 from an AK all the time I go into close quarter, it's neither realistic nor practical.

And I am referring to mod weapons because there are no Dovetail mounts in the base game, last time I checked.

Why are you referring to mod weapons? In ArmA 3 you can access iron sights by detaching the scopes.

OK, todays version of 1.52rc (1.52.132483) has fixed issue 2 again. Thanks!
P.S.: None of your change logs seem to mention this fix. Did you fix this unintentionally? ;-)

With glitch about geting into the wayy it works with stones as well. As of the issue nr 3 its one of most rated issue to fix since two years, but as burkhar says its complicated. Walking in buildings should be fixed and it would be get rid of the stone problems as wel

Hello, issue 1. is fixed in 1.49 DEV branch and will be part of stable 1.50 update. Working on other parts - however some of the issues are technically complicated and I have no ETA yet.

Thank you for your feedback and have a very nice day!

Unfortunately, todays version of 1.52rc reintroduced issue 2. I hope this change will be reverted again for the 1.52 final.

Hello,

I can confirm that issues 1. and 2. are fixed in 1.50rc. For issue 3., there exists an other ticket (as mentioned by Fighting Power). And the mentioned glitch is at least more complicated now:

Walking with lowered pistol against a wall and stopping there still makes the character to be slightly pulled into the wall, but simply pressing "s" afterwards is not sufficient anymore. You have to press "a" or "d" to walk sideways and use the mouse to rotate the body through the wall.

So I think the "correct" fix would be to _not_ make the character being pulled into the wall at all...

As the first three issues are fixed/duplicates, you might either close this ticket or keep it open to track the fixing of the glitch.

P.S.: Thank you very much for fixing the first two issues already! *thumbs up*

fixed

I'm unfortunately unable to reproduce.

Thank you, fine sir. This fixed the issue.

Hello,

there's an issue with automatic repair of corrupted user settings. Corrupted user settings is not detected correctly and the application the continue to run and crash because of it.

Try to run following hotfix, it will remove corrupted settings: http://arma.jiripolasek.com/files/CorruptedUserSettingsHotfix.zip

OK both issues are now fixed, you can confirm it, thanks.

no I just have steam overlay and sweetfx.

seems works but if I don't use sweetfx I encounter with this issue that I reported you before and you didn't investigate that:

http://feedback.arma3.com/view.php?id=22296

so what now?

Try launching the game without SweetFX and see if that works.

Are you by any chance using razer synapse or overwolf overlay?

Defiantly Shadowplay. Been playing without it enabled for a good hour and no crashes. It's a shame it's not compatible atm.

Where is it resolved???
This is an heavy problem V1.48, windows 10. GTX970, no shadowPlay.

I just had this shit looking at the config viewer from editing a mission with one unit (player) placed. What heavy environment!

The minimum to write is why you consider as resolved!
BE CREDIBLE!

I had Nvidia's Shadowplay running and have turned it off, I don't seem to have crashed straight the way, I need to test it more but i'm hoping that it's Shadowplay causing the problem.

@SilverDude Hehe, i was unaware, guess i should have searched, but the the addition of this shouldn't be complicated to add in game at all, would be another little touch to make things feel just that much better.

Yes please!

Even though I'd already seen a ticket like this *cough* ~duplicate~ *cough*.

You should also be able to put your primary weapon on the back with the same key. Hands free on demand.

Upvoted!!

I was not saying that the fix for my issues was the fix for this, i was intending to say, that i fixed my issue and as a result the vehicle now has this issue.

I was also making the observation that it is not a issue limited to APC/TANK simulation, it is actually more likely tied to the hideProxyInCombat property, as the exact same thing happens in a Car_F vehicle if you allow turn in and the driver does turn in, he is then invisible.

This is a different matter.
If you set hideProxyInCombat=0, you disable the option to turn in/out for the entire vehicle and every passenger will be forced to turn out, not just the driver. For some vehicles this may be usable (single person vehicles), but for others this is no good.

It doesnt fix the problem that you can't kill a driver by penetrating shots when he is turned in in a normal tank, because this command is unusable for a normal tank.

It looks like this is not only affecting tanks. My issue id=24782, was solved by using 'hideProxyInCombat = 1' in the Car_F class, which resulted in the driver being invisible in the external views.

Fixed on Dev version!

Please refrain from duplicating issues. Thank you.

Thank you for your very constructive feedback