Should be already fixed in dev branch and it should be a part of the next update (1.26) for stable branch.

Flying in a straight line doesn't seem as a good way. UAV could ended up in an enemy territory or very far from player and out of the map. Both these situations can cause complications to player and we have decided that UAV should stay circling, not flying in a straight line.

When I checked behaviour of a fixed-wing in the game, it seemed that it did exactly what it is supposed to do. I didn't observe any flying back to its spawn point. Are you still able to reproduce this issue? Thanks

No reaction for a long time. Marking as resolved.

Thanks for feedback. This issue should be already fixed in dev branch and this fix should be a part of next stable branch update.

Should be fixed in the next dev branch update.

Thanks! This fix should be a part of stable branch update 1.18, which should be released next week (more info about upcoming update 1.18: http://dev.arma3.com/sitrep-00053).

It was caused by dev branch, I am able to reproduce it in the stable 1.16.

Could you please check current version of dev branch and let me know if it is fixed there even for you? Thanks a lot!

Are you still able to reproduce this issue? I have tried your custom key mapping and I was able to create waypoints for UAVs. [Ctrl+Primary Mouse Button] and [Shift+Primary Mouse Button] worked fine. I have tried it in current dev branch. Thanks for letting me know about current state.

This issue should be fixed in current dev branch version. Could you please check it and let me know? Thanks!

No response for more than one month. Marking as resolved.

Marking as resolved - not fixable (caused by user-made content).

These drops are probably caused by that broken event handler mentioned by SaOk. It seems that this is not a part of the SaOk's mission (no one else reported this issue and even SaOk confirmed that it is not from his mission).

If that RPT log is really from the game without any mod, then I would recommend to reinstall the game (and delete manually all files in the folder S:\Steam\steamapps\common\Arma 3\). Right now there is still running something which is not a part of the vanilla game or SaOk's mission. Try the mission right after reinstall (before you install any mod), you shouldn't observe this issue. You can find out which mod caused it by installing all mods one by one and testing the issue.

Thanks everyone for help!

You need to remove the Arma 3 folder (where mods are stored) on your S drive (exact path is mentioned in my previous post) too. Be aware, that if you install Windows on different drive, it won't be automatically removed.

There is a discussion about this issue: http://forums.bistudio.com/showthread.php?152866-General-Discussion-%28dev-branch%29&p=2689733&viewfull=1#post2689733

Google told me that "25mmSparks" particle effect is a part of the Blastcore mod. Try to disable Blastcore, then check that this error message is not present anymore and try to reproduce this issue without Blastcore. If you won't be able to reproduce this issue anymore, then it is probably caused by this mod. On the other hand, it doesn't seem that anyone else having similar issue. I would recommend to check if the mod is installed properly before contacting the author.

Could be related to this issue: http://feedback.arma3.com/view.php?id=18671
I would recommend to wait for fixing of that issue and then check it again.

I was unable to reproduce this. It seems to be caused by given mission and we can't fix user made missions. Please report this issue to the author of the mission/mod, it must by fixed by him. Thanks

Marking as resolved. Thank you all for your feedback!

No reaction for more than a month. Closing as unable to reproduce.

Hi, I would like to ask you for more information. Could you please use "HOW TO GUIDE" link in the right top corner of this page and follow all steps mentioned in the part "How to report a crash"? Thanks!

First point is in the game. The second one is already reported here: http://feedback.arma3.com/view.php?id=12982

Closing this ticket as fixed.

Should be fixed in current dev branch version.

Should be fixed in next dev branch update.

Thanks for letting us know! Closing.

Hi,
is there any reason why you are so sure that this is not caused by any script present in Invade and Annex missions?

I have created my own dedicated server and tested Greyhawk with that respawn script. I was unable to reproduce it. Unfortunately, I can't find where the issue is without repro steps out of any big mod/mission. User-made mission must be fixed by the auhor.
I'm sorry, but you need to ask the author of that user-made mission for a solution. If he will be able to create some simple repro mission, I can look at it again of course.

Thank you for your understanding.

Should be fixed in next dev branch update (monday probably).

Should be fixed in next dev branch update (Monday probably).

Thanks for the feedback, I will check that issue with smoke module.

That "workaround" with smoke grenade module should work. You can set the smoke grenade module to last forever. Just switch parameter "persistent" to enabled.

Thanks for the feedback! Marking as resolved.

See sms's comment. There are cargo related scripting commands which should work globally. They should be used in this case. Could you please change it in your script and let us know, if it is working as intended after this fix? Thanks!

Thanks for feedback! Should be fixed in next dev branch update.

See PSK_Whiplash's post, he is right.
Only that "if the flaps are physically down, they have to be brought back up twice for them to be in their correct position" seems suspicious. Are you still able to reproduce this issue? Thanks

Thanks for the response. Closing as not a bug.

Should be fixed in current version of dev branch. Closing as fixed.

Unable to reproduce. Are you using any mods? Are you able to reproduce this bug even without mods? Thanks

Thanks! Now I can see this bug too. Reassigned to the right person who can fix it.

Hi, I wasn't able to find these stones. Could you place send us exact position of this issue? You can use in-game debug console. Just go on position of these stones, press Esc and into Watch field of Debug console insert code: getPos player

Then please copy array with numbers shown under your code in here. Thanks!

Should be fixed in next dev branch update.

Marking as fixed. Thanks for the feedback!

Duplicate of 0017308.

Should be fixed in current dev branch version. Could you please check it one more time? Thanks

This script error should be fixed already. Could you please try it one more time and let me know if you are still able to reproduce it? Thanks

Resolved - fixed.

This bug should be fixed in next dev branch update (today). We are really sorry for any inconvenience caused by this issue.

Hi, please report your issue via link "Contact Form" on this page: http://faq.bistudio.com/search?q=Question

Our support should be able to help you better, Feedback Tracker is more for bugs and suggestions related to the game itself. Thank you for understanding.

Are you still observing this issue? I am unable to reproduce this in current dev build. Thanks

Most of these bugs should be fixed already. In case you will observe any (new or old) bug, please create separate ticket for each of them. Bugs are usually solved by different people and I am not able to assign them properly when there is more bugs in one ticket. Any discussion in this case would be too very confusing. Thanks for understanding.

Closing as fixed. Thanks for help!

I am unable to reproduce this. Could you please attach a repro mission? Thanks

I'm unable to reproduce this issue. Could you please provide a repro mission or simple repro steps? Thank you

Skirmish trigger is needed for starting of skirmish. But skirmish is handled another way except this one module. It is explained in that post linked above.

These modules weren't removed without any explanation. There is link to the explanation in my previous post. All this have been made during the alpha stage of the game more than half year ago. There was warning about possibility of necessary changes which can affect user-made missions in this period of development.

We are sorry for any inconvenience caused by this change and we were trying to avoid similar changes with bigger impact on community work, but it wasn't entirely possible in the alpha stage.

These modules are not a part of Arma for a long time. At least if we are talking about the same ones. There is an explanation: http://forums.bistudio.com/showthread.php?152866-General-Discussion-%28dev-branch%29&p=2402360#post2402360

Checkbox in UAV Terminal is already present in dev branch version, it should be in stable branch soon. However, I will mark this issue as resolved. With all these changes it seems there are a few ways how to disable auto-firing of UGV and we don't want to disable it by default. Thanks for feedback!

Hi, you should be able to stop this behaviour by that already mentioned right click on waypoint and setting behaviour to never fire. You can stop UAV from doing basically anything via new "Autonomous" checkbox in the UAV terminal.

You are probably right, that this option (automatic shooting) would be disabled by default in real life. But we are in the game and more users will probably use enabled weapons. However, if you want to set these options (never fire or autonomous) on start of a mission, you can use script commands setCombatMode and setAutonomous. This is entirely up to mission author.

I would like to ask you for retesting of that right click on waypoint in the UAV Terminal. If it doesn't work for you, then it seems there is some issue. But I am not able to reproduce it, some repro mission would be useful in case you can still reproduce it. Thanks!

Should be fixed in next dev branch update.

Many thanks for investigation. I will try to look at it.

No response for more than a month. Closing.

It seems to be working fine for me. But "random 2" in count ends up in some cases with number bellow 0.5 and 0 weapons is added in that case. But I would say that it is correct behaviour. Is there any other issue with these commands?

Should be fixed in current dev branch version. Could you please check it and let me know? Thanks!

You are able to fire missiles yourself in Greyhawk now. Camera stabilization was improved as well.

No reaction for some time. Resolved as no bug.

See cancerouspete's post. I observe 2-3% fps drop, which is normal and we are not able to fix it. Are you able to reproduce this issue without that nearestObject line? Thanks
I would recommend to use some other way. Using of unlimited (457km) radius in nearestObject command is not very good for smooth fps.

Should be fixed in next dev branch update.

Should be fixed in current dev branch version. Could you please confirm if it is working? Thanks!

Thanks for investigation :)

Killzone Kid: Sure :)

1. Open new empty mission
2. Insert player as a BLUFOR UAV Operator
3. Insert a BLUFOR UGV Stomper RCWS
4. Start the mission
5. Open UAV Terminal via action menu
6. Connect to UGV by right click on its icon and selecting of connect item
7. Use "Control Driver" button in the Terminal
8. Press ESC and insert into execute field in the console: (getConnectedUav player) action ["BackFromUAV",player];
9. Observe that nothing happens

The code mentioned in the Additional Information field should work now. You are automatically kicked out of the direct control when a vehicle is deleted.

But action "BackFromUAV" is still not working for UGV driver position. We will look at it.

Duplicate of 16602.

No reaction for more than a month. Closing as fixed.

Should be fixed in current version of dev build. Could you please check it and confirm? Thanks

No reaction for more than a month. Closing as resolved.

Should be fixed in current version of dev build. Could you place check it and let me know if you still able to reproduce it? Thanks

Better example added in wiki documentation. Crash should be fixed in next dev branch update.

Please let me know if it is fixed and if there is anything else in this matter needed. Thanks

There need to be defined some other particle parameters as shape etc. You need to use script command setParticleParams or setParticleClass (refering to existing and properly defined class). Attached example is wrong definition and I don't think that particle should work in this case. But we will definitely fix the crash.

Thanks for feedback.

No response for a long time. Closing as unable to reproduce.

Unable to reproduce. Are you using any mod? Are you able to reproduce this issue even without any mods? Thanks

I will create a report in our internal system for that removeAllWeapons issue, it needs to be fixed by an engine programmer.

ManualFire is working consistent with other vehicles. Driver is commander of vehicle in this case and gunner AI is shooting when it is ordered to shoot. You can't see/hear any message, because radio protocol is disabled for AIs in UAVs. But I must admit that current situation is really confusing, we will definitely look at it. Anyway, I would recommend to create a new ticket for this issue and close this one. It is better to have separated ticket for every bug. Thanks

There were made some changes in the UAV system. I was able to reproduce that not working script command "removeAllWeapons", but it seems that this command is not working with any vehicle. Other issues seem to be fixed. I am just not absolutely sure if I have not missed something (there is more issues in this ticket). Could you please check it and let me know if there is still something which needs to be fixed? Thanks!

Unable to reproduce. Try to break some windows while shooting into back of the billboard, you can do it. Effect of impacting bullets is more visible on the back, because it has different color. But it doesn't change anything on passing of bullets through the billboard.

Parameter "centerPosition" is place, where is map defaultly opened in editor. It is not supposed to be the center of the map.

Should be fixed in the next dev branch update.

Unable to reproduce, no reaction on feedback request for a long time. Closing as no bug.

I am unable to reproduce that loiter waypoint issue in current dev build. Could you please check it one more time? If you will be still able to reproduce it, please create a new ticket with step-by-step repro or repro mission. Thanks!

Should be fixed in current version of dev build. Could you place check it and let me know if you still able to reproduce it? Thanks

Should be fixed in the next dev branch update. Marking as resolved.

Hi, we can't fix user-made missions and mods. Please contact directly author of that mod.

See answer from kju, there is already this command in the game.

Unable to reproduce. Could you please check it one more time and provide more precise repro? Thanks

No reaction for almost one month. Closing as unable to reproduce.

I am unable to reproduce this issue. Engine of vehicle is running right after start of the mission in all cases and I can stop it by scripting commands. Are you still able to reproduce this issue?

Unable to reproduce and no reaction for some time. Resolved as fixed.

Are you still able to reproduce this issue? It works correct for me. Thanks

Hi, we can't fix user-made mods/missions. This issue must be fixed by author of the mod or author can report vanilla game's issue which is responsible for this behaviour.

We are very sorry, but there is a lot of mods and we don't have resources to check all broken mods created by users.

Thanks! Marking as resolved.

Hi,
we have made a lot of changes in the UAV system in last few months. Are you still observing this issue? Thanks

You are right, documentation fixed. Yes, please create a new ticket for that vector rotation function. It is more complicated than this fix and engine programmers are very busy right now. It will take some time probably.

Thank you for feedback and help!

Should be fixed in current dev version. Could you please check it and let me know? Thanks

Consulted with author. Current colors are intentional, it is not a bug.

Should be already fixed for some time. Marking as resolved.

Should be fixed in current version of the dev branch.

That's fine. I'm glad it is fixed. Marking as resolved.