I had to revert parts of your fix to:
return scale * w1 + (1 - scale) * w2;
As your change would result in errors when playing a normal botmatch.
However, I added a few more float casts for precision reasons.
by errors you mean that bots never change weapons, right? i just recognized another bug related to default cases in the fuzzy relations. they get the value MAX_INVENTORYVALUE (999999) assigned, and therefor scale between the default and any lower case will always be 0. with scale 0 and the correct weighting [ return (1 - scale) * w1 + scale * w2 ] w1 will be returned. for the weapon relations, w1 is always 0, since they all have this line before the default case:
[ case 1: return 0; ]
as fix i suggest:
//the scale factor
if(fs->next->value == MAX_INVENTORYVALUE) // is fs->next the default case?
return w2; // can't interpolate, return default weight
else
scale = (float) (inventory[fs->index] - fs->value) / (fs->next->value - fs->value);
No, by errors I mean red lines saying: "Error: Weapon number out of range!" or something like that.
Please turn your suggestions into patches (this is not difficult to do with tortoise svn client) which I can test then. If the error described is gone I'll apply it.
edit:
oops it worked. i got this error and thought the submission failed:
Unknown field id: attachments.isobsolete at globals.pl line 115.
both patches are identical.
your "out of range" error is the one i meant. all weapon relations return weight 0, weapon number 0 is chosen, which is out of range.
Setting a QA contact on all ioquake3 bugs, even resolved ones. Sorry if you get a flood of email from this, it should only happen once. Apologies for the incovenience.
--ryan.
Created attachment 1124 [details] fixed weight interpoation
Created attachment 1125 [details] fixed weight interpoation test