It appears at first glance that this issue wasn't addressed for the 1.98 Old Man update. Overview data still isn't being read from pbo in Mission folder.

KK, let us know if it would be helpful for us to make a new ticket splitting this issue into two, namely:

The Steam-related issue discussed here appears to be related to the process of publishing a mission to Steam Workshop from Eden editor. In that dialog, a mission description and image can be uploaded along with mission (after agreeing to Steam Workshop legal BS). IMO, the data entered in that dialog should NEVER replace data already included in mission (e.g. overviewText, overviewPicture, data in Eden Attributes, etc.) UNLESS the user clicks a switch/toggle to that effect. Such a toggle doesn't exist AFAIK.

Could it be true that BI delegated all overview data to the Steam system and removed the ability to make pbos with all overview data self-contained? Seems unlikely to me......

Great! I am so glad that it's a bug! The system is still reading data from the Steam workshop page, and at least some of that must be intentional.... Perhaps the system is meant to read data from Steam if no overview data is available in mission, and the bug is preventing the reading of mission data, thus resulting in data being read from Steam?

I tend to think that the decision to kill user-entered overviewText and overviewImage in description.ext/Eden Attributes and replace them with Steam data was a corporate one, and no further thinking went into it. If so, this is a real shame. The most obvious reason why it is a bad idea is that a mission's description on Steam workshop is meant for "marketing" and information purposes, to provide potential players with data like gameplay elements, links to forum threads, other web sites, etc., whereas overview data typically entered by mission makers are designed to get players psyched to play by putting them in the mood/headspace of the mission. I find it hard to believe that BI would stealthily do this without informing the community, even in the biki. Perhaps I missed it, though.

Please make this ticket private, as I don't know how.

Sounds great! Thank you.

Does status as "Feedback" mean that the issue will not be fixed for the foreseeable future?

This ticket is duplicate of https://feedback.bistudio.com/T123781.

The issue is not fixed in 1.68 hotfix RC.

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.

IMO, this issue is worth a hotfix, as it is such a critical problem for mission makers.

This fix is not in current RC released Feb. 28. Will it be included in future 1.68 RC, or next stable branch?

You're on a roll! Great work!

Yep, completely fixed now. Good job!

Likely the same issue reported here in dev branch:

I reported what looks like the same issue in 1.68 RC:

Yep, changing interface size has no effect on issue, as reported here:

Hi Alwin,

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.

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.

+1

I very strongly agree with this. Please add option to play with AI team, at least when playing solo.

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.

Will do.

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.

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?

http://feedback.arma3.com/view.php?id=14840

Problem identified in December 2013:

http://forums.bistudio.com/showthread.php?163311-Rearm-vehicles-with-ammotruck-not-working-(SP-MP)&p=2570207&viewfull=1#post2570207

Acknowledged by BI dev:

http://forums.bistudio.com/showthread.php?163311-Rearm-vehicles-with-ammotruck-not-working-(SP-MP)&p=2571280&viewfull=1#post2571280

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.

A3 bug: http://feedback.arma3.com/view.php?id=22168

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:

"Canukausiuka

    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:

http://forums.bistudio.com/showthread.php?189028-quot-optic_Nightstalker-quot-and-thermal-scope&p=2884899&viewfull=1#post2884899

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

http://feedback.arma3.com/view.php?id=11151

Voted up.

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.