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://bugs.armed-assault.net/view_all_bug_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)

OK. So what now? Shall we close the list here, and replace current content of the page with a link to the bug tracker and instructions page {other options are returning to using the Wiki page, or using both) --Suma 11:08, 21 February 2007 (CET)

My biased opinion ;) .. keep the BTS (close this list). There about 20 new registered people in the last week and people seem to have adoped it. There are 49 active users. --Boecko 11:24, 21 February 2007 (CET)

Question is whom do you ask? The community is pretty tiny atm. I personally can only work with a BTS, I had even problems to find your question in this looooooong list. What I can see is that more & more guys with scripting knowledge dropping TTs in the BTS so it seems to be accepted.--INNOCENT&CLUELESS 12:01, 21 February 2007 (CET)

I confirm - bug-tracker is much more comfortable then biki --bdfy

Same for me. I saw some comments on how complicated it was, but for me it's way easier to find what has already been reported, and to report something. Has well has having comments and dev feedback. --Whisper 14:22, 21 February 2007 (CET)

Definitely for closing the Wiki page, and forwarding any bug reports to the BTS. We seem to have just as many contributors/reporters there as we did on the Wiki. So it seems that people are already getting the hang of it.

What about the "wishlist" and the "bug or feature" page though? Should they be integrated into the BTS as well? --Kronzky 17:04, 21 February 2007 (CET)

Feature requests/change requests are in, but hoz closed TT with the reason "more a wish". Hence boecko created a new project called "ArmA features" and I moved the related TT there. The project was private to avoid confusion, I made it now public. The problem is that until now we did not discussed really the TT flow and responsibilities nor agreed on. So if we could agree that the SEVERITY "feature" means that it is not a bug we could use the project "Armed Assault" as usual and I could move the TTs back. We have anyway time since I guess that BI is so busy that they are not really open for resource consuming feature requests for the next weeks. I opened a TT in the project "mantis bts" where we could discuss the treatment of feature requests and close it if we come to an agreement http://bugs.armed-assault.net/view.php?id=1992 .--INNOCENT&CLUELESS 10:28, 22 February 2007 (CET)

Since it seems that we're way past the "point of no return" regarding the BTS system, I've updated the bug page now.

Once we've decided on how to handle requests and bug/feature determinations we should update that paragraph as well. --Kronzky 17:13, 22 February 2007 (CET)

Instructions

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?

I have started an instruction page with a bunch of screenshots already.
If somebody else has the time to put some "meat" into the article, that would be nice, as I'm a bit tight on time right now. Thanks! --Kronzky 04:32, 16 February 2007 (CET)

Nice startup. I'll try to contribute, when i have the time. --Boecko 12:47, 16 February 2007 (CET)

Participation

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)

URL update

The official URL for the BTS is now http://bugs.armed-assault.net. Bye --Boecko 21:27, 15 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)

To clarify 1, my point is not that people will be unable to learn, it is that they will be [i]unwilling[/i] to learn. Reference this topic for examples of people who are hesitant to learn how to contribute to the biki. The point there is that people are already having to learn very rudimentary wiki markup in order to contribute to the biki. Fastening on this other appendage adds complexity and more learning, and in my experience, community members can be quite lazy. Moreover, we have a number of people who are already learning wiki markup in order to contribute on other pages. They could use that knowledge to contribute here, and the people who learn some wiki markup in order to contribute on the buglist then have the skills to make other contributions to other areas of the biki.

To clarify 2, I'm not saying that programmers will see an added benefit to the BTS. I simply do not see what benefit there could possibly be. You find a bug that has been solved, you mark it as solved no matter what you are using to track them. This could be accomplished quite adequately with a word processor. I'm not saying that the BTS itself is too complicated for people to use, it is that it adds too much complexity to what is essentially a list of items, NOT a dynamic bug tracking environment. Programmers who are familiar with a BTS will undoubtedly see them as useful tools- indespensible tools for tracking bugs between multiple programmers seeking to ameliorate those problems. This is not what we are doing here, though. We are maintaining a list of problems for someone to glance at now and again. Noone here is fixing anything. I've been maintaining the list for some weeks and I must say that I find the wiki perfectly adequate. --Plaintiff1 11:20, 15 February 2007 (CET)

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)