I agree, some spawning protection, like handling the damage from collisions for the first few seconds would probably solve this issue.

Currently even the smallest bump or slightly rougher landing will make the darter go out of commission.

The thing appears to be made of plastic and the rotors appear shielded, I reckon it could handle some bumps and nudges without being wrecked.

This is exactly what AD2001 is saying, I just tried it. You can throw a second grenade about a second before the first explodes.

The height matters not because the grenades don't detonate on impact but on a set timer so throwing it from the ground, a tower or a space station, it's always going to detonate after a set amount of time after they leave your hand since they are not cookable.

As Killzone_Kid says, this is working as intended. You need to return the amount of damage you want to apply, otherwise no damage will be applied.

I've added a very simple sample mission that shows how a camera that maintains the position behind the plane affects the feeling of flight in third person.

Of course, this type of camera option, if implemented could and should be improved with smaller amount of movement in regards to the g-force and other such effects.

This has been "fixed" but now the player is unable to affect the control surfaces while the engine is off.

Regressions introduced in 116538 have been fixed in 123647, making this completely resolved.

Anyway, BIS would have to move the player's vehicle from the virtual foreground into the background in order to solve this issue, which could cause a couple of new issues (mostly visual, like clipping of grass through the vehicle floor).

Wouldn't a much simpler solution, if possible, be to consider units "attachTo"-ed to the vehicle in the "foreground" for the purposes of first-person rendering?

It would still retain the benefits you mentioned, but would solve the issues of attached units being rendered oddly.

Unfortunately this ticket was so vague I didn't manage to find it when I looked for something similar a week ago (#15334). :(

I'll close this one as a duplicate of #15334 as it got assigned already.

I'll label this as reviewed, but can you please add some examples of usage, examples of output/effect and use cases for such commands to the ticket (Like in #12101 and #11199) so it's clearer for the devs.

I adjust slightly , and the rudder swings the nose back the opposite direction.

Even in current beta?

This isn't happening for me, I've tested it in the latest dev branch and aiming is much better.

I can confirm that autorudder has been removed from "Airplane".

If there is nothing more to add hladas, I think we can close this? :)

is removed in current beta, waiting for feedback ;)

It works great with the Buzzard, the airplane feels much better to fly.

Is this dependent on the "AirplaneX" simulation?

It seems to be only changed for that type simulation, would it be possible to remove it from "Airplane" simulation too? Community addons that use that type of simulation still seem to have autorudder enabled.

I've merged my ticket with your ticket and added the repro mission and repro steps for it.

I can no longer reproduce this, thanks for the fix. :)

Can't confirm the fix. Still broken in 126027.

http://imgur.com/a/kUpDT

Still broken in 126046.

Also affects the Nightstalker optic.

Upvoted but there shouldn't be unlogical exceptions for FAKs etc. Any object in a rucksack should be treated as Additional Storage.

I believe they should and the reasons for it are in the description. Either way, I'd rather see it work like I lined it out, then with testing, we can figure out should more things be restricted or not.

In the build 113293, you cannot reload any magazines from the backpack, so this is my wishful thinking that it might mean that BI is thinking about it/experimenting with it. But it's probably just a bug that sneaked in somehow.

Thanks for the confirmation. :)

Can you provide more information and more accurate repro steps?

I cannot reproduce this only with crouching and slopes.

This currently seems like a duplicate of #12437, which seems to better explain the problem.

Insulting people and guilt tripping "vote so and so or you're a noob" is not how feedback, bug reports or feature requests should be made.

Either way, this change is way too specific for a feature that can be forced by server admins and mission makers.

Please leave the vitriol, insults out of your future tickets.

Dragging of soldiers currently isn't an Arma 3 feature, please steer your feedback towards the addon maker or mission maker that made that feature.

Confirmed

It doesn't even need to be this complicated to include new control mechanisms and whatnot. It can work within the existing system.

The simplest way to add this would be to make the driver interior LOD pitch black with viewports like you demonstrated. You'd then just use the freelook key to look around the three viewports and you could even partially look through each one.

Like so: http://i.imgur.com/X2PAASO.png

Sorry, don't know the exact version, I just noticed it last night on the dev build. I reverted to the current Steam stable version of Arma 3 which is 0.74.109135 and it's present there as well.

I just tested Arma 2 OA 1.62.95248 and it's present there as well, but it's not as bad as it is in Arma 3. In Arma 2 the vector gets reset to the proper vector as soon as even the smallest rotation or mouse movement happens so it's not as bad/noticeable as in Arma 3.

I'm unable to reproduce this, I see both debug messages, how are you executing the script?

It can't be closed yet, it's been resolved for the AH-99, not all the vehicles specified.

While this has been altered to include the "ASIS" parameter in one of the recent updates, the check itself in the "Combat" version is not necessary due to the reasons mentioned in the ticket.

Please test these issues in the Dev builds and report back. Stable is already outdated and behind the Dev even with the recent update.

I can confirm that it was present in earlier builds.

I can no longer reproduce it as of todays DEV build, please confirm.

My suggestion would be "<unit> disableInventorySlotChange <array of slots>"

So you could do:

player disableInventorySlotChange ["ALL"] - Prevent changing of any slot
player disableInventorySlotChange ["CONTAINERS"] - Prevent changing of containers (uniform, backpack, vest)
player disableInventorySlotChange ["WEAPONS"] - Prevent changing of weapons
player disableInventorySlotChange ["PRIMARY_WEAPON"] - Prevent changing of primary weapon
player disableInventorySlotChange ["UNIFORM"] - Prevent changing of uniform only
player disableInventorySlotChange ["BACKPACK"] - Prevent changing of backpack only
player disableInventorySlotChange ["UNIFORM", "VEST"] - Prevent changing of uniform and vest only

etc.

ofcourse, this would need an "<unit> enableInventorySlotChange <array of slots>" so you can reenable it when necessary.

This way, you could disable everything or just some specific slots, depending on your mission requirements.

Adjusted it some more and reviewed. :)

I believe I can, it has a sound and it's not "broken".

The ticket and you argue that the sound is not there, it is there. I hear it fine sitting in a noisy room with my in-game volume at 50% and headset at around 50% as well, but I agree that the old one is better and more noticeable.

Adjust your ticket to reflect that you'd like the sound to be reverted/changed to something better/louder and I'll review it. I'd rather not review it like this and have it closed later by someone else with a reason: "the sound is there".

That click when I click the button is not the click I'm talking about.

Listen to the clicks after closing the pause menu to the end of the video. It shows a new hint and "clicks" every 0.5 seconds, as you can see by the script executed in the debug console.

And I still hear the sound even with your code.

It produces a sound, but not the same sound as in the video. I had the same sound from your video before (as you can hear here http://www.youtube.com/watch?v=BUM7cAFbqlo).
Here is a video I just recorded with the new sound: http://www.youtube.com/watch?v=dxP1bPsM_qQ

I wouldn't call it broken, just changed. :)

I'm unable to reproduce this, when hinting I hear a "click" sound.

Please try it again.

Added in build 114929.

I'm not "so against it", I'm just trying to explain what neokika meant when he said that you can use CfgFunctions instead.

I'll leave it at that as I don't want to cause more friction in regards to this.

Addon config functions are available in uiNamespace and missionNamespace as usual. You can call them from parsingNamespace by doing <arguments call (uiNamespace getVariable "functionName");>

Mission functions are available to uiNamespace and parsingNamespace by doing <arguments call (missionNamespace getVariable "functionName");>

As for your preference towards a single file loaded with functions, well that's your thing. :)

He's wondering why you aren't using CfgFunctions to create rewrite protected functions such as that instead of manually compiling them at runtime.

Functions defined in CfgFunctions are compileFinal'd by default and bring plenty of other benefits.

Here is a better link that describes CfgFunctions better than I can: http://community.bistudio.com/wiki/Functions_Library_(Arma_3)

Interesting sections are "Adding a function" in regards to the benefits and "Recompiling". But I suggest reading it all, Karel has recently updated it and it's a very good read.

Yep. A slightly more advanced, laser-less laserTarget. :)

Yep, I stand corrected, just tried it again myself. For some reason GEOM never returned anything where FIRE did when I tested it last time. Unfortunately it doesn't return the geometry components, just some certain selections.

"intersect" (https://community.bistudio.com/wiki/intersect) command already does intersection based on LODs between two points, it returns the named selection on the model which it's intersecting (currently I could only get it to work on the "FIRE" LOD).
In addition to the named selection, it also returns the distance along the line at which it intersects. This allows for a simple calculation of the position at which the intersect point happens because we know the current point in space where the line starts, it's end point and as such we can calculate the vector of the line. Since we were just returned the distance on that line, we can do another quick calculation from the starting point with the previous vector normalized then extended the distance we were given.

Unfortunately "intersect" doesn't work for all LODs and not all named selections will be returned in the given LODs.

As for the clear horizon, I've accounted for that in the ticket, since the skybox is a huge sphere around the player, it should be the last object checked for intersection and if it reaches it, then the coordinates of the intersection with the skybox would be returned so we have a meaningful height. Since this might be overdoing it, returning null would also be ok if horizon is reached.

Currently there are scopes in the game which calculate the precise distance including the geometry calculations and the laser designator has been doing the similar raycast forever now. The same raycast also happens when you command the AI.

• screenToWorld always returns the world position at ground level, therefore it cannot be an accurate representation of the current cursor position
• lineIntersectsWith only returns the object reference
• You can't assume the cursor is in the center of the screen, so some additional code would be required to track the cursor position on the screen
• Combining screenToWorld and lineIntersectsWith would result in a poor man's cursorTarget which is already available in the game instead
• The return value proposed by the command would be actual world coordinates at what the cursor is pointing, as you can see in the screenshots demonstrated
• None of the intersect commands return the world or model coordinates at which the intersection occurs

Confirmed.

Can you show us a video or give a reliable repro for this? There is no way to reproduce this with the steps "Simply existing...".

We had a bit of a chat between the moderators and figured that it wouldn't make sense to make glasses fight for priority. If that were the case, it would force someone to duplicate the classes for the glasses if they didn't think they are crucial. Also, if the config glasses had the priority switch you mention, and some other profile glasses had the same priority switch, there'd be a conflict which might not be satisfactory.

A more sensible config option would be to do something in the unit's config like:

"glassesAreCrucial = true"

Which would by default be false and you could change it for individual units in config.

So for example, this way, if the divers had this, they would, when spawned prioritize config glasses, while Pomigits units and all other units would allow the profile glasses to take over.

Pomigit, if you like what we're suggesting, please alter the ticket so we can review it, but we don't think that the current state of the ticket describes the solution would be beneficial to implement.

I find that it's ok the way it is now, for example this change would make the divers have sunglasses instead of diving goggles by default which I think would be worse.

For a "soft" definition, you could solve this by removing the glasses from the config, then running an init script that would check if the unit already has glasses and if not, give them the ones you want.

There is still no simple way to retrieve these things. :(

Thank you!

Confirmed. Funny thing is you can't collide with the hidden objects on foot, but you'll smack into them if you are in a vehicle.

Confirmed. Also seizure inducing in the thermal view.

Closing in favor of http://feedback.arma3.com/view.php?id=23679 which has been assigned.

I believe this is out of scope of this feedback tracker. Documentation can be already found on http://community.bistudio.com/

Are you aware that you can bind the "Use default action" to, well, use the default action that usually appears as an icon on your interface? This replicates the behavior you're asking for.

Binding it to E yourself will produce the result you want. It's bound to middle mouse buddon by default in the default preset I believe, so there is no need to scroll.

I've demonstrated with doors here: http://www.youtube.com/watch?v=B4UKrw8PUhw

Closing this to remove it from limbo in favor of 10726

What what?

Point 11 and 24, 11 is the front seat and labeled as "Pilot's seat", 24 is the back seat and labeled as "WSO's seat".

While never mentioned, some proof at 2:13 in that video, the guy in the back is writing something down on a piece of paper while the helicopter is turning.

Improved in the latest build but with side effects.

AH-99 glass before: http://i.imgur.com/bC2JygU.jpg
AH-99 glass now: http://i.imgur.com/ZWwKxAG.jpg

Unfortunately, it's still not complete, further anomalies exist:

• Sea now renders over the reflection: http://i.imgur.com/YnIEJyN.jpg
• Stencil shadows do not affect the reflection (http://i.imgur.com/g2VG8Wc.jpg), soft shadows properly remove reflection (http://i.imgur.com/e5bZVA4.jpg). Notice the blade shadow and the hangar shadow in the second image.

Thanks for the confirmation. :)

Todays dev build changelog claims this to be fixed. Please confirm.

I've added a repro mission that's slightly different than your repro but seems to be the same issue. It looks like attached objects get simulated at reduced speed now.

Beat you to it a few minutes ago (#10101). :)

Please include repro steps with your tickets in the future.

Please define what the diesel powerplant factory is. Some repro steps or the ways to locate the building are necessary.

Please do. I'm currently observing that as long as the engine is on, both the driver and the gunner can see the working monitors.

Screenshots appreciated.

Cannot reproduce.

This seems to be working as intended, if the engines aren't on in the SDV, the screens will not work. If you get in as driver, any small mouse movement will turn the engines on. Please confirm that the screens work in the gunner seat when the SDV engines are on.

It would certainly be nice to have. But it's covered by #3828.

Testing this today, the 3rd person camera no longer follows the gun in third person, ever, but is also unable to be pitched up or down.

This issue has been fixed. :)

Confirmed.

No worries. Future versions of those addons might fix the compatibility issue.

I just played "Night" and I can't confirm this.

Are you using any mods? CBA is known for causing the multiple radio transmissions. If you're playing with any mods, can you try playing it without any mods and see if the same happens?

As said 24 DAGR rockets seems like enough AT firepower. It destroys the strongest armor available in the beta with 1 shot.

Confirmed as resolved in todays dev update

I think this is a bug, when you put them on, you get the mount and strap part of the model, but not the goggles themselves.

I can't confirm or agree with that. I just tried it out and it planted me and the AI below the docks (http://i.imgur.com/zfF3GI9.jpg).

The reasoning and cause of this is simple. "Zero height" is either on land the point where ground is, or over water, surface of the water.

If the editor placed units behaved like before when we had no elevation input and had to resort to setPosATL-ing stuff, you'd end up with more confusion than this logical approach.

For example, placing a unit in the editor on a building would result in that unit being on the roof, but the elevation states that height is 0. Now imagine the mess trying to place the units on all kinds of floors in that building.

The way it is now, you can assume that 0 means right on the terrain or on the surface of the water instead of having to figure out what the engine assumes to be 0. It's the same effect as setPosATL-ing the unit to 0 in Arma 2.

The units, when you place them start out with their elevation at "0" meters, which is the ground beneath the dock.

There is a little box in the edit unit menu, where you can set the elevation. If you set it to "3" there, at the position you mention, the unit will be on the dock itself instead of the ground at "0" elevation.

I suppose you weren't aware of the elevation input box?

Either way, we can agree that the solution to that bug is not to make those optics collimating. The video shows that the optic is not collimated, your point that the sight gets misaligned is valid, but the solution isn't.

I agree that it's a bug, but it's because of the idle animation. The inherent weapon sway is not that idle animation (to clear it up for everyone else). It's mostly observed in prone and any slight mouse movement will correct it. We had similar with the crouched animation and ironsights in Arma 2.

That animation itself is what should be fixed.

In case of gameplay features, I do agree that scope shadow would be interesting. Right now we have the sway which doesn't misalign the optics and the way to control it with hold breath. I'd love to see those two interacting in some way. But that's a feature request for a different ticket.

The only reason I like that this happens (but still agree that it's a bug) is because it gives out some randomness and slightly misaligns the sights for scopes that are used for medium range enough that it prolongs firefights.

When in doubt, use marksman and sniper rifles to test.

I did, used the BLUFOR Marksman which is armed with MXM, HAMR and the IR laser by default. Observed the same with the EBR. I fired at the moment the maximum misalignment happened. Firing while they are aligned wouldn't exactly be testing the issue. :) Even with the SOS which is still 2D as the old scopes at 400 meters some random dispersion happens which is relevant as it contributes to the feel of the misalignment if you expect every round to hit at the same place.

Can we agree to alter the ticket to reflect that the problem is the idle animation in prone and crouched (I can't observe this while standing) in this case and not the scope itself and that the solution would be to correct the idle animation?

As for the assigned, apparently "Feedback" status assigns it to whoever set it to that when the author of the ticket replies.

Ok, I did some testing.

The weapon sway itself doesn't cause this, it indeed seems to be some kind of a camera misalignment due to head moving in some idle animation.

First is the fact that this happens with real weapons, the scope at 400 meters will not always, with undeniable certainty point at the exact point the bullet will hit if your eye isn't aligned properly with the scope.

Then there's the dispersion factor added to the weapons which gives bullets some leeway on where they actually hit.

Testing at 400 meters which the scope is zeroed at the laser did exhibit minor misalignment as in your pictures. But it affected my shot in no way.

First shot the reticule was dead center of the target, the laser went to the right edge of the target and the bullet hit very slightly to the left
Second shot the reticule was dead center of the target, the laser went to the right edge of the target and the bullet hit very slightly to the right and down
Third shot the reticule was offset to the left quarter of the way, the laser was aimed dead center, I hit the target slightly below the reticule
Fourth shot the reticule was offset to the left quarter of the way, the laser was aimed dead center I missed the target

I aimed with the collimator on top of the HAMR and some dispersion happened there as well.

Another issue with this is that the sights can appear misaligned if the laser doesn't end in the same distance as the sight. Demonstration in the pictures below.

http://i.imgur.com/0RVWyWt.jpg
http://i.imgur.com/0pyYCX7.jpg

My conclusion is the following. Laser vs reticule is not a proper way to conclude that the reticule is wrong, the proposal to fix this by making the reticule collimating would be the wrong way to solve this and would be even worse for gameplay due to the ability to use zoomed non-collimating scopes as collimators. The misalignment is a real life property as well. This also happens with the collimators but due to their lack of zoom is less apparent. Additionally since this happens with non collimating sights in real life, I find this beneficial to the gameplay. The reticule was accurate enough at the advertised zeroing range shooting at a man sized target.

Working as intended if you ask me. This is how the real life non-collimating scopes work.

Take a look at this video from 2:19 to see the same effect http://www.youtube.com/watch?v=ERVjdWurpiU

Confirmed.

It's in the Alpha as well, what's missing is the module for it.

You can open it by typing the above in a trigger then activating it, it will work fine and won't crash the game if done in such a way.