This is a duplicate of an existing ticket - #369. Closing.

Confirmed in stable 1.36.128579.

Attached a picture (<i>bouncy.jpg</i>) which displays the bullet trajectory. In addition to what seems like way too many ricochets to me, the bullets will sometimes ricochet under some extreme angles as well (<i>180.jpg</i>).

In development 1.37.128722 the problem is also present but much less so. Mainly it looks like the extreme angle ricochets are actually not present so it is more difficult to get a "good" bounce sequence going.

Please first update the repro with a list of a hangars that suffers from the issue (or at least an example of one such hangar).

If that is the case I apologize for misunderstanding but please provide some better testing guidelines, mainly the positions of those bugged hangars.

Why can't you just spawn the aircraft rotated by 180 degrees (<i>jet setDir ((getDir hangar) - 180)</i>)?

No, I am not joking. I told you how you can dynamically spawn an aircraft so it faces the correct way.

If the environment team took 5 minutes to turn the hangars by 180 degrees then all of the hangars will be facing <i>away</i> from the runway and the jets will keep spawning facing the wall. You would also have to rotate the model itself and at the end of the day all of the scripts that took the 5 seconds to accommodate for the current state would end up broken.

This is a duplicate of an existing issue: #8592. Closing.

No problem, resolved.

Closing - duplicate of #0021410.

Closing as a duplicate of #15911.

Closing as duplicate of #5241.

Closing as requested.

I don't think this is needed. Here is a better readable version of what you posted.

<pre>
thing setVariable ["TAG_myAction", thing addAction ["Stuff", "stuff.sqf"]];
// ...
thing removeAction (thing getVariable ["TAG_myAction", -1]);
</pre>

Please provide the error code and offending file displayed on the BSOD.

As the_Demongod says above, you cannot see with thermal sight through glass in real life either. Closing as no bug.

Closing as duplicate.

As AD2001 said, please use the forums to ask question. The feedback tracker is not the right place to ask questions.

I'll close the ticket.

Closing as no bug.

<i>I still would put this as user error and move to close this post :)</i>

I disagree. If there is a conflict it should be clearly indicated.

I'm sorry, I don't understand what you're talking about?

I am not sure what to make of this. If this is meant to be a serious bug report please create a new ticket with a description of what the issue actually is.

Disregarding and closing!

I'm sorry but Bohemia Interactive is not associated with Altis Life so the Feedback Tracker cannot be of help to you.

Please contact the admin of the server you were playing on.

Closing ticket.

Obvious spam is obvious. Making private to hide the link.

Done, #18595 closed.

Closing as requested.

It looks to me like the gun's muzzle flash counts towards the limit of dynamic lights and for whatever reason the street lamp is dropped as a result.

Confirmed in 1.15.116121.

Confirmed in 1.11.115723.

<b>AmovPpneMstpSrasWpstDnon_AmovPercMstpSrasWpstDnon</b> is too slow. Same with <b>AmovPpneMstpSrasWpstDnon_AmovPknlMstpSrasWpstDnon</b> (pistol prone -> pistol kneel).

I'd propose making them twice as fast.

This is a duplicate of #17337, closing.

Confirmed in 1.11.115723.

It keeps forcing you into the bottom swim animations.

You cannot address parent directories, hence the crash. As such, this is a duplicate of #9629 and I will close it.

Duplicate of #2325, closing.

Confirmed, ESDF user myself.

As others have said, this is not a bug. It's physically impossible to operate certain sights while wearing NVG.

If you believe there are scopes where it should also not be possible to use NVG but it is, please create a new ticket for it.

I'll close this one.

This is a duplicate of an existing ticket: #2510.

I'll close this one.

Confirmed in 1.11.115429.

This is caused by <b>AmovPercMstpSlowWrflDnon</b>'s <b>connectTo</b> which adds an edge leading to <b>Acts_TreatingWounded_in</b> with a really low cost of 0.001.

Whoops, turns out this is a duplicate of #14775. I'll close this one.

I guess it's rather obvious why I'm closing this. Tickets like this just waste everyone's time.

Don't forget everyone can assist in keeping the tracker clean. If you find a duplicate ticket please add a comment saying so.

Closing as duplicate of #0001819.

#0017229 is newer but it has more activity so I'll close this one as a duplicate.

Duplicate of #799, closing.

Thanks Koala, closing as duplicate of #0002927.

Bullets traveling at the speed of a butterfly won't do much damage, I don't see a problem here.

AI can pick up the bag, the problem is as soon as the AAF shows up (very soon) the AI enters danger mode which results in them (very slowly) advancing from cover to cover. This would be one case where the ability to set AI to careless would be handy.

Closing, duplicate of #3537.

<b>getArray</b> doesn't do any parsing, it just returns the array value that is held in memory since the game start, which is when the entire config will have been parsed.

<i>Why can't parseArray just remove "" and treat the content as if I typed array? I am not 100% on how SQF gets converted into C++, but would this "[]" to [] conversion be possible before SQF becomes C++ code?</i>

Well it essentially does that. The reason the former is much faster is because it was <i>already</i> compiled alongside the rest of the script. If you were to measure the time it takes for the <b>whole</b> script to call compile preprocessFile you'd notice little difference.

SQF never becomes C++ code, it just gets broken down to instructions that are interpreted by the engine (which just happens to be written in C++).

<i>although parseNumber is slightly slower than 1st example it is much faster than call compile workaround.</i>

When you use <b>parseNumber</b> it already knows the input string (should) contain a number so it just (presumably) calls atof to get the numeric value.

With <b>compile</b> the script interpreter has no idea what it could find in the string so it has to interpret it.

<i>parseArray is expected to be a much faster dedicated command.</i>

I don't see how that could be possible. parseNumber probably just calls atof, this proposed command will have to understand SQF grammar to correctly interpret the contained data types.

No worries, I'll close the ticket as no bug.

I'm sorry but you didn't actually say what the issue is?

Thank you for updating the description.

It sounds like you have toggled on free look. It's a feature that allows you to look around without having to change the direction of your movement. The default key to toggle it on/off is <b>2x Left Alt</b> or <b>Numpad *</b>.

Try turning it on using the aforementioned key and see if this is what you've encountered.

In 1.19.124337 I am no longer able to see the buildings underground. The issue with huge FPS drop remains (61 => 27).

I am not sure if it were every different but <b>U_B_CombatUniform_mcam</b> and <b>U_B_CombatUniform_mcam_worn</b> look identical - they both use uniformClass <b>B_Soldier_F</b>.

The effects are purely audiovisual in 1.09.113293.

The same problem was present in A2.

I am sorry, general feedback like this should be posted on <a href="http://forums.bistudio.com/forum.php">the forums</a> instead or split into individual tickets.

Closing invalid ticket. If you wish to return the game please contact whoever sold it to you.

There is no need to shout, edited title.

Given they fire caseless ammunition the lack of cases is correct. Closing.

<i>just do "dll" callExtension (str ["hey",3,2.5,["hey2",123]]);
dll could parse that on its own.</i>

Yes, but at this point you're essentially writing your own SQF parser.

<i>1. Switch STRING type of data to ARRAY to be sent to and from extension.</i>

That wouldn't be of much use. A better solution would be to allow the command to accept:

• string
• number
• bool
• array (containing any of the above)

The DLL would receive the supplied data type as an array of bytes containing the serialized data type, size of this array and the data type identifier. We'd return the favor for the output.

The function signature would then be:
void __stdcall RVExtension(char *output, int outputSize, int outputType, const char *function, const int functionSize, const int functionType)

Of course, we'd then require documentation about how the RV data types work so we can deserialize/serialize them.

Good point, we can just have the command return and take an array. Still, that's not going to make much difference in the difficulty of implementation.

You can do this using <b>steamcmd</b>.

Indeed, closing.

I'm unable to reproduce this in 1.19.124294, I assume this must have been fixed. Resolving.

I'm sorry, all submitted tickets must be in English.

Closing.

There is no bug.

Please provide a full example of your script where we can actually see what <i>_item</i> is.

There is no bug here. Please use the forums for scripting discussion.

Closing as duplicate of #0002927.

Please post feedback of this nature on the forums, preferably in this thread: http://forums.bistudio.com/showthread.php?147351-Arma-3-Feedback-Tracker

Reproduced in 1.31.127362.

There is a fault in the sound file (A3\sounds_f\ambient\rain\rain_new_1) - at 15.665s there is some kind of a click.

I've heard my share of rain and this does not sound like a raindrop hitting a puddle of water. I'm sure it is the sound of a raindrop hitting something but whatever it is it just does not work on a 1 minute looped sample.

Closing, don't duplicate tickets.

Is there any other issue with 5.56x45mm penetration or is it just this particular shack? If the latter is the case this one's a duplicate of #5164.

Please read the how to guide and provide the required information about your PC and a more detailed repro.

Closing thanks to being a duplicate.

I have no idea what you're on about. You're welcome to create a new ticket as long as it actually describes the problem rather than just being a rant.

Confirmed in 1.09.113293.

I noticed the same thing in A2, arrays are sent as serialized data structures.

Please note what the documentation for the <i>in</i> command says:
"Checks whether x is equal to any element in the array. If x is a string, the array is checked case-sensitive"

I am note sure what the second example is supposed to demonstrate. That condition will be true only when you are not performing any of the checked medic anims.

Resolving the issue.

Duplicate, closing.

Changes from dev branch will eventually be ported to stable. Since this is a duplicate of #13989 I'm going to close this.

Duplicate, closing.

Confirmed in 1.11.115429.

This is caused by <b>AmovPercMstpSlowWrflDnon</b>'s <b>connectTo</b> which adds an edge leading to <b>Acts_TreatingWounded_in</b> with a really low cost of 0.001.

This is a duplicate of #1819.

I've updated the ticket title. Please make sure to use descriptive titles in the future.

Duplicate of #369, closing.

Ricochets are already simulated, try shooting at the ground at night with some tracer ammo.

No change required, closing.

This is actually a duplicate of #2125. I'm closing this, please post your video there, thanks!

This doesn't sound like a bug. Both getPosASL and eyePos return PositionASL, drawLine3D expects PositionATL. If you feed it PositionASL you get your Z offset by the sea level. Use ASLtoATL to convert the positions.

Try deleting the Arma 3 directory in your documents, it should be re-created the next time you start the game.

Confirmed.

Done.

This is by design. It is <i>St<b><u>r</u></b>eam friendly</i>, not <i>Steam friendly</i>, perhaps you misread the label?