Talk:ArmA: Armed Assault: Bug List

Bug Tracking System

As there is now "unofficial" bug tracking system running, containing all bugs from this page imported, I think we should consider closing this page and redirecting users to that system (check it at http://www.boeckler.org/mantis/changelog_page.php). An alternative could be to having some volunteers doing synchronization for those who prefer reporting bugs here, but I doubt anyone would be willing do that. (Off course, another alternative is the majority of the community may prefer bug tracking being done solely here, which I doubt, but if it is the case, we can reopen the page again and continue as it is now). Please, voice your opinion here. Until we decide, this Wiki bug list is protected and user cannot change it. --Suma 11:10, 14 February 2007 (CET)

I think the tracking system has a stronger implication that an official response will be given to each bug. As it stands, the wiki page is just a list. An official word stating the intention of the public listing/tracking of bugs could help (eg, BI have an internal bug reporting system and this is just a secondary). --Ceeeb 14:15, 14 February 2007 (CET)

As this is a community tracking system, there is no guaranteed response from us (yes, we do have other system we use internally). Its primary purpose is for the community to have a list of known issues, workarounds for them... However, as you can see in the bug history in the tracker, chance of getting response from us are quite high, esp. for fatal or major issues. --Suma 14:27, 14 February 2007 (CET)

Too bad there seems to be no edit feature for bugreports on boeckler.org. thus it's imposible to fix errors (wrong Category etc ) --bdfy

Oh it's there, It's just the access matrix, what prevents that (an Updater can do that). This could be discussed in the notes of the issue. IMHO it's in the responsibility of the assigned person whether the category fits. --Boecko

On the other hand, we can discuss the initial access right of users. --Boecko

I find the new list a lot more confusing especially the priories. But I can live with it. Should I lock the Biki bug list then? hoz

I tried to map the priorities to the BTS-priorities AND to severities. One (with manager access) can changethis on the fly (Filter given priority, "Update Priority" at the bottom of the page. --Boecko

Hoz, Boecko is trying to express that both priorities AND to severities can be configured to ones preferences - the priority descriptions are the defaults values of the mantis. also i think both priorities and severities should only be possible to get changed by the BTS admins - i think one can configure mantis that way.--WGL.Q 20:28, 14 February 2007 (CET)

Now i see - after several reports i became and updater and got edit option.--bdfy

Please, provide repro steps. They may be obvious to you from the bug description, but they often are not. Example of issue I would like to have repro steps for is http://www.boeckler.org/mantis/view.php?id=1914 --Suma 22:10, 14 February 2007 (CET)

Since this is a professional and pretty complex system, and even the official manual can be a bit scary at first, here is a bare-bones description for bug-submitters: http://wiki.scribus.net/index.php/How_to_file_a_bug_report.
Of course, that article is written for a different product (and therefor contains some information that doesn't apply to ArmA), so we should probably create something similar for our own Wiki. --Kronzky 16:38, 14 February 2007 (CET)

Right - i think the BIKI here would be a good place to make a site which contains an introduction and a quick guide as well as a detailed summary how to report bugs best. --WGL.Q 20:17, 14 February 2007 (CET)

Introduction sort of:

* Why use a BTS at all

* Explanation of mantis UI

* Background (BI standpoint)

* Where to report suggestions to improve the system (BIKI?)

* Emphasis on quality and still open for EVERYONE

* more?

Quick guide sort of:

* Check if your problem can be reproduced at all.

* See if there is an existing entry for your problem in the BTS (search function).

* Report your bug SMART and one problem is one bug report (don't mix different problems in one report).

* Test the problem once a new patch is out (which is said to fix the problem) and close the report in the BTS if its fixed for real.

* more?

How to report bugs detailed / detailed summary should include:

* how to report bugs SMART (topic description, required and important informations to be written in the description field, how to write a description (style), how to repeat a bug (detailed desc. on occurrence), more)

* why, in what way (is it to be made) and how to add a screenshot

* a note about how to capture SMALL videos for better bug understanding

* Repro steps - providing accurate repro steps helps the one fixing it very much.

* Add simple example missions, even if you think that your description is complete (on Rahmadi, if possible; only really obvious bugs don't need examples)

* more?

In addition the page should also include a description:

* how to use Search and Filter: Full Text Search and Simple/Advanced Filters

* how to active email notifications (to get news about changes AND to able to test the problem once the according patch is out)

* how to monitor specific issues (same here)

* a note about RSS feed support

* more?

Also as far as i got this, the current BIKI / Bug List mods are highly encouraged to join up in the new BTS as managers over there as well as new people to configure and maintain the platform in the best quality! This is meant as a community project and the mid/long term goal is to be able to provide a better interface for the community AND BI to report and keep track bugs of Armed Assault to help to make the game better. So if you want to get this project as successful as possible voice your interest and join up! --WGL.Q 20:28, 14 February 2007 (CET)

I might add, that it's possible to setup responsibilities for certain categories to certain people. E.g. Issue in category xy is assigned to dev/manager xy for evaluating the issue (reassign, closing,etc).

The given persons automatically get an email-report about the status. --Boecko

Another topic to think about is if there platform should be multilingual - either as separate projects or all in the same. Some people cant speak english, so overall i think it would be best to offer this platform also for non english speaking parts of the community. --WGL.Q 20:28, 14 February 2007 (CET)

Thank you to Boeckler for hosting this and BIS for adopting it. It's a major step forward. Speaking for myself, being able to see some feedback from the devs on some of the issues that are being resolved is a major incentive to make the effort to report things. Sbsmac 23:31, 14 February 2007 (CET)

Bug Tracking System - Voices against

This is a little late, but I was not able to participate in the discussion up until this point. I was in the process of preparing a comprehensive argument against. I see that this has gone forward, but I would like to post my unfinished argument for the record (chiefly because I have already spent a lot of time on it). --Plaintiff1 01:38, 15 February 2007 (CET)

I'm not completely sure what this bug tracking system is hoping to achieve beyond an increased level of automation. I'm not entirely convinced that a list for bugs requires such an automation or the resulting increase in complexity and diffusion of community resources. Such a programme would be no more useful than any other list.--Plaintiff1 01:52, 15 February 2007 (CET)

We are not tracking bugs for BIS, but rather, listing what the community perceives as bugs. If I am not mistaken, the discressionary priority we assign the bugs is more or less a way of sorting the information beyond the pragmatic categorical sorting. Without BIS staffers minding the list, these methods of sorting the information is largely arbitrary and are the result of a educated guessing game. This list isn't even usable as a list of bugs: It is more like a collection of reports from beta testers, not a collection of bugs for them to act on. They need processing to actually turn them into bug reports they can use. We are simply throwing down some information that we hope will be useful for BIS and for other community members in their troubleshooting efforts (i.e. to confirm the responsibility of a known bug for a certain problem behaviour).--Plaintiff1 01:52, 15 February 2007 (CET)

As for the community's interests, I think that adding another superfluous protocol to learn in another system on yet another page is like whimisically adding a fifth, suspended, steerable wheel to a concept car- however shiny and feature-laden it is, there isn't a community side need for it. It would just add bulk and complexity to a larger community resource that is only yet finding its legs. The current resource is easy to use, easy to find, easy to interact with, easy to discuss, and easily policed. I think that if this bug list is moved into a bug tracker format that it should be clearly stated that this move is for BIS's benefit and why, as I cannot see any end-of-the-day benefit for the community. We are not trouble shooting, solving or interacting with the bugs in any way other than finding them and listing them.--Plaintiff1 01:52, 15 February 2007 (CET)

Ease of use

The voices of the proponents for a community bug tracker seem by-and-large programmers. These are people who are already familiar with the concept of a bug tracker. Some people express a hesitation to learn the Biki based on their fear of the alien protocol. Let us not lump another level of complexity onto the pile. To use another automotive metaphor, using a tracking program for the bug list is like having a 600 horsepower car. What do you need it for? Only enthusiasts would want such a thing and a small percentage of those would even be able to make use of it. There are features within the bugtracker that simply aren't of any use to the person that this list was designed for- the average community member seeking to share his or her knowledge and experience with BIS.--Plaintiff1 01:38, 15 February 2007 (CET)

As I am programmer, I cannot be unbias on this. However, submitting bugs to Mantis seems much easier that writing them to Wiki. There is plenty of people you never edit Wiki, only browse it. I suppose for them filling web forms (which is what Mantis does) is much easier than getting familiar with the Wiki template syntax to be able to fill in the record. The Wiki Edit feature is far from easy to use, esp. on long pages. --Suma 09:11, 15 February 2007 (CET)

I switched on the simple bug report in mantis (i disabled it before). Try it --Boecko

Out of Plaintiff1 comments I read the fears that 1.) the biggest part of the community would not be able to use mantis and hence would not report bugs because of this and 2.) the maintenance and management of the bugs would cost more time then it safes. To 1.): Someone who is able to speak/write english (if not his mother toungue) is usually able to assemble a telling TT in mantis. For those which are not able to write english it is possible to write the description of the TT in his language, the mantis managers will try to translate into english without loosing the sense of the original TT (we might have problems with mandarin :-) ). Like we did it for WGL there is always the need for the managers to browse the forum as Q created it here for WGL bug reporting: http://ofpc.de/wargames/e107_plugins/forum/forum_viewforum.php?7 to pick up some bug reports out of some discussions. But to keep track if/how/when the bug is fixed - there I do not see any other option then a BTS. So Plaintiff1 is right if he says mainly BI & experienced developers/scripters/addonmakers taking the most benefit in the 1st line - but what is wrong with that, usually they can deliver already a very good pre-analysis of the issue and if they are served all other community members would participate from the more reliable engine and more excellent content in the 2nd line. Btw from experience also weekend gamers where able to drop telling tickets in the WGL BTS bugzilla we used there initially and later in trac and those two are not as user friendly as mantis in my opinion. To 2.) A TT system safes time in the long run by ensuring that no issue is forgotten, several TTs with the same root cause could be mapped together by the developer, developer could send the TT creator a request for further information...Let's try and see what happens during the regression testing of 1.04/1.05 --INNOCENT&CLUELESS 10:17, 15 February 2007 (CET)

Introduction

This talk page has multiple purposes, please respect that information from time to time will be purged from this page. You can view the history at any time by clicking the above tab.

Defining Priority

⚠

Bug priorities To make it easier for BI people to see important bugs, we introduced bug priority templates. Add new bugs with priority 0. Only BigDawgKS, Plaintiff1, the BI staff, and the wiki sysops are allowed to set priorities to values higher than 0.

How does one define a priority?

Priority 1

• Any issue that causes a CTD (crash to desktop) during a normal gameplay. CTD using mission or content creation are not considered priority 1, esp. when caused by scripting and it is possible to avoid the CTD by not using the construct triggering it.
• Any issue that prevents the game from loading.
• Any issue that prevents installation of a patch
• Any issue that decreases performance significantly, up to the point of making the game unplayable. (especially if this was working better in previous ver)

Priority 2

• Issues that prevent MP game play
• Any other issue that causes a CTD, including mission scripting.
• Any issue that prohibits game play as per design
• Issue that prevent the operation of a vehicle/unit/object as designed. (can't get in vehicle, helicopter moves incorrectly)
• Issues that allow cheating. (example: sniper sites allows a person to see through walls)
• Significant performance issues (low fps in situation where decent fps would be expected)

Priority 3

• Annoying behavior, such as Repeated voice command.
• Sounds that aren't working as they were designed.
• Collisions in models which affect game play. (such as doors which prevent entry, invisible wall)
• AI not doing as they should/designed. (stuck, not running for cover, etc)
• Mission issues that prevent the completion or playability.
• Scripting commands that do not work as intended and/or at all

Priority 4

• Any issue that causes an in game error (missing paa, missing name)
• Graphical Nuisances (missing textures)
• Annoying collision issues.

Priority 5

• Missing sounds which maybe were never intended.
• Spelling errors
• Minor mission issues that don't affect the game play

Questionable Bugs

I've noticed that some users are reporting bugs using old builds. There are a lot of obsolete bugs on the bugs list in terms of the latest demo builds. I've flagged them. Do you think we should whipe them out now or wait for an official patch? --Plaintiff1 00:17, 14 January 2007 (CET)

Older Entries

• No way to control parachute. It seems randon. This is a feature that's been available in BF for years ! :--Major Latency

Then make a wish in the wishlist. hoz

• Night vision is apparently unusable on certain system settings. The HDR effect gets overbright and all you see is green light. My graphics card is GF6600GT with the newest drivers. Here is a picture [v1.02] --Celery

Does it stay like this? It takes some time to accomodate to the bright image Scruffy 22:37, 5 January 2007 (CET)

Removed, I think this is by design, it takes time for the NV to adjust. hoz

• AI can enter bases which are surrounded with walls/fences through walls/fences. They don't look for an entrance or a hole.

No location given not signed, useless. hoz

• When you crouch with a riffle and apply turbo forward you remain crouched and unable to sprint forwards. However when you use a pistol you are able to use turbo forwards from a crouched postion and return to crouch at the end of your run.

From a crouched position and riffle in hand you should be able to Turbo forward then crouch again at the end of your run -TheOne

Not a bug as per design, as mentioned by marek in the Demo TS thread. hoz

• Mission will start automatically after certain time when all players are in briefing screen. This should be changed to all players greened up or admin mission kick off. The current auto start does not allow for a proper weapons selection or mission planing. Sometimes people just end up without any weapons in the scenario. --SniperAndy

More of a wish then a bug. I think this is by design to keep the games moving, annoying as it is.hoz

• Should there be a different explosion effect when tanks fire into the ocean/water -NipWup

Wish/request hoz

• Wood stacks looking strange if destroyed pic [1.02] burns 02:07, 16 December 2006 (CET)

This might also be a design decision, as if wood stacks get unbalanced and collapse. --Sniperwolf572 17:27, 18 December 2006 (CET)

I think it's because tehy fall like trees if damaged. Seems to be dependent on angle as one fell to the right side. Scruffy 22:40, 5 January 2007 (CET)

As per design, not really a bug, make a wish for a better damaged model.hoz

• eg: on island Suthern Sahrani get AI to drive tank from grid reference Gd,56 to Ff49 (on the road) at around Grid Ga,53 and Gb,54 AI has trouble keeping to the road, or try's to find away around by going up the hill. I found that AI has problems navagating near steep land formations. Sometimes AI will plot a corse strait up the hill from grid Gd,56. [Demo 1.03] -NipWup

I beleive if the combat mode is set to careless you might see this behavoir. Try a very basic mission and change the combat modes. hoz

• When player is driver he cannot reveal and mark targets for the gunner.

Driver cannot switch vehicles lights on and off without (needs a permission from gunner) [Ger v1.02] -- Miki

Driver is not commander, in M113 gunner is commander and therefore gunner issues lights on/off, targets. hoz

• After picking some grenades, I have to push "F" twice to go through "HandGrenade" weapon - Lou Montana ArmA Demo 5116

Picking up 2 different kinds of grenades is likely whats happening here. hoz

I thought it was that first, but it happened to me to press up to four times "F" to go through. Maybe it's "picking 2 nades, throwing 1, picking 2, throwing 1, etc", adding 1 "step" each time... - Lou Montana

• Switching view from inside to outside of a jeep will autocenter when leaving view (by the way, the center view of HMMWV is too high :) - Lou Montana ArmA Demo 5116

By design. hoz

• Wrecks of Trucks and Cars (for instance "UralWreck") doesnt fall down if you place them in the air. Do they have a physics at all ? Screenshot [1.02] - Snowball

As per design, the wreck is in Class strategic like a house, physic's don't apply. hoz

This behaviour was also the case in OFP, nothing new here. Planck 01:27, 25 January 2007 (CET)

• Binoculars are always put away (changing to weapon) when player changes stance from standing to crouch... very annoying! I suggest that binoculars should work in the same way like scoped weapons do; choose binoculars with "b" or through action menu and watch through them with the right mouse button. they should stay in hands while moving unzoomed [1.02 german] --TheVoodoo

Bug or strange design decision? It was like this in ofp, for what it's worth. --Plaintiff1 23:25, 18 January 2007 (CET)

anyway, its time to improve the useability of it! --TheVoodoo

Then make a wish, not a bug. hoz

I know it's a little late and doesn't matter in terms of the bug list, but as of v1.03 binoculars remain in hand when switching between standing and crouching, the character doesn't hold them up to his eyes when switching but no more changing to primary weapon first, and is relatively fast. --Big Dawg KS

• Hello, I have a X1400 Mobility Radeon graphic card 128 Mo and sound and screen freezes after 30min of game.

Unfortunately, we need much more information than this if we are going to keep this bug, so please consider revisiting it. --Plaintiff1 20:58, 19 January 2007 (CET)

Hit the BIforums for help, or submit more useful details. BI Forums are the best bet though.hoz

• Russian units use english environment speech. You hear infantry commands in english language when close to them, and you hear 'out of fuel' and 'out of ammo' when in the proximity of russian vehicles [1.02] -Desertfox

The Opfor in Armed Assault are not Russians. Infact, according to the story line, most of the population in sahrani are multilingual because of the small size of sahrani. --RyanKaplan

A possible solution could be the use of different accents for people from North Sahrani, South Sahrani, and Americans. Then the player could use accoustic information to tell friend from foe and the story line would not be broken. Suitable accents for locals would be Spanish and Portuguese because the place names mostly seem to be taken from these languages. --Alpha-kilo 09:55, 4 January 2007 (CET)

Sounds like a sensible solution to a non-existant problem. --Plaintiff1 08:22, 12 January 2007 (CET)

This is clearly not a bug. I'm going to remove it soon unless there's some objection. --Plaintiff1 09:22, 22 January 2007 (CET)

This bug has been removed --Plaintiff1 04:44, 25 January 2007 (CET)

• Some sounds are overriden by others eg: when gunner in humve and you can year a distant vehicle driving, the driving vehicle's sound is muted for the piriod of time you openfire*, this might be associated to the hardware acceleration issue where eg: you can hear a chopper starting up from the otherside of the island, *firing the gun might just be muting the bug.

(ver 1.3.0.5110) on a X-fi elite pro (driver ver 1.01.14) -NipWup

I believe this is a feature of the HDR sound engine. --Plaintiff1

I respect your input, but i really dont think so. Most games with high sound quality settings enabled allow for the most possible number of sounds to be played at one time, this adds to sound detail which makes games sound good.

When a loud sound plays you can't hear the quiet ones. There's not many sounds louder than a gun going off in your face. This is a feature that acts exactly as BIS described it. Whether or not you like it is your issue. --Plaintiff1

does BIS describe that sounds are muted when louder sounds are played as a feature ? im sorry that ive missed this, can you provide me with a link where they list the sound features. and where did you get the impression that i dislike this ? ive said in my original report that this might be muting a different bug. im reporting somthing that I think might be a possible bug or fix other bugs, im not here to debate with you about a game feature. let the bis crew decide whether this is a bug or feature. -NipWup

I found Maruk's original post as well as several other mentions in other forums through the simple magic known as google. I have also been able to find mentions of it on the simhq reviews and forums, but their site is down for maintenance at the time of this writing. Moreover, this technology was already implimented in OFP:Elite. So yes, you did miss it; and no, it's not a bug. BIS has already explicitly stated its nature as a feature. Consider removing it? Thanks. --Plaintiff1 05:10, 11 January 2007 (CET)

This bug has been removed --Plaintiff1 04:44, 25 January 2007 (CET)

• AI gunners in armoured vehicles or artillery cannons are too smart. They can move a turret, aim and kill you with a sniper's precision in a less than 1 sec when they spot you... [v1.02.5103 Polish] -BezylatoR

Is this a bug? --Plaintiff1 04:51, 25 January 2007 (CET)

Removed from list --Plaintiff1 01:46, 31 January 2007 (CET)

• While sprint, unable to change firing mode (auto, burst, grenade, grenade launcher). Bug or game design? [1.02] - Silverr

I think you should perhaps post this in the Bug or Feature? section. --Plaintiff1 22:36, 1 February 2007 (CET)

Weapons are disabled during sprinting, that includes all weapon functions, and it doesn't make much sense to switch firing modes while sprinting anyway. --Big Dawg KS 01:14, 2 February 2007 (CET)