Sigh, I'm getting old. Already reported it, although it did not show up when searching.

Note: This bug also affects accessing character inventories and ammo boxes (which technically are vehicles, anyway)

I think the fuzzy effect indicates that you are injured. You need to eat enough so your health starts regenerating.

The actual bug is not the fuzzyness, but the fact that you can clear it by going into the graphics settings

Have the same problem. A blood transfusion returns some blood (and hence color), but apart from that, no regeneration even after eating half a day

Same issue here, looks like every second frame is rendered a bit offset to the previous one, resulting in a really nauseating jittering

Still valid. Init event handler is not called for non-player units

I think, as long as we have to edit the loadout of every single unit with the Initialisation box

By all means, that is of course a much more important functionality, and as far as I understood it, it will be in.

If you ever worked with the Neverwinter Nights toolset, it had a similar problem: when the fog and ambient lighting were enabled, you couldn't see much since things you placed beyond the fog range were simply invisible, and maybe the whole area was too dark. You could switch both fog and ambient lighting off with icons in the toolbar, for a much clearer view.

With a possibility to switch off the current weather and daytime in favor of a clear visibility condition.

Compare those two shots:
http://images.akamai.steamusercontent.com/ugc/616222083852222353/91F9C23D7339E9A9FFFFA290688A37CDB5173B99/
http://images.akamai.steamusercontent.com/ugc/616222083852222536/B6652200F99DC8BA3CC9340FAE585EF4C42793E7/

Spot the difference. Assuming you are doing a mission with the lighting conditions of the first shot, you will be thankful for a switch to something where you can actually see something at all.

Every time you test you need to establish the final weather conditions for your mission, since the AI is heavily influenced by the weather and daytime. Now assume you would have to make those changes every time you want to test and edit.

The new editors main focus is usability, and this very easy to implement feature would make it more usable.

Maybe it IS opinions, but I see a great potential in such a functionality.

Whoa, there's some proposals... so instead of implementing a functionality that takes less lines of code than the "creative proposals" you have for solving the issue, you expect people to "change the weather settings a couple of times in between to check" or "make screenshots" ?

Just because you don't see a direct use for this kind of functionality doesn't mean it's not necessary. I for example like to give some thoughts to the weather settings and daytime I use for my missions, so I spent quite some time tuning it.

Again, this is functionality that can be implemented with very little code, will immediately benefit everyone and does not require users to fiddle around with nonsense like screenshots.

Sometimes, I don't get you guys.

It was mentioned in the chat during the stream that this is going to come in

I had similar issues when AI in the editor suddenly started talking

Done

For the record latest Dev build exhibits the exact same problem. Note again, must be dedicated server

Please see attached example:

A dedicated server outputs:
"Starting test"
"paramsArray has scalar entries and value any"
"paramsArray is of type "

while a self-hosted server outputs:
"Starting test"
"paramsArray has 4 entries and value [1,25,0,1]"
"paramsArray is of type ARRAY"

To reproduce: Start a dedicated server with the supplied mission, launch it by slotting in and clicking ok, and then examine the server's RPT file

Actually found a way to make it work, by NOT using the predefined CopilotTurret. While this is still a bug of sorts, this means that this ticket can now be closed.

@Koala
Yes, the problem appears with non-official content, but the problem itself is in the engine, not the content. The Plane_Base_f base class DOES define the copilot turret, hence I am assuming that it was put there specifically for custom made content to make use of it (since, as you said yourself, there is no copiloted plane in Arma 3's vanilla content)

I am the author of the mod in question (CUP). I've ported the C-130 from Arma 2 to Arma 3 and it exhibits the problem. I also saw it in other Arma 2 ports like the one I quoted on the original bug.

I understand that the developers can't do anything about the problem in the mod, but I was hoping that this issue could be addressed on the engine side, since I _suspect_ (without having knowledge of the engine, of course) that the problem is rather minor and most likely easily fixed.

Uhm, not wanting to sound rude, but can't you at least leave the issue as open and unresolved ?

Confirmed it's still a problem in 1.52

The problem seems to be random. I'll try to see if there is a pattern, but up to now I haven't seen one.

Might be related to #0020746

Yes, it also happened on the Speedboat Minigun

Confirmed, works now. Thanks!

This has been fixed in the latest Tools beta

This bug should have a severity of critical, because it basically makes every mission with UAVs unplayable if it also involves a vehicle or a static weapon.

If necessary, I can provide the addon files that produced the problem

I was able to find out that the problem apparently was caused by a duplicate shadow volume 2. Seems that Binarize has problems with certain or too many shadow volumes.

I've reported two bugs (#15730, #9184) that also tie in to this bug, so I suggest setting them to be related

This is likely caused by the way UnitPlay is implemented. See Ticket #15919.

Basically, UnitPlay uses a hidden control that provides the timing. This means that any new dialog (like splendid camera) will kill it.

Same problem here.

Interesting sidenote: Start local server with no missions subscribed, then open the workshop, subscribe a mission, and you will see them pop up.

Restart the game in this state, and again crash

Whatever

Not necessary anymore

Yes, I mean that, mixed up the two. See, I changed the ticket to prevent any further heart attacks to you.

And I am well aware that the command does not work in multiplayer. You might want to re-read the ticket, because I said "or disabling simulation". Zeus works in single player too, by the way.

But never mind, I found a way around this anyway, so this ticket has become moot.

Note: This bug report is still valid

You should be more explicit in the feature requests, and give examples

It's the Arma 3 feedback tracker, so excuse me if I assume that people would know that it's related to Arma3 and now DayZ.

I'm sorry, the title alone says it all. I can not understand what I should make more explicit.

And honestly, what's with the downvoting ? Would one of you downvoters be so kind an actually say WHY you vote it down ?

Sigh....

KevsnoTrev, micovery

Did you actually bother to read what I wrote ?

micovery: The dev build now contains "DayZ" items, i.e. items taken from DayZ that are basically placeable objects. This feature request has absolutely NOTHING to do with DayZ, that's why I put the "DayZ" items in quotes, basically because the items have been announced as items taken from DayZ.

KevsnoTrev: Yes, I know that they are in the SITREP states that they are in the dev branch, and they are in the dev branch, just as CfgVehicle classes, i.e. static objects that can be placed. The feature request asks for them to be available as CfgWeapon classes so they can be used as items in your inventory.

And honestly, I don't know why the heck people vote these features down ?

They aren't, it's only vehicle classes that can be placed in the world, not items that you can have in your inventory

Koala, you misunderstand the point of this feature request.

I'm quite happy that it is possible to remove any trace of the "magic player position indicator" on the map (see my other bugs #15266 and the now closed #5568, reported by myself).

The point is: In Arma 2, you could actually see the GPS (the device) on the map screen (along with radio, watch, and compass). It would not show the map, but it would show the coordinates.

In Arma 3, the GPS is not visible. To actually know your coordinates, you have to switch back to main view, open the GPS with CTRL+M, read the coordinates, and then switch back to map and determine your position.

What I would like to see is the GPS, showing the coordinates (not your exact position) to be visible on the map screen.

This is somewhat related to bug #8485, but this report really just calls for the basic GPS, not additional tools.

It's fixed

Just a heads up, this has NOT been fixed yet

I *think* this was related to the paraglide crash that was fixed in Build 10747. The mission I was testing with previously started with paragliding. I could no longer reproduce the problem with another mission (no paragliding), so I would say the issue IS actually fixed.

Note: Definitely fixed

Not solved, bug is still present

:D True