Thank you for the correction and the info, KK. As I suspected, setVelocityTransformation is probably what is needed. Also thanks for the BSim's VBS wiki link (ProGame suggested it earlier as well) as that is indeed much more informative than what's available on the Arma BIKI. Another suggestion for anyone else interested in researching this command is to look at the BIS_fnc_unitCapture nnd BIS_fnc_unitPlay code. I'll be investigating this more thoroughly and will report back on the BIF with my findings.

Also, please have a look here: http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-%28dev-branch%29&p=2563710&viewfull=1#post2563710.

And Killzone_Kid's comments here: http://community.bistudio.com/wiki/setDir.

And ticket #7228.

A few more notes. This is not a problem exclusize to the setDir command, as setVectorDir and setVectorDirAndUp also suffer from this issue. Although I do not have a good grasp of the setVelocityTransformation command yet, it does not appear to be a valid workaround either (I'd be delighted if somebody could demonstrate different). Also, trying to re-arrage the calling sequences of the commands - setDir before setVelocity or vice versa, for example - as well as combinations such as calling multiple times as suggested by Killzone_Kid in the attachTo ticket (#0007228) also does not work.

Can confirm the 'Warning Message: Bad vehicle type' error popping up. What is the exact classname of the magazine and the soldier who carries it that's causing the other problem? Having some issues trying to reproduce the "out of ammo" report. Also, can confirm that face/setFace commands are still broken (#0015786).

@Xendance: "I don't want it to vary from mission to mission and from server to server." My comment here is directed at you:
http://forums.bistudio.com/showthread.php?160330-Scripting-Discussion-%28dev-branch%29&p=2567592&viewfull=1#post2567592

@gammadust: Yes, I have seen some recent dev posts on the BIS forums that are making me hopeful as well. Already voted on the other ticket you linked a while back. Thanks for taking the time to post these, BTW. You're a great service to the community. :)

Yes, trying to exert any consistent control over individual AI units via scripting has always been a nightmare that has held back AI modding and scripting for years. See my brief comment here:

http://forums.bistudio.com/showthread.php?159710-AI-Discussion-%28dev-branch%29&p=2564666&viewfull=1#post2564666

The only workaround I could ever get to consistently address such issues is to throw the individual AI I need precise control over into separate proxy groups (returning them to their "home" group when finished with them), but that leads to a host of new headaches as A) your detached AI has now lost all group related functionality and B) you now have to deal with the 144 group limit and C) other nasty "gotchas" that I hadn't yet encountered and/or thought of.

Looks to me like you've established a bit of a "fanbase" amongst the trolls, ProGamer. :) Downvoters, come crawling out from beneath the woodwork and explain yourselves!

@Killzone_Kid: Can you elaborate on what you're trying to suggest? Not trying to pick a fight, I'm honestly unclear what you're refering to. I was under the impression - based on nothing but my completely unscientific gut feeling - that the cull of these commands was temporary, and the long term plan is to re-introduce them after the underlying engine components are more-than-less fully developed and under better control. Am I completely off-the-mark with this assumption?

Yeah, I just ran into the problem of no getObjectTexture command yesterday. If you're only looking for the object's original texture, you can read it from the config file, but that's a limited workaround. We really shoud have a proper getObjectTexture command.

A little off-topic, but there are actually a number of comamnds that let us set engine parameters that we have no way of reading in the first place. Seems like very strange and ad-hoc practice to have a "setThisVariable" command without its sibling "getThisVariable" included.

Or how about simply releasing the Chernarus+ as an A3 DLC? Half the price of OA's BAF or PMC DLCs?

Version 1.05.111658 and still not working. We also need a objectViewDistance command akin to the viewDistance command that returns the value(s) currently set.

@EDcase: Yup, the AI will still engage distant targets. The problem isn't that the AI doesn't engage; it's that after it's initial response (like I said, a series of rapid shots over 2-3 seconds), the AI is then struck dumb and refuses to continue firing at the target in question provided the target remains more than 128 metres out.

Issue fixed in dev build version 0.55.104462 (2013/04/24). Thank you!

Just checked and it's occuring in both Stable 0.54.103957 and Development 0.55.103960. I actually clued in on this issue after watching a couple of YT vids. Considering that some of the vids in question are more than a few days old, I think it's safe to say that we've had this problem for a few dev builds back.

@oldy41: Seeing as I'm not a modeler, this is just unqualified speculation, but wouldn't it mostly be a cut-and-paste job? ATM, there is one base house window model which would have to be re-modeled and re-worked to allow for animation. You'd also have to model a series of damage states (if the second part of my request was to be implemented). All the other window variations can then be derived from various combinations of animation and damage states of the base window model. Going in and replacing the old windows with the new ones in the various houses shouldn't be too laborious either seeing as there's actually only 7 individual house models with wondows, which are then cleverly copy-pasted across the map (granted, I expect there'll be more once Altis comes into the picture).

Don't see why A3 couldn't have this considering VBS 2.0 has playback functionality: http://www.youtube.com/watch?v=aaCVVMoDeMk. Detailed, replayable post action analysis would be an awesome tool for players, mision makers and modders alike.

If you mean that a grenade thrown through a glass window should shatter said window, then, yes, it should be implemented. Relatively trivial fix, I imagine.

NB: For the pitch angles displayed by the hint in the repro mission, 0 == straight up, 90 == horizontal, 180 == straight down.

Upvoted, but I don't expect BIS to implement this as I very much doubt charred bodies would get past the German censors. Something for modders to add, I expect.

Sigh. Please use the search function: http://feedback.arma3.com/view.php?id=2453. Also: http://www.youtube.com/watch?v=0MA1IFKwdAQ.

Same here. Think it started with dev build 0.53.103342.

I agree with the suggestion proposed by several people on the BI forums that the weapon should return to whatever position it was in before the player opened the map.

LOL'ing at the downvotes. Enter a server or mission that you're not familiar with during overcast sometime around twilight and you tell me whether it's morning or evening. Already had this problem a number of times in A2.

Just leaving this here:

http://forums.bistudio.com/showthread.php?170227-AttachToWithMovement-Walkable-Vehicle-Interriors-and-Exterirors&p=2581966#post2581966

Y'all should find it pertinent to the topic.

SmallBlackSheep, with you all the way on this and your previous 'no shadows' ticket. Adding more tonal variations to the tree textures would help improve A3's already stunning visuals - under both sunny and overcast conditions. I still think some form of diffuse shading is crucial as well.

I completely agree in principle. I also think sidestrafing is way too fast, especially since you can sprint and strafe at the same time. Combine that with extremely responsive turning and things can get pretty silly.

Lach45: "Was found in an open field on a hill. Multiple people probably shot 2-3 clips trying to hit me as I full sprinted and changed directions with just a flick of the wrist. They never shot me."

Yes, just observe players from a distance as they weave and zig-zag across a hillside at max speed while trying to dodge incoming fire. It just looks so very wrong.

But, here's the real problem: inertia and slow turn rates (ie., negative mouse acceleration) are what made A2's movement feel so clunky and unnatural in the first place. So, how do you propose to add inertia back in without returning to the drunken-gimp movement we had in A2? I wouldn't want to hamper the feeling of A3's CQB experience, for instance.

I'd suggest that the ultimate answer is probably not A3's current complete lack of inertia or A2's overdone inertia, but rather a more nuanaced system that transitions from A3 style movement at slower speeds, through slight inertia and turn rate restriction while employing tactical paces, to A2 style inertia and manueverability for sprinting. Also, acceleration lag when transitioning up to run and sprint should be introduced (something even A2 lacked, I believe). So, for CQB it should still be quite easy to move through tight, urban environments at a slow or tactical pace, but if you're going to insist on sprinting around indoors you're probably going to start running into things just like you would IRl. In outdoor spaces, OTOH, you'll be able to move very quickly through open terrain, but won't be able to deek, dodge and bounce around like a videogame sprite while doing so. Thoughts?

Is this still going? Certain people need to appreciate that there's a distinction between calling ARMA a "war simulation" or a "wargame" and proclaiming that "THIS IS WAR!" The first two are accurate statements while the latter is pretentious, embarassing hyperbole. Frankly, I think the point has been made and BIS has been informed that - judging by the current votes - a 1/3 of their fans think that the splash screen is somewhat over-the-top. Whether they chose to do anything about it is up to them, and, honestly, not a big deal either way. End of story. Now, can all the snake-eaters and assorted tough guys stop crying about how all those meddling flower children are trying to trample on their precious rights?

Upvoted. I was quite taken aback by the "This is War" screen myself. This is war? Seriously? This is a fucking computer game. It's awfully pretentious and insulring to those who've had to experience the real thing. Please stick with the much more tasteful "Surviv. Adapt. Win."

Radioman, if you're trying to return the object the player is looking at then screenToWorld is not a reliable solution. The problem is that screenToWorld fails to provide an accurate return on the height (y-axis) whenever it samples anything above terrain level (ie. sky). So, objects protruding above the landscape from the player's POV will often not return properly. Worse yet, there appears to be no other scripting command that allows for the calculation of either the player's or player character's POV pitch angle. The only script command that works in this regard is weaponDirection, but that comes with it's own problems. See: http://feedback.arma3.com/view.php?id=5878 for further explanation and repro mission.

Reporter is correct, although this bug is also present in A2! Furthermore, to complicate matters, screenToWorld appears to be in the habit of returning a bunch of nonsense within A3 ATM.

Ed: By "a bunch of nonsense" I mean that when the given screen position being sampled by screenToWorld is above the terrain (ie., in the sky), screenToWorld often returns strange y-coordinates (height) which then feeds the lineIntersectsWith command a false end position (ie. in this case, not anywhere along the vector from camera to the centre screen position).

I can't reproduce peeking down through the roof, but peeking up through the floor from beneath the structure is always reproducable by me. No need to change your stance either, simply angle your aim upwards through the floor and your character will clip through allowing you to fire into the building.

Likewise, when crawling under the building, the 3rd person camera clips through the floor allowing one to see inside. See: http://www.youtube.com/watch?v=11ZaikSE50M#t=1m30s. Grenades can also be thrown through these floors: http://feedback.arma3.com/view.php?id=3171. And another related ticket: http://feedback.arma3.com/view.php?id=2521.

Sure. Although I expect BIS to leave a feature like this to modders I'm very much for it. If this is to be implemented, however, I'd want to see realistic and accurrate stoppage rates. Not sure about the new, caseless ammunition, but here's some eye-opening results for the standard 5.56 NATO: http://www.armytimes.com/news/2007/12/army_carbine_dusttest_071217/. Note in particular the M4 at 882 stoppages / 60,000 rounds. That means nearly a 36% chance of at least one stoppage per 30 rnd mag fired!

Issue is resolved for me in 0.53.103608. Thanks!

There shouldn't be a separate control for forward/reverse, rather it should be throttle/brake and a key for switching between forward/reverse gears (just like in a real car). Next, allow both throttle and brake to be mapped to analog axes, and that's most of the land vehicle control problems solved (handling and physics notwithstanding).

Agree that the vehicle controls, handling and physics could really use some impovement - not even going to start in on the choppers, but we'll hopefully be getting the flight model from TOH at some point - nevertheless, to label this a major issue that needs immediate attention is an overstatement. Ed: Upvoted, BTW, because it's a legit concern that should be looked into time permitting.

SmallBlackSheep: "As most tickets on this site, this is a request for an optional feature. Why not give people options, so everyone can use the system he prefers?"

ert3: "this not being a feature seems like an affectation of older arma's "[simulations should be hard]" mentality "

Yes, I've noticed many UI and control feature requests that would provide extra options for streamlining, simplifying or otherwise improving unecessarily complicated - often unrealistically complicated - player interaction systems garner an inordinate amount of downvotes. I think ert3 is right in that there are many conservative minded, self-styled "ARMA experts" who absolutely hate the notions of accessibility and convenience. In their minds, easy and intuitive design only serves to increase the game's appeal to a wider audience - ie., COD kiddies. From my perspective, clunky, cumbersome controls and poor customizability of said controls make many things which would be trivial and intuitive IRL difficult and frustrating to accomplish in-game. This makes the game both less fun and, more importantly, less realistic.

Yeah, apparently I'm a total Steam noob. Just clued in tonight that the proper way to switch out of a Steam game and back to desktop is using ALT+TAB! PEBKAC; downvoting my own ticket.

Also have a look at http://feedback.arma3.com/view.php?id=4363. Seem related to me.

FWIW, the Ka-50's max roll rate in DCS Blackshark was 45° per second, so 1-2 seconds to roll 60° in the Littlebird sounds reasonable. Of course, Littlebirds are known for their maneuverability.

Yes! Confirmed. Discovered this problem a while ago, but waas unable to replicate exactly what was causing it.

I'm thinking it's got to be a placeholder.

I also think this pause is a feature that simulates recovery time after a jump or fall, but I'm sold on the idea that having an anim and/or sound to go with it would make it look a 1000 times better.

ViiK knows what he's talking about. I know it looks shit, but this is an unfortuante engine limitation that we're going to have to live with for the forseeable future.

Read somewhere yesterday that the engine programmers are still working on smoothing out and otherwise improving the shadows edges - there are tickets for those issues as well, see http://feedback.arma3.com/view.php?id=351 , for example - so the lighting is by no means finished. Once the shadow edges are improved, I imagine the team will move onto the next problem. So, honestly, I expect to see some kind of diffuse shadowing for cloudy and overcast conditions make it in before final. The eyes of those doing the A3 lighting are so good that they are certainly aware of the issue we're discussing here.

Thank you! Was just going to post this myself. The overcast lighting looks really two dimensional, unrealistic and ugly, especially compared to A3's beauty in the sunlight. And, no, a lack of shadows isn't alright under overcast - objects still cast shadows even during the dullest, darkest days, it's just that most people don't notice as they are very soft, diffuse and low contrast. Improved overcast shadows, along with terrain casting shadows (another significant oversight at present), would also make the day-night transitions a jaw dropping experience. And, a final note, it would be quite the addition to see the volumetric clouds cast shadows on the terrain below. But, to be fair, I expect the BIS lighting guys are more than aware of these things seeing that A3 has revealed them to be industry leading talents. This is still an Alpha, so, hopefully, we'll be seeing improved shadows soon.

Checked in the editor and the runway headings are 015º / 195º.

Yup, well known and well documented bug going back for years.

Ed: As for a command to switch out of pistols - I'm not aware of one natively, although I'm sure it could be scripted. A trick, if they are playable units is to team swtich into them and manually change them back to primary or have them drop their pistol. But that's not really a reasonable workaround.

Ed2: Removed some unnecessary rudeness.

Please use search function before posting. We already have quite a discussion going under this ticket: http://feedback.arma3.com/view.php?id=3480.

I really don't understand people downvoting this request. If you want to keep using your movement keys (WASD) to adjust your stances that's fine, but why downvote others who'd maybe like to to do things a bit differently? The ARMA ethos has always been about customizability and player choice. On top of everything, this would in no way hinder, handicap or lessen the experiences of the people who like the controls as they are now, so there is absolutely zero need for controversy. I'm extremely tempted to flame some of the blatant ignorance and unwarranted umbrage already on display here, but there's no reason for something that should be so straightforward and self-evident to turn ugly.

+2

I find having it as a toggle is very akward for two reasons. First, if you're not ADSing but have Long Range Optics toggled, then you will need two control inputs in order to bring the CQB sights up. This may not seem like a big deal, but in a close quarters every split second counts. Second, it's very easy in the stress and confusion of a firefight to lose track of which optics mode you're in when not ADSing. So, again, when you need the CQB sights you'll often bring up the long range scope by accident which is terribly disorientating and often fatal. As per the suggestion, please allow players to bind long range optics and CQB sights to two separate keys like in A2:OA rather than only allowing for a toggle.

"...perhaps vegetation occlusion of AI vision should have its own ticket."

Agreed.

Although I voted this up because this is an issue that BIS should be paying close attention to - as I'm sure they are - I feel that the real problem here is that AI accuracy and spotting times are not situationally dependent enough. So, for instance, AI using powerful optics (such as thermals) and on overwatch should have very quick spot times and excellent accuracy (similarly to what they have ATM), while AI units caught in a sudden crossfire from a flank whilst already engaged in a firefight should be relatively slow and confused in their responnse with the accuracy of their return fire likewise being a lot more limited.

That being said, one very important factor to keep in mind is that from a mission scripting and addon modding perspective it is infintely easier to handicap or otherwise restrict the AI's abilities than to work the other way around. Therefore, IMO, BIS should definitely err on the side of an overly lethal AI; even at present the A3 AI is signifcantly improved from A2. Things are clearly moving in the right direction.

Technically, this is a long standing feature in ARMA rather than a bug. Doesn't bother me too much, but that's probably because I've grown used to it over the years. Nevertheles, it's only logical that if the player's avatar is clever enough to lower his weapon automatically when viewing the map then he should also raise it automatically when exiting the view. Upvoting.

I recall reading an interview in which BIS said they were aware of this problem, but that it would be too costly in terms of computing power to calculate all the extra collisions for smoke and lights within towns. I agree it does look stupid, but it's something we're most probably going to have to live with for the next few years at lesat. Still, no harm in letting BIS know that players consider it an important issue that should be addressed in the future.

Yup! Seems to be an animation clipping issue. Please also see: http://feedback.arma3.com/view.php?id=3305 ; http://feedback.arma3.com/view.php?id=3171 ; http://feedback.arma3.com/view.php?id=2201. Really needs to be fixed.

Edit: for clarity and addition of related examples.

Also see: http://feedback.arma3.com/view.php?id=3325. While using FAks: http://feedback.arma3.com/view.php?id=2201. While throwing grenades: http://feedback.arma3.com/view.php?id=3171.

Personally, I agree that the tactical crouch needs to be slowed down a little, or, as Helari suggested, it needs to be significantly more tiring than tactical standing pace. I like the latter idea better.

Here's a number of other animation clipping issues which similarly to the grenade throws through walls allow movement through walls: http://feedback.arma3.com/view.php?id=3325 ; http://feedback.arma3.com/view.php?id=3305 ; http://feedback.arma3.com/view.php?id=2201.

Yeah, that might work, but I'm thinking the best and most straightforward solution would be to perform a collision check or two before the grenade throw. Either way, I don't imagine it being a difficult problem to solve for BIS provided they are made aware of the issue.

Yep, I've had this problem myself as well as seen others experience it. Very hard to replicate, however. Seems to be related to hitting some kind of combination of movement key presses whilst running.

Pilots' NVGs in raised/stowed position clip through the windscreen of the Littlebird variants (M/AH-9).

Edit: Saw it in a Youtube vid (http://www.youtube.com/watch?v=dAonHz8xTao#t=33.6s) but cannot replicate.

Yes, "touch of bombs" needs to be at the bottom of action menus.

An excellent idea that was also suggested on the BIS forums yesterday: http://forums.bistudio.com/showthread.php?148836-Suggestions-for-Streamlining-Fixing-Stance-Adjustment-amp-Movement-Speed-Controls. I think it would be awesome to use scroll wheel+modifier keys to cycle through things such as movement speeds, stances and action menus. I also don't understand who could possibly be against this proposal considering it's in no way suggesting to take away or otherwise tamper with currently available control schemes; this is simply a request to add extra, optional functionality to the key bindings. How could that possibly be a bad thing?

@Ligthert: Check whether a position returned by your randomizing script is occupied by any objects before spawning your unit. The findEmptyPosition command (http://community.bistudio.com/wiki/findEmptyPosition) might also be useful. Keep in mind, these suggestions are just a stop-gap - this is a serious bug and does need to be fixed.

Confirmed. Also see: http://feedback.arma3.com/view.php?id=5135.

This is a must-have feature! Balancing is not an issue in a simulator; make all the things and let the mission designers worry about the balance.

Anemia, it appears to me that this ticket and the one you linked are discussing two separate issues.

Yeah, seems like many of the "secondary" animations have clipping issues ATM. Basically, it appears that no collision checks are performed before playing a number of animations, so you can step over into objects, peek through walls using step over, throw grenades through walls, use FAKs to warp/teleport through walls or into objects (as you discoverred here).

Also, I agree that the ability to heal from prone would be a nice addition and doesn't seem unrealistic - the character could roll onto his back in order to patch himself, for instance.

Ed: Trying to collate a few of these related issues: See http://feedback.arma3.com/view.php?id=3325 ; http://feedback.arma3.com/view.php?id=3305 ; http://feedback.arma3.com/view.php?id=3171.

Not sure about joystick, but support for mouse buttons and scroll wheel in combination with modifier keys has been assigned so we can expect to see it sometime soon'ish. See here: http://feedback.arma3.com/view.php?id=96.

"I wouldn't call it perfect. But lack of shadowing and saturation is exacly what one expects when overcast."

No. Turn off the computer and go outside; there's plenty of shadow during overcast.

"That's exactly what the world looks like without the added light and the blue and yellow colors from the clear sky and sun."

Another basement dweller.

Also, who was saying anything about saturation? People need to stop using words they don't understand and downvoting topics out of ignornace.

Actually, Joris-Jan van't Land posted on the BI forums a couple of weeks back that they will PROBABLY implement the TOH flight model, but that he's not guaranteeing anything. So, please don't downvote this or other heli physics issues. Also, would love to see http://en.wikipedia.org/wiki/Vortex_ring_state implemented.

Instead of the current system of toggles, how about simply allowing players to map any of the movement speeds to individual, separate key binds? Or, better yet, introduce 'speed up' and 'slow down' controls that would allow players to transition through the four speed states in a step fashion (SPRINT <> RUN <> TACTICAL <> WALK). Finally, allow for these controls to be mapped to mouse buttons or scroll wheel. Along with other movement scheme problems, wouldn't it solve this one as well?

Actually, going limp and crumpling into a lifeless heap is precisely what a body does when a human is shot and killed by small arms fire. The A3 ragdolls are particularly realistic in this regard.

Also see http://feedback.arma3.com/view.php?id=492 [^] and http://feedback.arma3.com/view.php?id=351. [^]

Yep, agree wholeheartedly with this suggestion. As it is now, I feel the urban prone is of very limited functionality which is quite unfortunate. Also, the ability to make small but precise adjustments to one's position while in the low prone by snaking or wriggling around slowly would also greatly enhance it's usability.

How about press (G) to pull out grenade, press reload (R) to pull pin, press (G) again to throw? Until the pin is pulled there should be an easy option to interrupt the grenade procedure and bring the firearm back up (CTRLx2). I don't know about cooking; I was under the impression that's a no-no in the real world. Also, for gameplay purposes, the character should be able to move at walking pace - or maybe even faster? - while going through the grenade animations. Any thoughts from those with RL experience?

@SuperJam: Yes, shifting gears is probably taking things too far, but I didn't make the suggestion simply to increase complexity or because I demand realism for realism's sake. My thinking was that with manual or semi-auto shifting the driver would have even better control over the vehicle's speed and acceleration, especially when off-roading in steep terrain - after all, 2/3 throttle produces an entirely different effect in 1st gear versus 3th, for instance. But, yeah, the thought of rowing through the gears like a madman while hurtling down a mountain road on Stratis does bring a smile to my face, so who am I kidding? ;)

I was just going to post pretty much the same request regarding the land vehicles: the current slow/med/fast forward and back controls are quite cumbersome and annoying. The suggestion in this ticket would be a great deal more intuitive as it more closely represents the control scheme found in real cars.

Keys bindings should be for BRAKE and three (or more) THROTTLE positions with another key for changing GEAR from forward to reverse (assuming an automatic transmission). It would be even better if we could map throttle, brake and steering to analog axes for even finer control. Gears might also be cool and would make the driving both more realistic and easier at the same time. May I suggest a sequential semi-automatic gearbox with one key for SHIFT UP and another for SHIFT DOWN (manual clutch not necessary).

No, it's not a brainfart. Searched high and low in-game going through both the Control Menus and the Field Manual, but couldn't find the answer to this question either (N is for "Night Vision"). As it stands, this is either not documented anywhere within the game or very well hidden somewhere. Needs to be fixed. Also, note the usual know-it-all mouth breathers downvoting legitimate issues.

Confirmed. Only occurs when ADS'ing.

The sun is much improved over A2. I'll agree that it could be more blinding when looking directly into it, but the overall effect is very good and a major obstruction to player vision - see the freakin' infantry showcase, for example. Now, the real question is whether the AI spotting and aim is affected by the sun position in any way, because so far it doesn't seem so.

Yeah, step-over seems to have a lot of clipping issues in general ATM. Step over onto an object - such as a rock - and you'll more often than not clip into it and get stuck until you step over out of it again.