ArmA: Bugs List-version-1.01.5094 – Talk

From Bohemia Interactive Community
Revision as of 22:27, 14 December 2006 by Innocent&clueless (talk | contribs)
Jump to navigation Jump to search

Discussion: Maintaining This List

How do we deal with this list after the next patch is available? Topic is up for discussion, I think we have two options.

  • Option 1. Delete the list and start fresh, in some cases bugs may have been addressed but aren't listed in the changelog and getting everyone to retest their bugs maybe a monumental task. If the bug is important, submitter will resubmit it the new list.
  • Option 2. Allow users to recheck their bugs, and scribe out the bug. This has its downside as many people might be lazy in this dept. therefore bugs never being cleaned up.

hoz 20:14, 6 December 2006 (CET)


Should the old reports be deleted? --Serclaes 00:01, 3 December 2006 (CET)

Which old reports? Things that are fixed meanwhile? Yes ;) --raedor 09:15, 3 December 2006 (CET)
Please use <del>deleted material</del> syntax instead of actually removing them. Example:
Some bug reported in first release [fixed in 1.xx.xxx] --Vic 00:27, 5 December 2006 (CET)
Only if it is fixed, not if it has nothing to do with bugs. --raedor 00:50, 5 December 2006 (CET)
How do we know if it's fixed yet or not? I mean you could have posted something here but it may not have been fixed Oo --Serclaes 01:26, 5 December 2006 (CET)
The only source for knowing that can be History logs of patches, as you saw it for patch v1.01. --raedor 01:29, 5 December 2006 (CET)


What's a bug?

Somebody had asked a while ago, what exactly constitutes a bug - that's how this discussion below got started. Even though that original post has now been removed, the follow-up discussion might still be a good reference to have for the future, though.

Just because something is different in the game from how it is in reality doesn't make it a bug.
As it says in the quoted Wikipedia article: "A software bug is an error, flaw, mistake, failure, or fault in a computer program that prevents it from behaving as intended (e.g., producing an incorrect result)."
So - if the developers intended for pigs to fly in the game, it is quite irrelevant whether they do so in real life. It's still not a bug... ;) --Kronzky 00:27, 8 December 2006 (CET)

I know, all the more reason it shouldn't be in the bug list. Unfortunately, going through the list I see a lot of questionable bugs, some obviously not, and are rather non-features or even possible wishes. I think someone should go through the list and determine which ones qualify as bugs and which do not. It might also be good to use that oppertunity to find reports that aren't as useful as they could be, as some seem to contain little useful information (and aren't following the exemplified format). --Big Dawg KS 22:14, 8 December 2006 (CET)


Items Removed

Should we really keep this list?
After all, we're getting *lots* of inappropriate and useless bug reports (and it'll probably become even more in the future). We shouldn't have to file a "justification" or log for every removal of them. (Or, at least, have a dedicated page for removed bug reports, rather than cluttering this one.) --Kronzky 17:24, 13 December 2006 (CET)

I moved these topics here for deletion as they are pretty useless descriptions of bugs and are not signed but the editor. There fore we can't ask for clarification.hoz 00:34, 6 December 2006 (CET)

  • Accuracy on all weapons is way off. [1.01.5094]
    • What Weapons?
  • Some Weapons have no recoil. [1.01.5094]
    • What weapons?

- Isn't the accuracy related to the server.cfg and settings? "precisionFriendly=0.750000". So it would have to be seen if the accuracy is different if this is set to 1. Then it is no bug, is it. --SniperAndy

More questionable entries:

  • "we lost our primary gun when we swim about 30sec"
    • This is not a bug, it appears to be intentional (for realism purposes).
  • "when you shoot a AI (near 1 meter) with the M256 of M1A1, he doesn't died."
    • Using a sabot? If so, not a bug, sabots shouldn't have any splash damage.
  • "Possibility to turn off the integrated communication system that allows you to hear other players [1.01.5094]"
    • Is this a bug or a wish? --Big Dawg KS 23:38, 7 December 2006 (CET)
      • Its a wish. I haven't had time to go through the list much today. Hopefully tonite. hoz 22:11, 8 December 2006 (CET)
Ok, I'll move it to the wish list if you don't mind. --Big Dawg KS 22:25, 8 December 2006 (CET)
  • Under General: "Can't climb on the little rock or put an ai on(in the editor)...the AI is inside!" - What rock and how about setops the unit? --SniperAndy


  • Game did not start after install. tried the patch but got the same error message : "data file too short 'addons/weapons.pbo'." [1.01.5094]
    • This is more of an install problem. hoz
  • AI can't recognize any terrain in the city except the streets. The soldiers always walk around big places and don't use any stairs or so...

(wrong^^ / already seen AI´s using stairs and walking around upper levels twice) [1.01.5094] burns 19:44, 8 December 2006 (CET)

  • One cannot step over bodies laying on the ground (dead or alive) [1.00.5087]
    • Really a bug? Don't think so.
    • When I swim in the water weapon in hand, when I reach the shore all my equipment is lost. MrFreezeFR 14:01, 7 December 2006 (CET) [1.00.5087]

(loosing weapons in water isn´t a bug but a feature) burns 19:28, 8 December 2006 (CET)

  • As a seagull you cannot view the mission's notepad when looking at the map. [1.01.5094] --Kronzky 19:24, 5 December 2006 (CET)
    • Its also like this in Elite, I think its by design.hoz
      • ..besides, seagulls have been known to keep all mission details in their heads, as opposed to having notepads and whatnot.. ;o) --teaCup 22:35, 10 December 2006 (CET)
  • Getting stuck on bigger rocks [1.01.5094] burns 15:34, 5 December 2006 (CET)
    • Useless without picture/location.
  • we can't climb ladders into church
    • What church? What location?hoz
  • we lost our primary gun when we swim about 30sec.
    • Non bug as designed. hoz
  • When firing the west M249 MG in multiplayer and getting ammo from truck via the quick-ammo icon, your MG gets filled up with 4*30 rounds stanach magazines. [1.1.0.5094]
    • Not necessarily a bug as M249 can fire M16 Mags in real life.
  • .50 cal Bullets ricochet off Water [1.01.5094] burns 11:06, 6 December 2006 (CET)
    • I don't think that this is a bug. I have seen 7,62 x 51 mm bullets ricochet on water in Real Life (The time I was in the Army). --- [KSK-D]Arbaal 22:24, 6 December 2006
      • Indeed bullets can ricochet off of water. hoz
  • Weird LOD choices reported sometimes [1.00.5087]
  • Generaly more realistic sound all the weapons. Now there sound like toy-guns. Dec 10. 11:52
    • Moved to the wish list. --Big Dawg KS 22:35, 11 December 2006 (CET)

Marking Important/Critical Bugs

What about marking the most important or critical bugs, so that BI know what they can start to fix with. Otherwise I think they will get a collapse when they look at these huge list and this could prevent them from doing some suicide attempts --T_D 15:32, 10 December 2006 (CET)

I don't think this is feasible. I'm sure BI is prioritizing the bugs. I think we will wipe the list clean after the next patch and start fresh and moderate the list a little better. If the bug was important then it will be reported perhaps in better detail. hoz
Yes, we prioritize bugs for our own purpose, Still, it would be quite helpful for us to know what are bug priorities as perceived by the community. However, if this is to be helpful, community would need to be able to agree on a very small number of high-priority problems. If anyone can mark anything as important, I suppose very soon most reported problems would be marked as important. --Suma 14:59, 11 December 2006 (CET)

Bug tracking system?

Hi,

why don't you just take an real bug tracking system (BTS)?

  • It would be better than a wiki page
  • it's searchable and you could close duplicated things easily
  • you could make categories
  • it's state of the art

It would be great to see such a thing. I've made good experience with Mantis.

Thanks

Boecko 13:55, 11 December 2006 (CET)

Erm... this is a user-powered bug list. It's not exactly officially supported by BIS (or it wasn't when I started it), it was just a simple way to keep a (hopefully) comprehensive, unified and collaborative bug-list and hope the devs take these reports into account. I'm sure BIS uses a bug tracking tool internally, but as far as user reports go, I think what we do is already above what happens in other communities. --Vic 14:28, 11 December 2006 (CET)
That's right. It's pretty unusal to have something like that for other games. Sorry, i'm using it every day, so i'm used to it. Most opensource-projects use something similar. --Boecko 15:04, 11 December 2006 (CET)
Million of other projects were able to organize a BTS for such purpose - why not here the same? BI and the community desperately need to get more professional. Its about damn time to learn how to improve. Trac is the way to go! --WGL.Q 18:42, 11 December 2006 (CET)
I think it's time for a BTS! Trolls have started to use this page, which are already known in the official german ArmA forum.
It's awkward for the brave bug reporter!
1.There is no tracking ability (for single cases. not the whole page)
2. Clarifying things with a screenshot is a real pain a) link to an external webpage b) Imageupload via mediawiki
--Boecko 12:14, 13 December 2006 (CET)
I can image why BIS doesn't open their bug-tracking system to the public - it would just get flooded with wishlist items, and totally clutter the whole thing.
so? it's still better to maintain than an anarchy page like that. By the way .. SUN, Apple [1] [2], Microsoft (temp down) and Adobe are doing similar things. --Boecko 17:35, 13 December 2006 (CET)
It would probably be useful to have at least *read-access* to it, though. That way one could quickly check whether they're aware of a bug already, before wasting your time trying to pin it down the exact occurrence for the report here.
And even if they don't want every Joe Schmoe reading it, perhaps at least the sysops here should get read-access. That way they can compare bugs reported here with what's in the official BTS, and mark them "BIS-acknowledged" (or something like that). It would save players a lot of time (not having to track down every bug, if they know it's "official" already), and make them a lot more content (if they know BIS is aware of it, and will probably get to it sooner or later).--Kronzky 17:07, 13 December 2006 (CET)
While I agree a public bug tracking system would be a nice-to-have, this wiki is what we get. You can either bitch about it or work with what we have. Re: BI acknowledged bugs, do you want BI to spend time read and updating bugs or would you rather have them fixing them in a timely manner? I'm guessing you can't have both. As you can see I intend to move this bug list, and move in the new list once a new patch is released and I'm hoping others will help with moderating this list so that genuine bugs are can be clearly identified for BI. hoz 17:41, 13 December 2006 (CET)
...BI to spend time read and updating bugs or would you rather have them fixing them in a timely manner?.
How about an optimized workflow to fix bugs? I can image this page keeps one BI-employee busy to make sure that the internal BTS is kept in sync.
Most BTS have the ability to mark bugs public/private, it wouldn't be a big deal. This page is like developing with notepad. --Boecko 17:58, 13 December 2006 (CET)
I guess you miss understood that this what we get. I'm merely a Wiki admin, trying to help out with the tools that have been provided. If you don't like the format, then don't worry about it, post in the forums and hope someone from BI will see your post and fix the issue and stop going on about something that isn't likely going to happen anytime soon, I think everyone can agree a better system is needed for fixing bugs, until then this is what we have. hoz 18:11, 13 December 2006 (CET)

Boecko this system is as official a system as there will be for reporting bugs, no more, no less, I respect you might not be happy with it, in which case the solution is to leave the bug reporting to other people.-Placebo 20:28, 13 December 2006 (CET)

I suppose this is an official statement of BI? So be it. I'm looking forward to the next patch.
Case closed. --Boecko 20:45, 13 December 2006 (CET)


Why closed? @ BI & Placebo: This will never speed up your bugfixung process. I am sure you use a TT tool inside BI for developement together with a kind of SVN. (if not, BI never left the garage / notepad / hacker way of going it??) So inside the community there is the willingness to provide for free (you hear that BI? for free!) the setup and administration of such an environment. Only question is if BI would really use that tool???? We would filter out the shitty tickets or map double / redundant tickets for BI so that BI would get the concentrated, well organized pain served on a silver plate.

Sounds good?

The only thing that would be necessary on your side:

- Willingness to use that TT.

- let us know in a workshop your demands on that tool (how it should be setup, names and content of cathegories, process flow of ticket status...)

- maintain the SW Version names and numbers

- maintain the trouble ticket-stat "fixed" "delayed" "rejected"

- maintain the change request stats

It might cost some resources on your side, but trust me, on the long run it would save BI so much time. In addition you might participate from that tool even for VBS if it is true that both using the same or similar engine because 1.000.000 eyes seeing more then a few hundred.

Check there if you wanna find some examples how it would look like:

here a few representative TTs / CRs

should make clear why lists ar not working:

https://wgl.bofh.at/wgldev/trac/ticket/250

Is a short CR for WGL, whichs could also be implemented now in ArmA core. In theory BI could request more info within the TT from the creator of the TT or rejected by BI as to ambitious or BI could answer with a design proposal for that CR



https://wgl.bofh.at/wgldev/trac/ticket/241


This CR describes a functionality request at high level, something we missed very hard already in OFP and it seems it is even not implemented in ArmA. At least I did not recognized that AI thrown a handgranade over a wall where I was hiding behind.


https://wgl.bofh.at/wgldev/trac/ticket/232

one that is also not solved in ArmA and requires a design decision by BI since they have a generic control set per model type


https://wgl.bofh.at/wgldev/trac/ticket/240

also a nice one, must still verify/test with ArmA if also here nades simply disappear after a certain lifetime. Stupid thing was / is that long range nade fire was not possible with that design fault since it took to long for the nades. Hence AGS17 on BMP where useless for toasting an area from safe distance.


https://wgl.bofh.at/wgldev/trac/ticket/390

This one I quickly created out of a german "official" ArmA forum


AND HERE THE BEST: A SOLVED TT:

https://wgl.bofh.at/wgldev/trac/ticket/372



Retrieved from "https://community.bistudio.com/wiki?title=Talk:ArmA:_Bugs_List-version-1.01.5094&oldid=24519"