- User Since
- Mar 9 2013, 3:55 PM (353 w, 19 h)
Jul 21 2017
Jul 20 2017
Jun 19 2017
Jun 18 2017
Jun 17 2017
Please make this ticket private, as I don't know how.
Apr 11 2017
Sounds great! Thank you.
Does status as "Feedback" mean that the issue will not be fixed for the foreseeable future?
Apr 9 2017
Apr 4 2017
Mar 29 2017
This ticket is duplicate of https://feedback.bistudio.com/T123781.
Mar 28 2017
The issue is not fixed in 1.68 hotfix RC.
Mar 26 2017
In 1.66, I played through the mission with no problems. Replaying mission in 1.68, I get the same problem as described here. Vehicles will not move beyond ambush point near chapel; they will not move to warehouses at point Yankee. Secure Warehouse task will not complete even though all AAF are dead. Mission will not proceed.
Mar 17 2017
IMO, this issue is worth a hotfix, as it is such a critical problem for mission makers.
Mar 1 2017
This fix is not in current RC released Feb. 28. Will it be included in future 1.68 RC, or next stable branch?
Feb 22 2017
You're on a roll! Great work!
Feb 20 2017
Yep, completely fixed now. Good job!
Feb 19 2017
Feb 14 2017
Likely the same issue reported here in dev branch:
I reported what looks like the same issue in 1.68 RC:
Feb 12 2017
Feb 11 2017
Jan 28 2017
Yep, changing interface size has no effect on issue, as reported here:
Jan 25 2017
This issue is still very problematic in 1.66 stable. Proper order of tasks and diary records for briefing can only be achieved by placing the Create Task or Create Diary Record modules in a set order, with the last-placed module being placed on top in the list. PLEASE make task order relative to taskID, so that taskID = 1 will always be on top in task list, taskID = 2 the next down, and so on. As Create Diary Record has no such thing as an enterable ID, a new parameter, such as "Record Order" or "RecordID," should be added to make it simple to order the diary records.
Jan 16 2017
Confirmed in 1.66 stable. Also, there is no way to manually type a string value for task type into the dialog box.
Using 1.66 stable, only way to get task icons to display in initial briefing at start of mission is to manually edit Type section of mission.sqm for each task.
Nov 15 2016
Sep 25 2016
I very strongly agree with this. Please add option to play with AI team, at least when playing solo.
May 11 2016
Yep. I would strongly suggest that you refrain from really "playing" the game until the full, "final" version is released. As it is, your saves most likely won't work when the next "stable" (non-dev) build is released. We are missing the images/movies/data associated with the science findings anyway. The Early Release version is just to identify major bugs and get suggestions from the community.
I get the exact same problem using current dev build at the very start of the space program, and it renders the game unplayable, as the camera cannot be used to film crater rim (gas can be collected). As soon as I reverted to stable (non-dev 0.8.0170) build, the problem went away and I was able to use the camera in Victoria crater.
May 10 2016
I wonder if this feature was removed from A3 by design, as AI had trouble accomplishing the refueling for some reason, or petrol stations are handled differently in A3 terrains.
When tanks are in a column under alert mode, and order is given to stop, second tank will usually crash into rear of lead tank, and often flip over. Entire column becomes confused and in disarray after halt order, and correct spacing is often not maintained.
In line formation, subsidiary tanks will proceed for >100m after halt order. See uploaded image. Line formation is only regained after about 10 seconds.
Oh man. That is not good at all. Does the problem occur when a tank is behind a low wall in the terrain that covers the hull only? Or some piles of garbage?
Heavens, what a nasty bug. Hopefully the problem is just with those sandbags...
Affects East Wind campaign: http://feedback.arma3.com/view.php?id=22058#c89198
Could this issue be related to this old one?
Problem identified in December 2013:
Acknowledged by BI dev:
This issue affects canFire reporting of vehicles that start mission with no ammo, see http://feedback.arma3.com/view.php?id=22164.
Yes, that's good. But there should be a comment in there that says something like:
"If mission starts with vehicle having no ammo, then canFire will always report false for it."
That is the issue that made me start this ticket, and that is related to the A3 bug I mentioned in above post (http://feedback.arma3.com/view.php?id=22164#c85986). When the A3 bug below is fixed, then the comment may no longer be needed.
Here is post where I recognized the problem over a year ago: http://forums.bistudio.com/showthread.php?163311-Rearm-vehicles-with-ammotruck-not-working-(SP-MP)&p=2570207&viewfull=1#post2570207
Great! Case closed. :-)
Ok, based on your findings and mine, what about this for biki page:
"Returns if the given vehicle is still able to fire. This command checks the damage value, not ammo availability (if mission started with vehicle having ammo)."
Comment: canFire always reports false for a (completely) empty vehicle, even if it has full ammo and no damage.
But I think I have found another problem, which may have been previously reported, and which may effect this canFire issue. I have a vague recollection that I've heard about this issue before, perhaps in forums. If a mission starts with vehicle having no ammo, that vehicle cannot rearm at an ammo truck, and gunner doesn't report that he "needs ammo" to the commander. At mission init for a vehicle with no ammo, the ammo state is fixed on empty, and that is why canFire reports false even for an undamaged vehicle. That looks like a bug for sure. However, we can still edit the canFire page as I wrote above, at least until the ammo bug is fixed.
My last post contradicts the 2008 post on the page:
False if there is no gunner in the vehicle, regardless of damage level. "
So that comment should be removed also.
Another fact: canFire always reports false for a (completely) empty vehicle, even if it has full ammo and no damage. That should be added as a comment.
But canFire will return true if there is no gunner, as in my second mission and post http://feedback.arma3.com/view.php?id=22164#c85967.
Try new mission I just uploaded. Orca named a2 has full ammo. Start mission and then do radio alpha. canFire = true. Then order gunner of a2 to disembark. Then do radio bravo. CanFire = true. So the presence of the gunner is not checked by canFire, I guess. I edited the above post as to what the biki page should say. Let me know if you disagree.
I cannot find a situation in A3 stable or A2OA/CO where canFire shows true for an undamaged vehicle with a gunner present and no ammo. So, I think the page should read thus:
"Returns if the given vehicle is still able to fire. This command checks the damage value and ammo availability."
And the 2007 post by Bdfy should be removed.
Try the attached mission, which uses ah-99. With player as gunner, canFire reports false with no ammo. (stable build)
Killzone wrote "If you are on turret returns true even if no ammo"
This is not true for me. In my mission, if you swap the ah-99 for a ifv-6v Panther (or with any other armed vehicle, I would guess) with no ammo, canFire also reports false. The conflict with the biki page is obvious.
Note that the comment at the bottom of the biki page:
"true even if unit is out of ammo. Only false if gun is damaged. "
is also wrong.
Great! As the ticket description says, I already tested the issue in A2OA (actually A2CO) 1.63.112555, and the behavior is the same as in A3. I could upload an A2CO mission if you like. I have not yet tested in 1.63.125548 (current Steam stable build), but it is highly unlikely that the behavior is different than 112555 and A3.
This is quite important. The scope should always retain its last user-selected optics mode. I made some comments on the scope here:
Additionally, there could be a way to lock the scope on a given mode, but having it be continuous as suggested here, is most likely easiest to implement and the best.
Using current stable build (1.38), and only VTS Weaponrest mod loaded, I replayed Common Enemy (not a revert, just a replay, as I have already finished campaign). Mission played perfectly without a hitch.
In 1.40 playthrough of Win, I experienced all of the issues you found, except those in Moral Fiber. The chopper landed correctly at warehouse, and AI drivers made it successfully to cemetery. The first time I played through, those issues in Moral Fiber were definitely there, and very annoying.
Most issues still exist using 1.40.129533 stable build. Some additions:
In Resurgent West, many FIA units under Kerry's command lag so far behind him when flanking Neochori that they become lost and die, even though they are not under fire.
In Moral Fiber, unit 2 (medic) is trapped in Hunter HMG and will not disembark when Kerry is attacking Pyrgos to blow tank. Tank is too easy to blow using arty strike, which is apparently scripted and will result in a direct hit every time if strike is called in on task destination marker. Marker could be moved to a more general location near AAF strongpoint so that player would at least have to read map carefully when calling in strike.
Preventive Diplomacy: Unit 4 (AT) constantly says he is out of ammo, even though he is not.
Paradise Lost: A-164 Wipeout gets blown out of sky very quickly if even just a few AAF vehicles are left after arty. Hint should be given that laser designator should be used to call in targets for Wipeout's laser-guided bombs.
That damn service comes with this new Razer mouse I bought. You are correct, if I kill that service, A3 Launcher works even if Steam is run as non-admin. I don't use the Launcher anyway, so I will wait for next stable branch update before trying it again.
Admin run of handle uploaded.
Handle output uploaded today. Please delete the files I have uploaded after you have them - for security.
Killer Network Manager monitors my Killer Xeno pro gaming network card. BFNservice (Big Foot Networks) controls the card. Both packages start automatically on boot. It would make sense that there is a conflict between those packages and the Steam A3 Launcher. One time those packages had a conflict with iTunes network function, but the packages were patched to fix that.
However, killing the Network Manager and BFNservice does not affect the Steam Launcher function, as the same "Steam is in offline mode" and "Check if Steam client is running" errors still persist.
I normally use a non-admin account on my Win7 x64 box to play BI games. If I start Steam normally, the A3 Launcher always says that "Steam is in offline mode," followed by "Steam service unavailable. Please make sure Steam client is running." The launcher will exit if click "Ok". If I start Steam as admin, the Launcher works. Is this behavior normal and intended? I can upload the Launcher log from my non-admin Windows account if that will help. Using A3 1.28.127008 stable build.
I start Launcher by right-clicking on Arma3 game in left column in Steam, and selecting "Open Launcher," or I click Play for Arma 3, and then click "Open Launcher" in little window that pops up. I am starting launcher as NON-ADMIN user. If I start Steam as ADMIN, then "Open Launcher" works fine. I'll upload my files.
I mentioned this problem, and suggested some possible solutions, in July 2013.
Here is my original ticket, which is obviously related to this ticket
The problem also occurs when blood pool is illuminated by sunlight. See http://www.imagebam.com/image/ebcc96375240988.
And videos in this post: http://forums.bistudio.com/showthread.php?186747-Blood-pool-removed&p=2844159&viewfull=1#post2844159
^ ^ What NakedViking wrote is completely true, and has wasted many hours of my time using current stable build. Isn't this a bug? It really complicates using task modules if switch triggers cannot be synched to task modules without the trigger conditions being seen as already completed, when they have not.
By the way, I am seeing the switch trigger problem in editor for both SP and MP missions.
I think the switch trigger problem deserves its own ticket, if there isn't one already. Does anyone agree?
Confirmed using stable build 1.06.112613.
Duplicate of http://feedback.arma3.com/view.php?id=16322#c61242, which has been fixed.
I replaced my GTX 295 with a GTX 680, and the crashing issue is gone using current stable build.
I have a GTX 680 in another machine that I can swap into my gaming box, but I am hesitant to do so as there appears to be quite a few people with 500-700 series DX11 cards that are also getting the "DXGI_ERROR_DEVICE_REMOVED" and related errors....
Thank you for the suggestions. I already tried to place diver near water in editor and dive off Stratis, and that did NOT lead to a crash. I just did a video settings autodetect and started Scuba showcase again -> crash. Dumps will be uploaded. Note that I played through the Scuba showcase several times during Alpha and Beta with no problems.
It may be time to retire my 4-year old GTX 295.... :-(
Please let me know of any further way to diagnose what is going on, as I am at a loss. Max Payne 3 supports DX11 (and 10, 10.1, and 9c) and it runs fine. dxdiag reports no video device errors.
As my system specs show, my GTX 295 is DX10 only, but that hasn't been a problem so far and is within minimum system requirements. I have not run a DX11 benchmark. I just re-installed 331.65 drivers, and still get the crash.
The fact that the game and computer will crash only at start of Scuba Showcase and at nearly same point in Wet Work mission points to an A3 problem, not a hardware/driver problem. I started Tank Showcase just now and it played with no problem. Quit and started Scuba -> CRASH. What, if anything, is different with Scuba and Wet Work missions?
Are all the people having http://feedback.arma3.com/view.php?id=579 problem also having only hw/driver problems?
Tried placing diver again and dove in editor -> no crash, excellent performance. Quit and started Scuba Showcase -> instacrash.
Yet another rpt+bidmp from crash at start of Scuba showcase uploaded. This looks suspicious: "c:\w\c_branch\poseidon\futura_stable\lib\ui\uimap.cpp DisplayGetReady::Destroy:NOT IMPLEMENTED - briefing!"