As a tooltip when the marker is rolled over would be the most sensible.

I'd like to see third person turned off completely. It's unrealistic, is a cheat method, and obviously attracts the wrong kind of players.

Now that is odd, and I can confirm that it is not fixed. However, the gunner was wearing a rebreather when I checked the first time after the hotfix, and hence the post.

This appears to be fixed in Version: 0.71.106777

I'm able to confirm this in Version: 0.71.106777 too.

Not only can you not switch from gunner to driver, but telling your subordinate driver to dismount causes him to drive to the shore before doing so. Once he has dismounted, the switch position command is available.

The HEMTT and Zamak now display a proper rear view, but as pointed out by Semiconductor, they do not show the vehicle body.

The Marshal and Marid still show a generic environment map. I suspect the Marshal's driver view is unfinished (no instruments, rear facing camera etc) while turned in, but the mirrors while turned out should show the rear view. The same could be said for the Marid, but like the Zamak, the right hand mirror is barely visible from the driver position anyway.

Agreed, and thank you.

Ok, that means you now get my vote :)

This would be open to abuse, and sounds like a preamble for Steam achievements. In a sandbox game, those kind of statistics are irrelevant, but could easily be implemented on a server for members statistics.

I can't vote either way on this.

Agreed. My search foo failed me.

Those enhancements would be great SuicideKing. I have a feeling that the throw feature is currently incomplete, and perhaps something like you suggest will come later.

This issue was intended to draw attention to and raise the profile of this feature.

This is a good suggestion. I have a similar request for an an enhanced attachTo command #0008488 that would compliment this.

As soon as I opened your mission I realised my mistake of not assigning the added waypoint to a var. For some reason I persisted in not using assignment while creating the reproduction steps, yet I had initially when the problem was first encountered.

The backwards error of "type array expected nothing" and cryptic rpt entries don't help matters.

Waypoint 0 is the starting position of the unit. It is immediately completed, and the current waypoint becomes -1 if there are no further waypoints assigned.

Using addWaypoint [position, radius, 1] has the desired effect, and can be subsequently assigned a type using [group, 1] setWaypointType "xxxx" Perhaps this is what IconoclastDX is doing, but without further elaboration, it's hard to tell.

I've tried to reproduce this issue, and can confirm that using setWaypointType does work correctly when used in a trigger activation field, and I would suggest that the initial reporter is seeing the results of the addWaypoint error. #0009251

This seems related to, if not a duplicate of #0009251.

I only had trouble with addWaypoint, but will re-check that this indeed the case.

Scripting aside, there are simply too many items to put into one container, and the menu would become slow and cumbersome.

We already have containers which have items for each category - weapons ammunition etc. As the number of items increases from the current alpha content, I'm sure items will be added to these to ensure availability as it has been historically.

If you beleive items are missing from these containers, please report them as such, but this request is folly imho.

Down voted

I can confirm this. approx 2 seconds is all.

I also attempted to remap my keys to 2xC for Combat pace toggle, and C for "Combat pace 3 sec". It seems the short duration overrides the toggle and neither of them work on double tapped C.

This has already been reported #0008381

I've updated the description to reflect yours.

The setting you are looking for that prevents enemy recognition is:

"Allow full HUD info" - Disabled

I was tempted to report the distance check without rangefinder, but reconsidered as it would be beneficial for inexperienced players to judge distances. I haven't found a difficulty setting for it, and agree that there should be one.

That's a good point, and I didn't quite make that clear when I said it often overrides as the default option. It also seems the icon does not necessarily indicate the action either. Updated description to make this clearer.

I believe it is related, and reported here #0009378

Please note, this should not relate to the weapon instance on the ground, which in my opinion should be treated as a singular assembly for pickup. #0005233

Where the weapon is linked, and therefore appears in the inventory of the corpse or disabled soldier, the weapon can quite feasibly be considered as a complete item, or consisting of its component parts by opening the weapon, Any individual part can then be taken in much the same way as a vest or rucksack.

I can confirm this, and I first noticed it while playing through the infantry showcase. The downed man has an RCO scope on his weapon which would be useful to the player. The weapon must first be taken before the scope can be removed. This action also fills the players inventory with bulky ammunition, so the scope will disappear if an attempt to drag the scope to the players "full" inventory.

I have opened a ticket #0009368 which is related to this asking for linked weapons to be treated as sub containers which would also alleviate this problem.

To expand on the reproduction steps, the following observations can be made.

Dragging any item from the players inventory to an already full container [corpse, disabled soldier, crate, vehicle etc] and release. The item is not placed in the container, nor does it return to the players inventory. In previous series the item would be dropped outside of the container. Result, item is lost.

Dragging an item from one slot to another full slot within the players inventory will highlight red, but releasing the item does not return it to the original slot. Result, item is lost.

I can confirm the problem with both snipers on a local dedicated server. Screenshot attached.

Confirmed as a duplicate.

@Sneakson Use # followed by the issue number to embed links to them.

eg #0001819

All clear does not mean alertness drops. It simply means no more discovered enemies. The AI will remain alert for a time after contact has finished, and these reports also confirm that squad members are still combat effective and they remain alert for new threats.

I understand your meaning now, and perhaps you could amend the description/title to reflect the inappropriate use of "covering fire" while not in contact?

I'd like to refine this a little.

Assigning a variable with concatenated strings using the form myString = myString + myString does not have an effect on performance. However, as soon as this long string is used in any way - output to screen, rpt file, or sent to callExtension, a performance hit is encountered. The severity can range from a short pause, to a complete hardlock.

The heads of standing humans clip through the roof of the bunker. When ragdoll starts after death, the clipping prevents the bodies from falling.

Attached image shows dead civilian caught in pose by headclipping. (White hot TI used for clarity)

That does make far more sense when explained. In the heat of an edit session, little quirks like this can completely throw me. I'd normally work with a script and not the editor, so the inconsistency is a gotcha. I'm sure I'm not the only one.

Thanks for the biki attention, I'm sure it will help many.

Thank you b101uk. I was heavily amending this issue while you posted your note.

Transport is the name of the vehicle, so group transport should and does return the actual group name of B Alpha 1-2. This is not the issue at all.

I had an error while attempting to create a scenario for another issue report. Unfortunately I did not note the exact error, and nor was this recorded in the rpt, so the exact error remains unknown. I did however resort to the debug console and typed the following into the exec field:

group transport addwaypoint [position player, 0, 1];

This had the desired effect, and the same command was attempted in the activation field of a trigger. Unfortunately this will not work, and threw the error as reported. As soon as I read your mission in the other issue report I realised the error of failing to assign the addition of a waypoint to a variable.

The net result is this. The error report is backwards as described above, and debug console allows incomplete script commands to be executed.

I absolutely agree ceeeb, but as I point out above, the incorrect form worked ok in the debug console and I became target blind with the reversed script error.

This issue appears to be resolved now. Title updated for moderator attention.

Still present in beta (0.71.106762).

I support the proposal in principle, but do see that some ingame menu items would have to be exported to the "launcher gui". Expansions, the whole multiplayer, and mission selection menus would need to be externalised as currently they use the engine which once loaded, is locked to the mods it is launched with.

In essence, I believe you are asking for the engine to be used for rendering the game elements only, and menus to be moved to a launcher for the engine?

I am unable to reproduce your report. The shadow is clearly seen in both 1st and 3rd person views. This has been tested with and without night vision goggles equipped.

Maybe some more information and a screenshot would help?

Tested on Version: 0.61.106023

I am unable to reproduce this report. The player character will assume any position whilst turning with the horizontal mouse.

Tested on Version: 0.61.106023

Note to Bullet Purveyor - Are you running any mods? This is the second of your reports I've been unable to reproduce.

Confirmed

duplicate of #0008381

I have the same setup including the same stick, but cannot 100% reproduce the problem.

After a fresh game start and entering the editor as per the repro steps, the heli did not spin up despite collective being set to full. Reducing to zero and back to full started the engine, and normal behaviour was restored.

Restarting the preview after crashing and keeping the collective on full causes the rotor to spin up and the heli to lift off 90% of the time. The odd exception cannot be explained.

One intended purpose for such a command would be for using model animation based towing #0008164

This issue was made in error after a failed upload of example mission.

Please remove and refer to #0008488 instead

Fixed in beta (0.71.106762).

If anyone else would be kind enough to confirm the fix, I will mark this as fixed.

Duplicated by #0009391

I was about to make a request for improved force feedback, and like the previous reporter, I believe raising the profile of this one is more worthwhile.

There never has been full force feedback in any of the series, except a poor vibration effect. Improvements in this area would be most welcome.

A reflection of the current surface type, handling characteristics, and current damage of all of the vehicles would increase the immersion for the player, and are important additions to any simulator.

Multiple FFB devices can be supported with DirectX, and modern hardware is capable of rendering effects continuously rather like sound playback.

It would be desirable to have a force feedback setting for each of the controller categories. ie vehicles, helicopters, infantry - each of these have their own requirements/tunings much the same as the controller inputs.

For those wanting to turn off the current offering. There is a hidden entry in the player profile:

documents\arma 3 alpha\YourName.Arma3AlphaProfile

vibrations=1; <= setting this to 0 turns off the "vibrations"

Rather than create a new issue, could this one be amended to become an improvement suggestion?

The crash on exit may be a different issue, and could be related to issue #8126

The OP's attached rpt files do not show any evidence of a shutdown crash, so this needs confirmation.

#8126 seems to be fixed as of Version: 0.57.105210, and needs confirmation.

I have a request ticket #0008488 with exactly this in mind. A towing system could be realised using model selections and the already available animation sources as opposed to script bound setDir/setpos loops etc

If a native towing system cannot be made, then please consider supplying/expanding the commands for community made alternatives?

Following the usual playthrough of the infantry showcase, and exiting appears to be fixed for me too in Version: 0.61.106023

No Mods.

I do run AiA at times, and something else I'm working on, but all testing for here is Mod free. See my rpt file.

Version: 0.58.105348 has brought the issue back for me.

Here are my repro steps that I've used all along with this issue.

Start fresh game.
Play through Infantry Showcase.
Exit via menus.

No mods and launched via Steam.

New rpt and dump attached.

Post Version: 0.59.105455 rpt (non crashing) added for comparison - Sq-arma3_2013-05-20_13-52-52.zip

I see. As I am just a reporter too, I'm unable to see your other reports, so I was unaware of another ticket.

If you really believe it is related to the same cause - in this case XAudio2_6.dll being the faulting module - then perhaps you could link to that issue?

Use # followed by the issue number to place a link to it.

I have a feeling you may have another issue ShotgunSheamuS. If you are suffering crashes at other times, and not just at game exit, it may point to another problem.

It may help if you upload your rpt and crash dumps so they can be reviewed and to confirm there is a common cause.

The issue definitely seems to have gone away for me, but I will report back if it appears again in a future patch.

Version: 0.59.105455 released today does not exhibit the crash for me.

There does not appear to be anything in the changelog that might address this issue other than a new exe.

Can anyone else confirm?

I may have been premature in reporting it was fixed for me. It now appears to be more specific in that a mission/editing session must be done first. Simply entering and exiting the game does not produce the problem.

I also have a Realtek sound device ALC892, but as mentioned earlier, I use the AMD high Definition Audio via my monitor's HDMI for playback most of the time.

High GPU usage has been noted before, but this is not 100% reproducible for me. Other observations are High IO activity associated with the crash, but again not 100$ reproducible. These observations are taken from Process Explorer and are specific to Arma 3 process.

Furthermore, it does not appear to matter which exit method is used. Following the menu, closing the process window from the desktop or task bar, or using Alt-F4 combination.

I use the headphone socket on my monitor so I'm using a High Definition Audio Device via HDMI.

Using motherboard sound device produces the same results. Current sound configuration is set to use all devices for playback.

This issue no longer appears in version 0.57.105210 for me. can anyone else confirm?

This crash only occurs on game shutdown.
It appeared after the audio fixes.
Faulting module XAudio2_6.dll

Supplemental information:

If A3 is left running for extended periods of time - overnight - the audio ceases to play (silence) yet there does not appear to be any errors. Power mode set to Hi-perf, so this can be ruled out.

rpt, dxdiag and evt files for last two crashes attached. prefixed Sq

Please note: Second crash is after a fresh boot to rule out external issues.

Related to, and not worth a possible duplicate report is this:

When typing into any watch field, due to the issue reported here, the rpt file quickly fills up with errors due to the incomplete commands and strings typed into the watch field.

Perhaps a button to toggle the watch may help here?

The execution of the watch is automatically toggled off when the contents of the watch field change (to prevent rpt spam) and can also be toggled off manually for when the watch is not required, but the field contents are preserved.
Manually toggling on at times the watch is actually needed.

The speed of execution is a requirement, and I believe the initial reporter means during typing of the field values in this respect.

This behaviour may explain why some missions can crash after being paused for any extended period (speaking of arma series in general) It would appear that although the simulation is paused, evaluation of vars, and possibly scripts continue. The debug console apparently exposes this.

We currently don't have armour for soldiers. The more complex vest system with dedicated slots for current items you originally describe would be a start, and perhaps a more customizable system could be added later?

This suggestion makes sense.

Related issue #0006862

I have created a feature request related to this asking for attached objects to follow rotations when attached to model selections #0008488

To expand on the difficulty in accessing the inventory regarding the areas of action I have created an issue for this #0009378

Related issue #0007586

Ok, I'll bite.

Consider the image below which uses the very large interface option.

https://www.dropbox.com/s/7bd8n04vzzdts6g/Very_lg_interface.PNG

Opening your own rucksack implies that it is taken in hand and opened. The rest of your loadout is known to you, and should be easily accessible - I can reach into my own pocket, take a coin and put in another with my eyes closed - the present system adds this familiarity via a screen graphic.

The loadout of the corpse should not be known to you, so therefore cannot be shown as such.

@bez The corpse is nothing more than a crate with sub containers. As I pointed out, these can be opened by double clicking. The layout is to reflect your characters load out, and that of the corpse may be significantly different. Your proposal would work, but it does take a lot of screen space. The only bug, is noted below.

I've just opened a ticket asking for the linked weapon to be treated as a sub container #0009368

The problem of items disappearing is due to trying to drag them to a full inventory or sub container #0009367

Selection of the correct inventory container to open when at a dead body is difficult. The areas of action seem to be further away than is plausible, and because they cross over, it becomes confusing. I would suggest decreasing the action area.

@bez, There is no need to remove any sub container. The vest can be opened on both the corpse and yourself, and items can be dragged between them. Simply double click the sub container (vest, ruck) to open, and use the ground menu item at the top to return to the main inventory.

I vote up, but would like to see it implemented as an option that is unbound by default like some others.

Apart from accidental discharge while manipulating ingame objects such as rucksacks, there is another cause. Alt tabbing for any reason will usually result in any LMB mouse clicks being buffered and then firing upon return to the game.

If the possibility to place your weapon in safe mode exists, there can be no excuse given for team kills due to no option to make safe.

Generally I agree with this request, and I'd like to see a similar serverside control for maximum gamma/brightness as view distance.

However, it's worth pointing out that there may be perfectly legitimate reasons for a player to turn up his ingame gamma. EG I have a projector that has seen better days, so without this adjustment, playing would be impossible. That said - faulty or old equipment just means that a particular server cannot be played on at night.

Update:

It is possible to run concurrent instances after applying the fix mentioned in ~0008202. This does not defeat Steam, nor does it allow multiple installations using the same activation key for LAN play for example. Attempting to join an online server may trigger duplicated key alerts, or even result in your Steam account being revoked.

The old method of adding -window -nopause to a shortcut created from arma3.exe will enable full testing of MP missions and addons between two or more windowed clients depending on the host machines hardware of course. Simply run as many copies as required from the same shortcut.

While the game is in alpha, and beta for that matter, being able to run more than one instance of the game for testing purposes locally is very important for feedback.

Issues such as #0000716 especially in MP are very hard to reproduce consistently, but could possibly be understood when tested under controlled conditions.

Beyond that, it would also be nice to be able to run a limited LAN capability when Arma3 goes gold.

Addon and script development that have a strong network component are almost impossible to refine where differing machine hardware, random network problems, and finding willing test partners simply exacerbate the issue.

Even with two activation keys for Arma3 it is impossible to run two instances. Steam prevents two activations under the same user, and only one user can be logged in at a time. For the record, this is not mentioned in the EULA either, and cries of piracy are rather moot.

I can confirm that crouch toggle in combat mode only goes down and not up, but not the aiming issue that Alex72 reports.

Version: 0.61.106113

I believe this was once attempted in the past. There were config entries, and even animations for fists. I don't know why or if it's been totally abandoned, but the previously quoted config entries show that it has at least being entertained.

Melee in close quarters is still an important aspect of warfare. It's down and dirty, and is avoided if at all possible, but it does happen. As a device in ArmA, a player only (AI would probably have major difficulties deciding when to use melee) would be nice. However, sneak attacks are still nigh on impossible due to the AI's awareness attributes.

As for the COD like argument - Arma isn't the same, so running around armed only with a knife would lead to a very quick dispatch, so that argument doesn't hold water imho.

Entering a small room to find an enemy armed with a heavy machinegun, and quickly taking them out with a knife/butt, or other melee device would certainly have merit.

I'm on the fence on this. While it would be convenient to take a stack or take all, there has to be a tactical penalty for picking over inventories. Insta pickup gives the player who has expended their ammo the advantage over the player who has been more economic and could take the kill while you're picking through items.

On balance, if this were to be implemented, then it should be difficulty based. A non vote from me unless it's more refined.

To me the answer is simple.

PIP or RTT should optionally be used for the peripheral unzoomed view. The true zoomed "picture" retains all of the fidelity while the RTT can, and should, be low quality/blurred. This would simulate our real life motion detecting ability of peripheral vision.

Only a minor advantage is given to those with powerful machines by having a wider field of view, but target recognition would be hard due to the low resolution/blur effect, so the potential target would need to be acquired through the lens. This could actually be viewed as a disadvantage in some respects.

How did this turn into a heavy weapons and ordnance request?

To be able to fire small arms for suppression while moving, and as a relatively protected steady firing platform while stationary is enough in my opinion.

Given the assault boat passenger positions, I find it hard to believe this isn't going to be realised at some point.

This may be a little pedantic, but the title should read "Passenger firing from open vehicles"

It's been pointed out that not all vehicles would be suitable for this, but where they have open sides/tops, or are fitted with firing loupes as in the case of the BMP, then a gunner view could be added to the appropriate passenger positions.

The traversal and elevation of weapons would be very restricted of course, as well as a limited view, but for suppressive fire, and when the vehicle is correctly positioned, directed fire, this feature would be a godsend especially in multiplayer scenarios.

I can confirm this is still in the latest dev build Version: 0.61.106195 via the F12 screenshot key, and with print screen.

There are workarounds for windows 7 that involve running the game as administrator and disabling desktop composition, but these methods should not need to be resorted to, and expose security holes.

If F12 wrote the captured image to a folder in the users documents, then alt tabbing is no longer required to paste the clipboard contents into another application.

I believe #0008544 to be related to this as far as controller inputs are concerned.

You make some valid observations b101uk, and this makes a more compelling argument to provide a more comprehensive axis profile and mapping configuration tool.

Aside from the inconsistent climb rates for analogue and digital, there is an interesting side effect. If the analogue control is used alone, and then a digital input for climb is made (keyboard) this has the effect of centering the analogue control.

This can be an effective altitude hold in the hover, but unfortunately comes back to bite as soon as any cyclic inputs are made - the collective must be fully lowered and raised to re-calibrate the axis.

I've tested with concurrent analogue controls (Saitek Cyborg force 3D and Logitech extreme 3D pro) which both have the same analogue rate of climb, so it appears that only the digital inputs have a different rate.

The same happens while viewing the map too.

To clarify the problem - The mouse pointer can move away from the main render area in a multi-monitor environment. This can cause undesired effects. The other monitors can be virtual ie on another machine if a tool such as Synergy[1] is used.

A lock cursor to screen option would be great. This would enable the mouse pointer to keep within the bounds of the render area without accidentally wondering off to another screen. The consequences of this is that ArmA gets minimised if the mouse is clicked outside the render area, and in multiplayer could be fatal.

Live For Speed[2] has such a feature btw.

[1] http://synergy-foss.org/
[2] http://www.lfs.net/

Deceiver has already touched on this, but take a look at the animations for equipping binoculars.

The primary weapon is slung muzzle down from the shoulder, and then raised from this position afterwards while standing.

From the crouched position, the primary weapon is placed across the lap.

While prone, the primary is placed on back.

The binoculars are stowed on the left however, and maybe this is one complete animation, but these seem to fulfil the requirements of this ticket if the animations can be linked correctly.

I still think that (G) or grenade key should equip the "Throw" weapon much like drawing a hand weapon. The player can then position themselves, or run into cover before throwing. The actual throwing mechanic could also include modifiers for over-arm and under-arm - lobbing over hard cover and through doorways as required.

I agree that while it has improved a little, it is still far too arcade in its present form.

Related to "Double-Tap keys don't care about qualifier keys" #0009957

Duplicated by "Hand grenades are too easy to use" #0009734

Just to clear some points up.

1. Automatic weapons need an initial chambered round to be able to reload the contents of a magazine automatically.

2. An expended magazine uses all of the rounds, so loading a new magazine means that a round must first be chambered (cocked) before firing.

3. A tactical reload means changing the magazine before it is expended. Therefore satisfying number one, and avoiding the added cocking time of number two.

4. No rounds are lost with the current system, they magically get removed from the weapon and reloaded into the magazine when it's removed.

5. Because of number four, No round is left chambered, we are returned to to number two, and a longer time to reload is the result.

6. Taking a 30 round magazine as an example, a combination of number one and number three means we should have a full magazine plus one chambered (31 rounds) and a weapon ready for firing immediately.

Animations have nothing to do with this issue apart from the complete magazine change and re-cocking is played every time which in itself increases the time before the weapon is ready to fire.

This is one of the first things I noticed. In fact the collision models also have the strange effect of making other objects inaccessible. For example: Underwater showcase mission - Killing of the enemy divers, or boat crew means that their inventories are impossible to access because they have fallen through the collision box. They are visible, but the player cannot move close enough to pick up.