View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002031 | FSSCP | tables | public | 2009-11-10 09:39 | 2009-12-21 20:33 |
| Reporter | FUBAR-BDHR | Assigned To | Sushi_CW | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.11 | ||||
| Fixed in Version | 3.6.11 | ||||
| Summary | 0002031: AI classes above the 10th entry in the table cause AI to fire all weapons and maybe other stuff | ||||
| Description | I noticed the AI were firing weapons from way out of range. After several hours of experimenting an eliminating everything I could think of I noticed some entries were working. Started going through a few at a time to see where things started going nuts in case of some kind of typo in the tables. Blew up on the 11th entry. Commented it out and it did it on the 11th again. Copied 11th to 1st and that works. Checking the code it seems to allocate memory for 10 AI classes at a time and there is a comment in there about it not wanting to play nice. Guess it's not playing nice. | ||||
| Additional Information | 3.6.11 5643. Code is in AIcode.cpp around line 758. Actually allocates the first 10 above that. | ||||
| Tags | No tags attached. | ||||
|
|
This goes back at least as far as 3.6.9. I tried it with the retail exe but it just locks up about 2 seconds into the mission. To reproduce edit AI.tbl copy the existing entries and rename (I just stuck a 2 at the end) so you have more then 10. Play mission with original General (preferably on insane) then switch the AI in FRED to General2 and try again. |
|
|
Some history. From blame it appears the initial commit was done by WMC (r1649) was changed by WMC (r2074) and an attempted fix by Taylor (r2112). So it's definitely an old one. |
|
|
Probably scratch that whole theory. I bumped the number of initial allocated and it didn't help. Still goes nuts at the 11th entry. Did see quite a few things in the AI code based on Num_ai_classes which makes absolutely no sense to me if the ai classes don't need to be in any particular order or isn't a fixed limit. I give up on this one. |
|
|
OK so I didn't give up that easily. Tried setting a +weapon range: and that fixed the secondary problem so I went searching again. Found the issue was in one of the lines that was bugging me yesterday. Attaching a diff. It's messy and a better solution will be needed but it's a workaround. Figure this is one of those things that will require an ai_profile flag (or use an existing one) and/or ai.tbl entries to work around completely. As it is now all AI classes > 10 are treated as if they are class 10. |
|
2009-11-12 06:22
|
2031.diff (1,104 bytes)
Index: aicode.cpp
===================================================================
--- aicode.cpp (revision 5644)
+++ aicode.cpp (working copy)
@@ -8802,11 +8802,17 @@
firing_range = MIN((swip->max_speed * swip->lifetime * 0.75f), swip->weapon_range);
else
{
+ if (aip->ai_class <= 9) {
float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
? (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS
: aip->ai_secondary_range_mult;
-
- firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
+ firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
+ }else{
+ float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
+ ? (Game_skill_level + 5)/NUM_SKILL_LEVELS
+ : aip->ai_secondary_range_mult;
+ firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
+ }
}
|
|
|
I'll look into this more when I get a chance (which should be in a week or so). This problem may have old roots, but does it occur in 3.6.10? It's still possible that the new way of handling AI class & AI Profile stuff I implemented is to blame here (although I hope not). :) |
|
|
This dates back to retail but since retail had what 6 AI classes it wasn't an issue. V pretty much based distance at which secondary weapons would fire on difficutly and ai class. Farther down the table you went the longer the range at which they would actually fire. Well once you exceed the 10th entry it starts increasing the range. Now this is actually a nice feature to have. The problem is the way it was implemented. It should have been done as a percentage entry in AI.tbl for each class and difficulty. So if you want them to fire at full range you enter 100. You want half range 50. 2/3 66. Etc. Just like evasion, courage, etc. That may still be the way to go with this. Problem is the current valuse would need to stay as calculated. Guessing your AI profile flag $fix ai class bug could be used for this. Again the other issue is what else does it effect. |
|
|
Aha! Well, in that case, the solution you propose already exists. What you're looking for is $Secondary Range Multiplier. You'll notice in the patch you attached that that if secondary_range_mult is specified, it is used instead of the weird AI class-based calculation. In fact, you should probably check out all of these: http://hard-light.net/wiki/index.php/Ai.tbl#Other_AI_Class_Attributes I think it's a good idea for any AI.tbl with custom classes to make use of those to clearly define what the classes do. So they should all have: $Afterburner Use Factor: $Shockwave Evade Chances Per Second: $Get Away Chance: $Secondary Range Multiplier: and should set $Autoscale by AI Class Index to NO. Try that and see if it fixes the problem. In the meantime, I'll add a note to the wiki stating that if you use custom AI classes, you should probably specify all of these. |
|
|
Already tried it and it does not fix the problem. |
|
|
Darn. I wonder if the weird memory-allocation stuff is somehow preventing the table values from propagating properly? Anyway, it's at the top of my TODO list to figure out exactly what's happening. By the way, this only affects secondaries, right? |
|
|
I've only confirmed it in secondaries but it may exist in other things as well. For instance Minbari fighters in TBP always shoot beams from beyond their range and I've never been able to figure out quite why. Could be the same issue. Also a quick search of the code shows this is not the only place such calculations are used so a full review of those places may be in order. |
|
|
Are you using $fix AI class bug: YES in AI Profiles? http://hard-light.net/wiki/index.php/Ai_profiles.tbl#.24fix_AI_class_bug: Because if you don't, then none of the AI.tbl attributes actually get set properly if the AI Class for a ship is set in FRED instead of using the ships.tbl default. That would handily explain why setting $Secondary Range Multiplier isn't working: since it's using the old/buggy way of assigning AI classes to ships, the AI class NUMBER gets assigned but none of the associated attributes do. The result is that when it comes to the code that should use $secondary range multiplier instead of the calculation based on AI class number, it opts for the latter since it thinks erroneously that $secondary range multiplier wasn't set (even though it was). Short version: if you aren't using $fix AI class bug: YES, do so and see if that fixes the problem. |
|
|
I've tried that. Did you look at the diff I attached? It should make where the problem is clear as day. |
|
|
Blast. I have looked at the diff (several times), but it unfortunately doesn't tell us anything about what the cause of the problem is (just one hack to work around it). I did do some debugging to make sure that the AI class stuff was being parsed and the memory allocated correctly, and it seemed to be as far as I could tell (for 20+ entries). Guess I need to just keep digging more, replicate the problem in-game, and trace the snot out of it. |
|
|
The issue in the math. The formula does not take into account the possibility of AI class entries going above 10. So once it does you start ending up with a positive number to multiply the range at which secondaries will be fire by thus resulting in them being fired before they are in range. So the way the code originally works is something like this (not actually doing the math here) Range of 1000 Very easy/1st AI Class = Fire at 100 Medium/1st AI Class = Fire at 200 Insane/1st AI Class = Fire at 300 Very easy/5th AI Class = Fire at 500 Medium/5th AI Class = Fire at 600 Insane/5th AI Class = Fire at 700 Very easy 10th AI Class = Fire at 800 Medium/10th AI Class = Fire at 900 Insane/10th AI Class = Fire at 1000 Now you get to 11th and instead of the range at which they are fired being cut by the difficulty it is actually increased so you have: Very easy/11th AI Class = Fire at 900 Medium/11th AI Class = Fire at 1200 Insane/11th AI Class = Fire at 1400 Then a few levels more and you get to the point that the range is multiplied so much that the ships just fire when they arrive. |
|
|
But if $Secondary Range Multiplier is set, then none of that calculation happens. If I understood you correctly, though, you get the problem even when $Secondary Range Multiplier is set. I understand why the problem happens using default AI.tbl entries. What I'm still confused about is why it STILL happens when $Secondary Range Multiplier is set for the AI class and $Fix AI Class Bug is set to YES in the AI Profile. |
|
2009-11-29 02:45
|
|
|
|
After today's IRC conversation, it looks like the problem isn't with $Secondary Range Multiplier. That works as intended. The problem is that the default "auto-calc" behavior gives retarded results when there are too many AI classes. I discovered some other interesting issues while investigating the possibility of capping the calculated range multiplier at some sane value to prevent that problem. The range the AI shoots at is already capped by the maximum range of the secondary, as specified with +Weapon Range. Missiles in retail, however, don't have +Weapon Range specified, and the default is practically infinite (9999999.99 or somesuch). Also, the calculated range multiplier will go over 1.0 even WITHOUT adding any AI classes, if you are playing on higher difficulty levels. See the attached srm_table.pdf for details (it gets up to 1.4 or so). So, do we just say that autocalculated range multiplier should never go higher than that? What exactly should we use as a sanity-ceiling? 1.5 maybe? -- Personally, I still think the best solution for modders using custom AI classes is to exhaustively specify every option they can, so they know EXACTLY how each AI class behaves and why. Otherwise, we're dealing with arcane formulas (like the one we've been discussing) that the modder knows nothing about, and simple things like changing the order of AI classes has side-effect consequences on AI behavior. In other words, I think a modder using custom AI classes is nuts if they want to rely on the auto-calc behavior instead of specifying smart values themselves, and I have a hard time justifying making it easier for them to shoot themselves in the foot by trying to fix the auto-calc behavior (which is extremely mod-unfriendly by its very nature). So, my vote is to just make sure the issue is well documented and encourage modders to specify $Secondary Range Multiplier values for their custom AI classes. That said, I'd love to hear some more comments on all of this from some other people. |
|
|
Cap it a 10 (0-9) and document it. 10 was the original number of AI classes before V increased it to 50 and the SCP made it dynamic. So my guess is that is what the formulas were written for. I can't say that I've seen the range go to 2x at class 10 on insane though. Did my original testing on Insane. Seems about 1.4 -1.6x. Not saying they can't or don't shoot at the 2x range just didn't witness that behavior. At class 11 it didn't even go 2x. Tests were with a weapon with 1600 range. Class 11 shot at about 24-2600. Of course it went up fast from there. Too lazy right now to double check the math but the table might be off by 1. |
|
2009-11-30 17:16
|
2031_sushi.patch (2,057 bytes)
Index: code/ai/ai.h
===================================================================
--- code/ai/ai.h (revision 5691)
+++ code/ai/ai.h (working copy)
@@ -307,6 +307,10 @@
// Goober5000 (based on the "you can only remember 7 things in short-term memory" assumption)
#define MAX_IGNORE_NEW_OBJECTS 7
+//SUSHI: So that things don't break too badly when adding lots of AI classes
+//(some of the autocalculated stuff based on AI class doesn't scale with the total number of AI classes)
+#define MAX_AUTOCALC_AI_CLASS 9
+
typedef struct ai_info {
int ai_flags; // Special flags for AI behavior.
int shipnum; // Ship using this slot, -1 means none.
Index: code/ai/aicode.cpp
===================================================================
--- code/ai/aicode.cpp (revision 5691)
+++ code/ai/aicode.cpp (working copy)
@@ -8804,8 +8804,9 @@
firing_range = MIN((swip->max_speed * swip->lifetime * 0.75f), swip->weapon_range);
else
{
+ int autocalc_ai_class = MIN(aip->ai_class, MAX_AUTOCALC_AI_CLASS);
float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
- ? (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS
+ ? (Game_skill_level + 1 + autocalc_ai_class/2)/NUM_SKILL_LEVELS
: aip->ai_secondary_range_mult;
firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
@@ -13763,10 +13764,11 @@
// Don't all react right away.
if (!(aip->ai_flags & AIF_AVOID_SHOCKWAVE_STARTED)) {
+ int autocalc_ai_class = MIN(aip->ai_class, MAX_AUTOCALC_AI_CLASS);
float evadeChance = (aip->ai_shockwave_evade_chance == FLT_MIN)
- ? ((float) aip->ai_class/4.0f + 0.25f)
+ ? ((float) autocalc_ai_class/4.0f + 0.25f) // Chance to avoid in 1 second is 0.25 + ai_class/4
: aip->ai_shockwave_evade_chance;
- if (!rand_chance(flFrametime, evadeChance)) // Chance to avoid in 1 second is 0.25 + ai_class/4
+ if (!rand_chance(flFrametime, evadeChance))
return 0;
}
|
|
|
Alright, I uploaded a possible patch (2031_sushi.patch). Let me know what you think. |
|
|
Looks good to me. Just a couple of questions though. What affect does $Autoscale by AI Class Index: have on these? And of course are there any other cases like this out there? |
|
|
$Autoscale by AI Class Index does not affect secondary range firing or shockwave evading. It affects a whole host of other things, but there are already controls/parameters for adjusting those them (via AI Profiles or their equivalent AI.tbl overrides). Most places that use the AI class index for some sort of calculation take into account the total number of AI classes, so they scale properly. The only ones that don't seem to scale properly are secondary range firing and the shockwave evasion, which are covered by this patch. |
|
|
OK that's one for the documentation part then. |
|
|
Capping the ai_class shouldn't even be considered here. That doesn't fix the problem and adds a needless limitation to the engine. It is obvious that this is the V bug, so just fix the bug. The maximum range of a secondary weapon is max_speed * lifetime (as used in retail), which means that allowing a range multiplier above 1.0 introduces unintended behavior. secondary_range_mult just needs to be capped and 1.0 and let that be it, especially since aip->ai_secondary_range_mult doesn't appear sanity checked on parse either. If maintaining absolute compatibility with retail is paramount (and I don't think so in this case) then capping to 1.0 should just be done if aip->ai_class is > 6 (retail actually has and uses 7 AI classes, not 5). Either way aip->ai_secondary_range_mult still needs to always be capped into a sane range. Regarding shockwave evasion, I just don't see a problem there necessitating any changes. The higher the ai_class the greater the chance that a shockwave would be avoided. And an ai_class < 4 is considered dumb, hence the /4 there. Values > 1.0 are actually wanted in that case and the total number of AI classes has absolutely zero negative influence on that formula. |
|
|
Actually you want the AI to be able to fire from beyond max_speed * lifetime just not insanely beyond it. The weapons still only fly that far but allowing some extra distance for approaching ships (especially for anti-fighter weapons)is more realistic behavior. |
|
|
So capping it at something like 1.1 or 1.2 instead of 1.0 should work out then. That should give the little bit of extra distance while not making it so far out that the missiles would just be wasted. An extra 20% to the distance should account for fast approaching ships, but for things like slow moving cap ships it would probably be too much. Would 10% extra distance be enough of a balance between the two, or would just going 20% be the best overall option? |
|
|
Well I'm for even a little more. While nothing I'm working on has any major speeds I saw a ship posted the other day with a speed of 320. Hate to see that sucker in multiplayer. If need be cap it at 7 instead of 10 but sill allow +weapon range and secondary range multiplier to go beyond that. That way people can set up classes for fighter on fighter and bomber vs cap if they want without any hard limits. If a modder screws up a table entry then that's their problem. The code itself doing something unintended though is a different story. |
|
|
That seems reasonable. The formula in question can be capped but the value of aip->ai_secondary_range_mult would be left as-is. Should solve both issues pretty cleanly. |
|
|
Yeah, the proposed patch would still allow you to override things using $Secondary Range Multiplier and $Shockwave Evade Chances Per Second. No matter what we end up doing here, you'll be able to get your desired behavior using those (and IMHO every custom AI.tbl *should* specify those manually). So where does that leave us? The last post by Talor is exactly the situation the patch gives us, just with the capping mechanism based on the AI class safely out of retail range instead of a hardcoded value. The end result is the same, but I think the AI class count way is going to be clearer and easier. The idea is that the only changes are to places in the code that DO NOT scale with the number of AI classes. All this does is make it so that if someone does add a ton of AI classes, but doesn't specify things manually, they won't get weird unexpected behaviors like missiles firing from 10k away. The shockwave evasion part could be skipped, I guess... to be honest I doubt anyone will notice it one way or the other. I mostly included it for completeness (so all cases where autocalc by AI class index is used but doesn't scale with total number of AI classes are covered). So, where does this leave us exactly? |
|
|
You seem to be working under the premise that all of these calculations must somehow be dependant on the number of total ai classes. That simply isn't the case. Your proposal is for a fix that really has nothing to do with the problem. The problem with the secondary range multiplier is that it simply isn't sanity checked. This is a V bug. It is a simple one line change to do CLAMP("formula", 0.1f, 1.1f). There really isn't a cleaner or clearer way to do that. For the shockwave evasion case your proposal actually introduces a bug because you are capping the chance that higher AI classes receive. It doesn't have anything to do with the total number of AI classes that exist and there is absolutely no reason to change that. |
|
2009-12-04 06:18
|
2031_taylor.diff (959 bytes)
diff --git a/code/ai/aicode.cpp b/code/ai/aicode.cpp
index 84edf66..9a8f27c 100644
--- a/code/ai/aicode.cpp
+++ b/code/ai/aicode.cpp
@@ -8804,9 +8804,13 @@ void ai_chase()
firing_range = MIN((swip->max_speed * swip->lifetime * 0.75f), swip->weapon_range);
else
{
- float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
- ? (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS
- : aip->ai_secondary_range_mult;
+ float secondary_range_mult = aip->ai_secondary_range_mult;
+
+ if (secondary_range_mult == FLT_MIN) {
+ secondary_range_mult = (Game_skill_level + 1.0f + aip->ai_class/2.0f)/NUM_SKILL_LEVELS;
+ // don't let it go above 110% of max range
+ CLAMP(secondary_range_mult, 0.1f, 1.1f);
+ }
firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
}
|
|
|
Attaching my proposed version of the fix for reference. |
|
|
What about making the sanity check based on (lifetime * velocity) + (lifetime * closing speed of target)? Not sure if the closing speed is known at that point. |
|
2009-12-04 17:03
|
2031_sushi_2.patch (839 bytes)
Index: code/ai/aicode.cpp
===================================================================
--- code/ai/aicode.cpp (revision 5691)
+++ code/ai/aicode.cpp (working copy)
@@ -8804,8 +8804,9 @@
firing_range = MIN((swip->max_speed * swip->lifetime * 0.75f), swip->weapon_range);
else
{
+ int autocalc_range_mult = (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS;
float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
- ? (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS
+ ? CLAMP(autocalc_range_mult, 0.0f, 1.6f) //Sanity check: Max possible with retail AI classes is 1.6
: aip->ai_secondary_range_mult;
firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
|
|
|
Why don't we just cap it at the maximum possible value for retail? General is AI Class 0000007, giving it an index of 6. General on Insane gives us: (4 + 1.0f + 6/2)/5 = 8/5 = 1.6 Attached 2031_sushi_2.patch |
|
|
Any more comments, or should I commit my most recent proposed patch? |
|
2009-12-11 16:38
|
2031_sushi_3.patch (632 bytes)
Index: code/ai/aicode.cpp
===================================================================
--- code/ai/aicode.cpp (revision 5711)
+++ code/ai/aicode.cpp (working copy)
@@ -8814,7 +8814,7 @@
else
{
float secondary_range_mult = (aip->ai_secondary_range_mult == FLT_MIN)
- ? (Game_skill_level + 1 + aip->ai_class/2)/NUM_SKILL_LEVELS
+ ? (Game_skill_level + 1 + (3 * aip->ai_class/(Num_ai_classes - 1)))/NUM_SKILL_LEVELS
: aip->ai_secondary_range_mult;
firing_range = MIN((swip->max_speed * swip->lifetime * secondary_range_mult), swip->weapon_range);
|
|
|
Added 2031_sushi_3.patch Wanderer had some good suggestions, making this whole thing even simpler. Instead of capping at 1.6, we make it scale with the total number of AI classes in a way that doesn't affect retail. |
|
|
Committed the last patch. |
|
|
Now wait a minute. If you change the scaling method, that *does* affect retail because it'll use a different formula. Why can't you do what taylor said and add CLAMP? People who override the value using ai_profiles aren't going to care about the retail formula anyway. |
|
|
It doesn't affect the original formula any more than a CLAMP would. In both cases, you get the same result using retail tables (check the math). The only difference is what happens if you add more AI.tbl entries without specifying $Secondary Range Multiplier. If we use CLAMP, then the scaling just sort of stops after the 7th entry. If we scale based on number of AI Classes, then the scaling grows with the total number of entries in the table. I think the second option is slightly better, just because it is more consistent with the way that most places in the AI code. Usually, when the AI class index is used to scale something, it is done in relation to the total number of AI classes. The secondary range thing is an exception right now. The whole point of this patch is to make it a bit harder for modders to shoot themselves in the foot when they add AI.tbl entries. Given that, it makes sense to go with the method where, all other things being equal, we make the AI behavior in terms of AI class index MORE consistent, not LESS consistent. |
|
|
"In both cases, you get the same result using retail tables" <-- okay, that's what I was concerned about. :) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-11-10 09:39 | FUBAR-BDHR | New Issue | |
| 2009-11-10 17:33 | Zacam | Status | new => assigned |
| 2009-11-10 17:33 | Zacam | Assigned To | => Sushi_CW |
| 2009-11-10 21:41 | FUBAR-BDHR | Note Added: 0011239 | |
| 2009-11-10 22:31 | FUBAR-BDHR | Note Added: 0011240 | |
| 2009-11-11 02:33 | FUBAR-BDHR | Note Added: 0011243 | |
| 2009-11-12 06:22 | FUBAR-BDHR | Note Added: 0011248 | |
| 2009-11-12 06:22 | FUBAR-BDHR | File Added: 2031.diff | |
| 2009-11-17 22:56 | Sushi_CW | Note Added: 0011294 | |
| 2009-11-18 00:28 | FUBAR-BDHR | Note Added: 0011297 | |
| 2009-11-18 05:15 | Sushi_CW | Note Added: 0011300 | |
| 2009-11-18 05:31 | FUBAR-BDHR | Note Added: 0011301 | |
| 2009-11-18 05:34 | Sushi_CW | Note Added: 0011302 | |
| 2009-11-18 07:45 | FUBAR-BDHR | Note Added: 0011303 | |
| 2009-11-27 16:08 | Sushi_CW | Note Added: 0011347 | |
| 2009-11-27 21:16 | FUBAR-BDHR | Note Added: 0011348 | |
| 2009-11-28 01:04 | Sushi_CW | Note Added: 0011349 | |
| 2009-11-28 02:05 | FUBAR-BDHR | Note Added: 0011350 | |
| 2009-11-28 16:37 | Sushi_CW | Note Added: 0011352 | |
| 2009-11-29 02:45 | Sushi_CW | File Added: srm_table.pdf | |
| 2009-11-29 03:15 | Sushi_CW | Note Added: 0011354 | |
| 2009-11-29 04:44 | FUBAR-BDHR | Note Added: 0011355 | |
| 2009-11-30 17:16 | Sushi_CW | File Added: 2031_sushi.patch | |
| 2009-11-30 17:17 | Sushi_CW | Note Added: 0011357 | |
| 2009-11-30 19:43 | FUBAR-BDHR | Note Added: 0011358 | |
| 2009-11-30 21:20 | Sushi_CW | Note Added: 0011359 | |
| 2009-11-30 21:46 | FUBAR-BDHR | Note Added: 0011360 | |
| 2009-12-02 07:06 | taylor | Note Added: 0011363 | |
| 2009-12-02 08:05 | FUBAR-BDHR | Note Added: 0011364 | |
| 2009-12-02 08:17 | taylor | Note Added: 0011365 | |
| 2009-12-02 08:48 | FUBAR-BDHR | Note Added: 0011366 | |
| 2009-12-02 09:37 | taylor | Note Added: 0011367 | |
| 2009-12-02 16:52 | Sushi_CW | Note Added: 0011369 | |
| 2009-12-02 23:51 | taylor | Note Added: 0011370 | |
| 2009-12-04 06:18 | taylor | File Added: 2031_taylor.diff | |
| 2009-12-04 06:18 | taylor | Note Added: 0011374 | |
| 2009-12-04 07:53 | FUBAR-BDHR | Note Added: 0011375 | |
| 2009-12-04 17:03 | Sushi_CW | File Added: 2031_sushi_2.patch | |
| 2009-12-04 17:04 | Sushi_CW | Note Added: 0011376 | |
| 2009-12-11 15:45 | Sushi_CW | Note Added: 0011404 | |
| 2009-12-11 16:38 | Sushi_CW | File Added: 2031_sushi_3.patch | |
| 2009-12-11 16:39 | Sushi_CW | Note Added: 0011405 | |
| 2009-12-18 17:24 | Sushi_CW | Note Added: 0011431 | |
| 2009-12-18 17:24 | Sushi_CW | Status | assigned => resolved |
| 2009-12-20 23:08 | Goober5000 | Note Added: 0011452 | |
| 2009-12-20 23:08 | Goober5000 | Status | resolved => feedback |
| 2009-12-21 15:11 | Sushi_CW | Note Added: 0011456 | |
| 2009-12-21 20:33 | Goober5000 | Note Added: 0011458 | |
| 2009-12-21 20:33 | Goober5000 | Status | feedback => resolved |
| 2009-12-21 20:33 | Goober5000 | Resolution | open => fixed |
| 2009-12-21 20:33 | Goober5000 | Fixed in Version | => 3.6.11 |
