Bug List – ArmA: Armed Assault Talk

From Bohemia Interactive Community
Jump to navigation Jump to search
No edit summary
m (Text replacement - "\[ *((ftp|http)s?:\/\/[^ ]+)([^{])=([^}])([^ ]+)" to "[$1$3{{=}}$4$5")
 
(93 intermediate revisions by 20 users not shown)
Line 1: Line 1:
==Introduction==
==Bug Tracking System==


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.
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. --[[User:Suma|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). --[[User:Ceeeb|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. --[[User:Suma|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 )  --[[User:Bdfy|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. --[[User:Boecko|Boecko]]
:::: On the other hand, we can discuss the initial access right of users. --[[User:Boecko|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? [[User:Hoz|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. --[[User:Boecko|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.--[[User:WGL.Q|WGL.Q]] 20:28, 14 February 2007 (CET)
:::Now i see - after several reports i became and updater and got edit option.--[[User:Bdfy|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 --[[User:Suma|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) --[[User:Suma|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. --[[User:Boecko|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.--[[User:INNOCENT&CLUELESS|INNOCENT&CLUELESS]] 12:01, 21 February 2007 (CET)
::: I confirm - bug-tracker is much more comfortable then biki --[[User:Bdfy|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. --[[User:Whisper|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? --[[User:Kronzky|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 .--[[User:INNOCENT&CLUELESS|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. --[[User:Kronzky|Kronzky]] 17:13, 22 February 2007 (CET)




=== 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). --[[User:Plaintiff1|Plaintiff1]] 01:38, 15 February 2007 (CET)


==Defining Priority==
: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.--[[User:Plaintiff1|Plaintiff1]] 01:52, 15 February 2007 (CET)


{{Important| '''Bug priorities'''
: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).--[[User:Plaintiff1|Plaintiff1]] 01:52, 15 February 2007 (CET) 


To make it easier for BI people to see important bugs, we introduced bug priority templates. Add new bugs with priority 0. Only [[User:BigDawgKS|BigDawgKS]], [[User:Sniperwolf572|Sniperwolf572]], [[User:Plaintiff1|Plaintiff1]], the BI staff, and the [[Bohemia_Interactive_Community:Administrators|wiki sysops]] are allowed to set priorities to values higher than 0.}}
: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.--[[User:Plaintiff1|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.--[[User:Plaintiff1|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. --[[User:Suma|Suma]] 09:11, 15 February 2007 (CET)
::: I switched on the simple bug report in mantis (i disabled it before).  Try it --[[User:Boecko|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 --[[User:INNOCENT&CLUELESS|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 [http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s{{=}}d97916afb30e88124d4105382c57c642;act{{=}}ST;f=71;t=57886;st=15 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.  --[[User:Plaintiff1|Plaintiff1]] 11:20, 15 February 2007 (CET)
 
::1 seems to me to be a dead-end argument.
Actually, the ability to use the BT builds upon knowledge that has been built through regular websurfing, and little else.  In other words, i can't see this as an argument to keep the biki page.
 
::Point 2 - the BT will allow automatically mailing the creator of the TT, as well as any others who has set themselves as interested in a bug, to say that we need more information, to say that this has been solved, etc. We have the ability to pretty much discuss the entire bug. "Adding ones 2c worth" is easier than with a wiki.
 
::One last detail - It's true that the BT can easily take some more manpower than the wiki, but we're on it already. The wiki may be ''adequate''... But this is probably better. --[[User:MaHuJa|MaHuJa]] 15:46, 6 March 2007 (CET)
 
== Defining Priority ==
 
{{Feature|important| '''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 [[User:BigDawgKS|BigDawgKS]], [[User:Plaintiff1|Plaintiff1]], the BI staff, and the [[Bohemia_Interactive_Community:Administrators|wiki sysops]] are allowed to set priorities to values higher than 0.}}
 
{{Feature|important| '''BTS - Definitions'''
 
We need to adjust these levels to the severity options in the new BTS!}}




How does one define a '''priority'''?  
How does one define a '''priority'''?  


'''Priority 1'''
'''Priority immediate'''
*Any issue that causes a CTD (crash to desktop)
*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 the game from loading.
*Any issue that prevents installation of a patch
*Any issue that prevents installation of a patch
Line 21: Line 78:




'''Priority 2'''
'''Priority urgent'''
*Issues that prevent MP game play
*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
*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)
*Issue that prevent the operation of a vehicle/unit/object as designed. (can't get in vehicle, helicopter moves incorrectly)
Line 29: Line 87:




'''Priority 3'''
'''Priority high'''
*Annoying behavior, such as Repeated voice command.
*Annoying behavior, such as Repeated voice command.
*Sounds that aren't working as they were designed.
*Sounds that aren't working as they were designed.
Line 38: Line 96:




'''Priority 4'''
'''Priority normal'''
*Any issue that causes an in game error (missing paa, missing name)
*Any issue that causes an in game error (missing paa, missing name)
*Graphical Nuisances (missing textures)
*Graphical Nuisances (missing textures)
Line 44: Line 102:




'''Priority 5'''
'''Priority low'''
*Missing sounds which maybe were never intended.
*Missing sounds which maybe were never intended.
*Spelling errors
*Spelling errors
*Minor mission issues that don't affect the game play
*Minor mission issues that don't affect the game play
==Talk about the Priorities==
==Move the Bug List?==
Since the bug list entries are constantly cluttering up the edit history (and probably will continue to do so for a while), how about we move it to a different name space (e.g. [[Help:Contents|Help]]). For the normal users it wouldn't make much of a difference, but for those that use the log, the bug list edits (and probably the wish list as well) would then only show up if you select the "Help" name space in the drop-down menu.<br>How about it? --[[User:Kronzky|Kronzky]] 05:49, 4 January 2007 (CET)
I know what you mean but I'm not in favor of changing the name space as many people link here already. [[User:Hoz|hoz]]
Well, we could keep this page, but forward it to the new Bug List page. That way they can keep their links, and we can keep the log clean. --[[User:Kronzky|Kronzky]] 23:26, 4 January 2007 (CET)
:OK, both lists (bugs & wishes) have been moved to the Help: namespace.<br>
:Which means that you can now select [http://community.bistudio.com/wiki?title=Special%3ARecentchanges&namespace=0 "Main"] as the namespace in the "Recent Changes" list, and you will not see entries for either of those pages anymore. (By default *all* namespaces will still be listed.) --[[User:Kronzky|Kronzky]] 05:44, 8 January 2007 (CET)
==Buglist Preamble==
I think it would be a good idea to add something about keeping your ArmA up to date when submitting bugs to the introduction section.  Something for the demo users could look something like:
It would be a great help to us if you would keep your arma builds up to date when submitting bugs using the demo!  This way, if you are reporting bugs, we are sure that the bugs you are reporting haven't already been fixed in the newest build.  The newest build is available here: [http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=8852d4cb2e9176a93a8f9f24af6d493c;act=ST;f=72;t=56170;st=0;&#entry989050].  Thanks in advance. --[[User:Plaintiff1|Plaintiff1]] 00:17, 14 January 2007 (CET)
==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?  --[[User:Plaintiff1|Plaintiff1]] 00:17, 14 January 2007 (CET)
===Older Entries===
Bug priority|3|When in seagull mode the mission notebook is not accessible in the map screen. [1.02] --[[User:Kronzky|Kronzky]] 08:16, 20 December 2006 (CET)
:This is actually already prevalent in OFP [[User:Str1ker|Str1ker]]
:This seems like a lack of feature or a feature that annoys you rather than a bug.  Consider putting it in the wishlist. --[[User:Plaintiff1|Plaintiff1]] 08:44, 16 January 2007 (CET)
*Bug priority 3? To me it doesn't seem to fit that category because it doesn't get in the way of gameplay.  Moreover, it's likely a feature, misguided or not, to make it harder to have seagul ghost-recon, as it were. --[[User:Plaintiff1|Plaintiff1]] 08:44, 16 January 2007 (CET)
*I have tagged the entries for the sound information bug and some others as remedied as of build 5116.  To find them, simply search the page for the word 'remedied'.  I have confirmed that this bug no longer exists for the demo, but I have no information regarding the retail version.  --[[User:Plaintiff1|Plaintiff1]] 01:21, 13 January 2007 (CET)
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] -[[User:Desertfox|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. --[[User:RyanKaplan|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.  --[[User:Alpha-kilo|Alpha-kilo]] 09:55, 4 January 2007 (CET)
::::Sounds like a sensible solution to a non-existant problem. --[[User:Plaintiff1|Plaintiff1]] 08:23, 12 January 2007 (CET)
:::::This is a preference and not a bug.  I think we should remove it. --[[User:Plaintiff1|Plaintiff1]] 08:23, 12 January 2007 (CET)
AH1 Cobra able to do loops? imho impossible in real life. Would be ok for the littlebird though. (if there´s an enhancement in heli physics either make it like BF2 or just like OFP) ''[1.02]'' [[User:Burns|burns]] 01:21, 16 December 2006 (CET)
:This also applies to the Blackhawk, even with <nowiki>V0=0</nowiki>.
([http://www.youtube.com/watch?v=AFdNo5yL33M video]) -[[User:Dirk|d034rk]] 20:22, 23 December 2006 (CET)
* This is an opinion and not bug.  Many helicopters can do loops and barrel rolls.  In the case of helicopters with fully articulated rotors, this is dangerous because the rotors might bend so far as to clip other parts of the helicopter.  Until this is confirmed as to be impossible I suggest we strike this bug off of the list --[[User:Plaintiff1|Plaintiff1]]
Ok, I moved these here because there's already a 50 page thread on the forum about this and the flight model has already been brought to BI's attention. If they're cleaned up and perhaps merged, and can qualify as a bug, then they can be resubmitted. --[[User:BigDawgKS|Big Dawg KS]] 22:23, 21 December 2006 (CET)
* Rudder controls for AV-8B lose noticeable effect in too slow speeds. Consider this: stall speed for the plane seems to be around 200 (you can barely keep it's nose up). At this speed you should be able to use rudder to adjust the plane heading (for example aligning for runway when landing). Also rudder is used for aiming (to some extent) when firing the minigun. At the moment you can't turn the heading enough with pedals to aid landing or attacking with minigun. Another point; when you bank hard (close to 90deg left or right) you should be able to keep the nose of aircraft from falling with rudder. This issue will probably apply to other fast moving winged aircraft as well. (tested with joystick with rudder axis). 21 Dec 2006. [v 1.00 - 1.02] -[[User:Tuusita|Tuusita]]
: Can we call this a bug? I'm not sure if it's actually a bug or your opinion (wish). --[[User:BigDawgKS|Big Dawg KS]]
::I would call it a physics problem.  Rudder physics on all aircraft, fixed and rotary wing, are wrong.<br>
::--[[User:ColonelSandersLite|ColonelSandersLite]]
::: Still, if it's a non-feature and not technically a bug, it doesn't belong here. We all know there is serious debate about the current flight model in ArmA, I don't think we need to continue it here. --[[User:BigDawgKS|Big Dawg KS]] 22:23, 21 December 2006 (CET)
* Controlling AV-8B throttle with joystick throttle axis is difficult. When you set throttle axis to near center it seems there is "an autothrottle" that increases throttle when nose is pointing up (above horizon) and decreases throttle when nose is pointing down (below horizon). This "autothrottle" is not able to hold speed when you are banking and your nose points slightly down; it will decrease throttle even if your speed is slowing down since your nose points below horizon. Suggested fix: 1)(preferred)control aircraft throttle directly (when throttle axis is designated in Controls) OR 2)make "autothrottle" try to hold the speed (the speed when throttle axis was centered). 21 Dec 2006.  -[[User:Tuusita|Tuusita]]
: Again, I think this is more of a wish than a bug, unless it is a serious issue that makes it unplayable. There's been a lot of dispute about the flight model and there are many conflicting opinions as to how serious a problem it is, if one at all. --[[User:BigDawgKS|Big Dawg KS]]
* Got the full game and cannot start the game. When i click on the game icon , 10 small scare appear and when 8 of the 10 scare is checked, window error message appear and stop the game lauching. What i should do?  -[[User:Bob819|Bob819]]
:Go to BI forums [http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=042ba19395d78a832260383a089eb51e;act=SF;f=68 troubleshooting section], this is not troubleshooting but a bug list, you are also not listing your system specs and the actual content of the error message. --[[User:Sniperwolf572|Sniperwolf572]] 09:24, 25 December 2006 (CET)
* Version is 1.02 German, all drivers are up to date in fact it is a new computer. When running the game it will stop after the first screen with the small helo comes up and the game attempts to load, it will then freeze and go to a microsoft error report which I have submitted. I have tried reinstalling, running 1.0, 1.02, 1.02 with lang patch, all to no avail. The game was running fine yesterday.
:Go to BI forums [http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?s=042ba19395d78a832260383a089eb51e;act=SF;f=68 troubleshooting section], you are also not listing your system specs. I encountered this only when I installed addons with faulty config. --[[User:Sniperwolf572|Sniperwolf572]] 09:31, 25 December 2006 (CET)
* Players can perform as many TKs as they want - no kick.
We just had two guys (James: 1855235 and Noli: 5173253) walking all crowded public servers to TK at spawn. Once they got into tank, they setup behind spawn and kill everyone. Once one server is cleared, they switch to another one.
If its not a bug - then at least its a *big* gap for exploits.
So unless this is fixed, one or two "bad" guys can ruin the fun for some hundreds. Until then, dont expect a widespread acceptance of the public servers/ArmA in general.
''Solution:'' After a certain threshold (5 kills?), the TK-ratio is measured... if it is > 0.5 -> kick with text to the player. If it was not on purpose - nice, he learned some lesson. If it was on purpose - well, it was deserved. [[User:Weasel75|Weasel75]] 04:00, 27 December 2006 (CET)
: Non-feature/wish. --[[User:BigDawgKS|Big Dawg KS]] 19:02, 27 December 2006 (CET)
* Rifle-sound sometimes disappears. This seems to be related to have the weapon close to or in? a wall. That happened to me with G-36 twice online, while I am pretty sure it happened to others (so the bug is not just on the client) too - I stood right besides them, no firing-sounds. [[User:Weasel75|Weasel75]] 06:36, 28 December 2006 (CET)
: Already reported. --[[User:BigDawgKS|Big Dawg KS]] 03:08, 2 January 2007 (CET)
* When player is under water for too long there doesn't seem to be a sound to indicate you are drowning. Or it maybe that the player position in water is not calculated from the position of the player's head. Then again maybe there is no sound.[1.02] --[[User:Rick0Shay|Rick0Shay]]
: Non-feature/wish. --[[User:BigDawgKS|Big Dawg KS]] 03:08, 2 January 2007 (CET)
* Harrier is very difficult to get into air - takes almost full runway length to take off with flaps down or up. No vertical take off/landing. Limited sensitivity in Y axis in air - tried slider etc. Using MS sidewinder with rudder and throttle. Works fine in LockOn-FC and other flight sims. Seems unplayable at present. [1.02] [[User:Rick0Shay|Rick0Shay]]
: Non-feature/wish. --[[User:BigDawgKS|Big Dawg KS]] 03:38, 2 January 2007 (CET)
* Harrier on ground (runway) allows multiple ejects. [1.02] --[[User:Rick0Shay|Rick0Shay]]
: Non-feature/wish. --[[User:BigDawgKS|Big Dawg KS]] 03:38, 2 January 2007 (CET)
:: Are you sure about that? It's about as realistic as throwing hand grenades and then pick them up for reuse. -[[User:Xpz|Xpz]]
::: I'm sure, reusing a hand grenade is equally bogus in terms of gameplay as it is realism, reusing the ejection system on an aircraft isn't. Besides the game doesn't even simulate ejector seats (not by default at least), if it did then you could argue that this is a bug, otherwise you're talking about a bug in a feature that doesn't even exist. --[[User:BigDawgKS|Big Dawg KS]]
* When parachuting user controls don't seem to have any effect on the flight direction and speed of the decent. This might be a bug or a feature I'm not sure. since it detracts from realism (the ultimate game/sim objective) I would say its a bug and a non feature - but hey that's just me. Its also interesting to note that this basic ability is present in quite a few other combat games that have been around for over 3 years. [v1.02] [[User:Rick0Shay|Rick0Shay]]
: Non-feature. Also certain parachutes are intended not to be steerable (at least not easily), such as during large scale jumps to prevent collision. --[[User:BigDawgKS|Big Dawg KS]] 21:29, 3 January 2007 (CET)
* "Scrolling in the map screen is very choppy or don't work at all. This applies to up/down, not left/right. [v1.02]"
: Priority 5? This bug is really irritating and destroys the gameplay. Imagine planning an assault and not being able to scroll the map. It's a disaster. -[[User:Xpz|Xpz]]
:: Provide a video or more detailed description and it can be better assessed. --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
::: The bug report is updated on the main page. Here's the video: [http://www.unionen.se/xphaze/mapbug.avi Video (xvid)] --[[User:Xpz|Xpz]]
* player ejects from vehicle when destroyed and player ejects from soft vehicles when caped (killed without destroying vehicle armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: This is necessary to ensure the player respawns, it was a problem in OFP that was fixed by ejecting the players. So I'd say it's more of a bug fix, perhaps someone has a different opinion? --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* when change weapon to full automatic the use binoculars then change back to weapon it is automatically set back to semi auto armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Non-feature (also it's not like you can't instantly switch it back). --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* commander seat in tank cant command, or very hard to, revert back to OFP mothod of commanding, and why can the driver issue orders armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Non-feature/wish. --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* weapon kit consistiong of AT launcher, M4A1 and hangun, go for a swim and when you get out of the water you only have the handgun the AT launcher and M4 dissapears armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Feature (weapons are dropped to allow you to swim). --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* hit a tree dead on with sabort blows the tree down a heat round does not armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Non-feature I suppose, since HEAT rounds don't do as much damage as Sabots, try 2 or 3. --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* cant "drop ladder" when started climbing from the base of ladder armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: You can indeed drop off the ladder if you start from the base, at least on the really tall ones. --[[User:BigDawgKS|Big Dawg KS]] 00:40, 6 January 2007 (CET)
* at far distances if BRDM is spotted ai will keep shooting at it, trying to get its attention ? then BRDM turns and kills them all (rule no1 don't piss the tank off) armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: What part of that is a bug? --[[User:BigDawgKS|Big Dawg KS]] 00:51, 6 January 2007 (CET)
* havent been able to reproduce bug, ai equiped handgun in prone possition then got stuck, was unable to move or stand up, all he could do was pivot on the spot, he could aknoledge orders but couldent carry them out armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Cannont be reproduced, as he says. --[[User:BigDawgKS|Big Dawg KS]] 00:51, 6 January 2007 (CET)
* ai donot respond to grenades when they land next to them armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Non-feature. --[[User:BigDawgKS|Big Dawg KS]] 00:51, 6 January 2007 (CET)
* ai do nothing when they find a dead body, can players hide bodies ? armademo ver 1.3.0.5110 -[[User:NipWup|NipWup]]
: Non-feature. --[[User:BigDawgKS|Big Dawg KS]] 00:51, 6 January 2007 (CET)
* Cannot assign team members to smaller teams no more.  The assign menu item (item 9) is missing.[v1.02] --[[User:Aprecious|Aprecious]]
: It can still be done, just not from the standard command menu. This would also be a non-feature, not a bug. --[[User:BigDawgKS|Big Dawg KS]] 00:59, 6 January 2007 (CET)
* AI is being swamped with move commands and other commands ''every second''. You can ''hear'' this happening if you got your headset on. In the distance you hear the leaders giving new orders per second. I believe this results in the AI being swamped with commands not being able to handle, calculate the informations provided. This could be one of the reasons for all the AI behaviour being reported. Just a overflow of commands. I also don't think there is a need to hear the AI commands. ''I removed this again. Turns out that this was caused by missions using Kronzky's Urban Patrol Script'' -[[User:SniperAndy|SniperAndy]]
*I died once as I sprinted on a corner roof, trying to jump away (happened once) - [[User:Lou Montana|Lou Montana]] / Demo
:No repro steps, likely fell off the roof. removing..[[User:Hoz|hoz]]
* There is some bad behaviour of US Recon Soldier in Front of BMP.Have a look at ScreenShot:
[http://img149.imageshack.us/img149/7940/arma2007010701570525ov5.png][v1.02] - [[User:berndsattler|berndsattler]]
:Isn't it the target designator? The model is missing and It's been already mentioned. [[User:Funnyguy1|Funnyguy1]] 20:18, 7 January 2007 (CET)
When swimming, returning to land will randomly make all your equipment off, sometimes it will, sometimes it won't - [[User:Lou Montana|Lou Montana]] / Demo
: This is based on time in the water and how deep, as per design I beleive. [[User:Hoz|hoz]]
==Newer Entries==
*No way to control parachute. It seems randon. This is a feature that's been available in BF for years ! :--[[User:Major Latency|Major Latency]]
: Then make a wish in the wishlist. [[User:Hoz|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 [http://koti.mbnet.fi/celery/pics/arma_nv1.jpg picture] [v1.02]  --[[User:Celery|Celery]]
: Does it stay like this? It takes some time to accomodate to the bright image [[User:Scruffy|Scruffy]] 22:37, 5 January 2007 (CET)
::Removed, I think this is by design, it takes time for the NV to adjust. [[User:Hoz|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. [[User:Hoz|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 -[[User:TheOne|TheOne]]
: Not a bug as per design, as mentioned by marek in the Demo TS thread. [[User:Hoz|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. --[[User:SniperAndy|SniperAndy]]
: More of a wish then a bug. I think this is by design to keep the games moving, annoying as it is.[[User:Hoz|hoz]]
*Should there be a different explosion effect when tanks fire into the ocean/water -[[User:NipWup|NipWup]]
: Wish/request [[User:Hoz|hoz]]
*Wood stacks looking strange if destroyed [http://www.surfacezero.com/uploads/burns/ARMA_bug4.jpg pic] ''[1.02]'' [[User:Burns|burns]] 02:07, 16 December 2006 (CET)
:This might also be a design decision, as if wood stacks get unbalanced and collapse. --[[User:Sniperwolf572|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. [[User:Scruffy|Scruffy]] 22:40, 5 January 2007 (CET)
::: As per design, not really a bug, make a wish for a better damaged model.[[User:Hoz|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] -[[User:NipWup|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. [[User:Hoz|hoz]]
<div style="background:#e0e0ff;border:1px solid #cfcfff;padding:1em;padding-top:0.5em;padding-bottom:0.5em; color:black;">
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) -[[User:NipWup|NipWup]]
:I believe this is a feature of the HDR sound engine. --[[User:Plaintiff1|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. --[[User:Plaintiff1|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. -[[User:NipWup|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.  --[[User:Plaintiff1|Plaintiff1]] 05:10, 11 January 2007 (CET)
</div>
<div style="background:#cdcdf9;border:1px solid #cfcfff;padding:1em;padding-top:0.5em;padding-bottom:0.5em; color:black;">
http://www.flashpoint1985.com/cgi-bin/ikonboard311/ikonboard.cgi?act=ST;f=63;t=49299
Hi Tech
* HDR (High Definition Range) rendering is implemented to allow good dynamic range of the image in various daytime conditions.
* ''Similar system to HDR is also implemented for sound so you can hear well low volume sounds in quite areas and also large explosions during combat.''
* AI can do everything that you can do. AI can also be mixed in with humans when playing multiplayer (as bots and opponents).
</div>
<div style="background:#cdcdf9;border:1px solid #cfcfff;padding:1em;padding-top:0.5em;padding-bottom:0.5em; color:black;">
http://redorchestragame.com/forum/showthread.php?t=10160&page=22
I found out that the sounds work quite well when you deactivate "hardware acceleration" in the game options, but enable "EAX"...
while the weapons don't have echoes, these things are eceptionally well done:
* Helicopters and tanks roar at a frightening level and realistically can be heard from kilometers away.
* Gunshots sound different dipending on whether they shoot at your direction or away from you.
* There is a clearly audible snap (allthough not as pronounced as dslyecxi would want them, I suppose ^^) when bullets pass you.
* The High Dynamic Range Audio works even more impressive than in OFP: loud sound make less loud sounds even more silent for a short period of time.
* Sound shadows: when an object/building/tree is between you and the source of the sound, the sound is muffled.
</div>
--[[User:Plaintiff1|Plaintiff1]] 05:10, 11 January 2007 (CET)
===Realism Bugs===
I would like to call into question the validity of the realism bug category.  I simply do not see how this category can exist without turning into a wishlist.  Observations such as vehicles burning underwater are valid imersion concerns- however, this is not a gameplay or stability issue:  It is a lack of feature which belongs on the wishlist.  Asking for a rethinking of the armour values algorythmns or assignments are also wishlist material.  Things that BIS *INTENDED* to happen are not bugs, and those that were left out due to engine constraints are also not bugs- they are things BIS intended not to happen due to performance or other considerations.  To be honest, we need a copy of the design document in order to ascertain what a bug is.  In absence of that, I think we can safely knock off the reaslism bug category, as there are more much more pressing matters.
I should probably say that it's not that realism problems aren't bugs, however, ALL bugs that aren't stability related could be said to be realism bugs, and realism may or may not have been the ultimate goal in most areas of the gameplay scope.  Furthermore, game balancing issues which may fly directly in the fact of realism are *features*, the direct opposite of bugs.
This list will not be completely controllable, as anyone can write on it, but I think that with careful structuring of form, users can be coaxed in the right direction.  If this is a desirable state of being for this wiki, that category completely flies in the face of it.  --[[User:Plaintiff1|Plaintiff1]]
:: Well, as we don't have access to any design documents we have to guess what a bug really is. I think we all can agree on using simple common sense. If it is implemented in OFP, it certainly should be in ArmA. -[[User:Xpz|Xpz]]
::: I partially agree.  Common sense would dictate that if there is a glaring stability or gameplay issue, that it is probably a bug, so common sense is one tool we can use to judge bugs.  However, there are a lot of ways in which ArmA and OFP are different, so I don't think that they should be compared for this purpose.  This doesn't, however, address the validity of the 'realism bug' category. --[[User:Plaintiff1|Plaintiff1]]
:::: It would be nice to have more information on what BIS intended (and did not) and what they consider bugs. --[[User:BigDawgKS|Big Dawg KS]] 00:57, 6 January 2007 (CET)
:::::We can ask them for it but most likely we'll just have to put a system in place that makes the bug list make more sense.  For instance 'You can't go prone on hills'.  Is that a really a realism issue or is it a control issue?  And what does 'can't go prone on hills mean?  I don't think it's an issue where BIS neglected to put in that feature, throwing realism to the wind.  None of those bugs in the realism issue bug section make any sense as realism bugs.  I don't think that realism can ever be the best possible category to put a bug in.  I think that broken physics (if they are truly broken as opposed to lacking in detail) can go in the physics category, control problems (like not being able to do something in some situations-  like go prone- but you can in others can go in a control bugs category, and bugs that are not bugs can go in a feature request wiki page.  Further weapon issues like excessive/ not enough recoil in a game breaking way can go under weapon issues, while weapon tuning can go on the wishlist. --[[User:Plaintiff1|Plaintiff1]]
* 1: can't move while reloading or fireing full automatic omg !! i can understand it while lieing down, 2: unarmed characters cant neel, 3: same explosion effect heat and sabart ?, 4: chopper feul runs down too fast when dammaged a little bit + engine stops arfter too litle damage, implement control dificulties when damaged ?, no engine smoke when damaged, being able to crash land a plane or chopper and survive, 5: being able to controll a parachute, 6: no recoil or vibration or any fireing effect from vehicle mounted guns (and no muzzle flash from Humve), and some dont have the belt fed effect, reload actions would be nice too, 7: Rifle shells eject from pistols, 8: cant pivot while reloading at or aa weapons 9: bullet proof windows on some buildings, 10: no M24 bolt action ?, 11: smoke from smoke grenade usless on steep slopes, smoke disapears into side of mountain, 12: UH60 miniguns. *cough*, firing vibration effects, and can you make it spin any faster (wind up to speed), 13: need light emmiting glowing tracers from weapons not green and red lines, and faint intermitant tracers from small arms fire, 14: detachable and retachable mods to weapons on the field, 15: at night, burning vehicles abruptly stop emmiting full light when burning stops, 16: shell ejection from weapons should fly much further, 17: first person view proper reload actions and weapon movement, 18: characters have to compleat action before dieing, 19: it wouldve been nice to have ragdoll effect, grenades,tanks or any explosive cant sent a person flying, + vehicle breakup when expload, sending deblies averywhere, 19: dismemberment option (character decapatation) nothing much happends when you hit a soldier square on with a tank shell ?, 20:is it possible to add heat haze effect on the deasert plains during the day and exaust from choppers, jets and tanks -[[User:NipWup|NipWup]]
* 1: vehicles can burn on fire underwater, 2: handguns fire accuratly over 600m, 3: no internal tank instraments and can't veiw inside tank body, 4: it would look more real if the sun glare/beam effect showed and continue through the gaps of tree leaves -[[User:NipWup|NipWup]]
: These were removed because they are mostly non-features/wishes. You could be right about the realism section. Maybe we should put an important notice there explaining what is actually a realism '''bug''', or maybe even removed altogether. --[[User:BigDawgKS|Big Dawg KS]] 01:15, 6 January 2007 (CET)
:: Just to chime in here. I would be ok with removing the Realism section. Just be sure to move the decent reports to the appropriate section. [[User:Hoz|hoz]]
* AI walking through walls reported by bt_1900 and Lujon
And isn't this sort of an engine limitation? AI can walk through everything since OFP, the LODs just tell them not to do it most of the time. [[User:Scruffy|Scruffy]] 22:30, 5 January 2007 (CET)
== Demo bugs ==
* ARMA demo [1.3.0.5109] performance issues where menus and functions lag performance, dropping frame rates to 0 or producing connection lag. I’m not sure which. Switching between Map and 1st person takes a few seconds, makes it very hard to navigate without getting killed.
:Getting in and out of vehicles or switching positions sometimes takes a few seconds.
:Overall performance setting: very low
:My stats:<br>
:Amd Athlon 64 x2 4800 (I know its not optimized for dule core)
:NVidia Quadro FX 3450/4000 x1 [no sli]
:Mem 2 gig
:Sb Audigy X-fi
:Connnection : Cable
* Starting the game with Crossfire enabled causes the game not to start.  The ArmA mouse cursor loads to a black screen.  Esc allows you to exit the program.  Windows claims that 'memory could not be written'.  The RPT file alludes to a driver problem. RPT excerpt available on the talk page. [Demo v1.03] --[[User:Plaintiff1|Plaintiff1]] 10:43, Dec. 27th
* Server crashes every time when CTI (Capture The Island) mode is started. [Demo 1.03 build 5110] - [[User:Osmo|Osmo]]

Latest revision as of 18:27, 28 April 2023

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)


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)
1 seems to me to be a dead-end argument.

Actually, the ability to use the BT builds upon knowledge that has been built through regular websurfing, and little else. In other words, i can't see this as an argument to keep the biki page.

Point 2 - the BT will allow automatically mailing the creator of the TT, as well as any others who has set themselves as interested in a bug, to say that we need more information, to say that this has been solved, etc. We have the ability to pretty much discuss the entire bug. "Adding ones 2c worth" is easier than with a wiki.
One last detail - It's true that the BT can easily take some more manpower than the wiki, but we're on it already. The wiki may be adequate... But this is probably better. --MaHuJa 15:46, 6 March 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.
⚠
BTS - Definitions We need to adjust these levels to the severity options in the new BTS!


How does one define a priority?

Priority immediate

  • 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 urgent

  • 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 high

  • 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 normal

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


Priority low

  • Missing sounds which maybe were never intended.
  • Spelling errors
  • Minor mission issues that don't affect the game play
Retrieved from "https://community.bistudio.com/wiki?title=Talk:ArmA:_Armed_Assault:_Bug_List&oldid=340027"