New Reno boxing bonus stats - Feature, or just a bug?

Darek

is currently unavailable
I'll just quote Per so you know what I'm talking about.
a green star At the start of every match, if you have either kind of gloves, you gain a permanent +3 bonus to your Damage Threshold for normal damage (to a maximum of 100), -1 to your DT for plasma and explosive damage, and a bonus to Damage Resistance for each listed damage type except fire (to a maximum of 90%). If you only have normal gloves you get +1% DR for all four types, but if you have plated ones you get +2% for normal damage, +5% for laser damage and +1% for the others. (There's also a -1% penalty to your unlisted EMP resistance, but this doesn't matter in the least; your electricity resistance is unaffected.) You get to keep these bonuses even if you lose that match. Therefore, in the fourth match, you can kick your opponent, ask Little for another shot, then win the final match (the Masticator's replacement is significantly weaker and doesn't bite) and you'll have got a fifth toughness bonus for only $500. Even factoring in the DT penalties that's better than any combat implant! Silencer muses: "Perhaps the resistance boosts were just supposed to be temporary and not permanent - that'd explain why plated gloves give you better ones, since you can block and shield your sorry face better with them." That only covers one damage type, though.

I've been trying to find out more of how this bonus works, and I have a theory that you were never supposed to get anything at all.
That it's just a lucky (or unlucky) bug. It all depends on how you see it. ;)

I'll try to describe how it all works (and if I'm wrong, please correct me).

When you talk to Stewart Little to start boxing, he moves all your stuff to a temporary box. Then he checks the temp box to see what gloves you had.
He creates a special set of gloves for you without the weapon knockback perk.
After that he tells you to equip those gloves with this command:
Code:
					wield_obj_critter(dude_obj, restock_obj);
In that same instance you get the bonus stats, though I haven't been able to find any code for that.

What I wanted to know was why you get a different bonus depending on what gloves you have, but without the code I couldn't find anything.
So I moved the gloves bit and the equipping part to the dude script and had it create a gun instead of those special gloves.
That gave me a totally different bonus (much higher values) and after thinking a bit I realized that I recognized them. They corresponded with some of the weapon stats. I've tried to create a few different weapons to check their bonuses and to find out what weapon stats those numbers represent. This is what I came up with:

Code:
Here's the Plated Boxing glove bonus:
Normal: 3/2
Laser : 0/5
Fire : 0/0
Plasma: 0/1
Explode: 0/1

and here are the proto file data the bonus is added from:
MP Cost1 / Min Dmg
MP Cost2 / Max Dmg
Crit Fail / Damage Type
Perk / Max Range
Don't know / Min Strength
It fits with all the weapons I've checked and it explains the different bonus you get from normal gloves and plated ones.
So what I believe is that the code for equipping a weapon is bugged. It adds weapon data into the bonus stats section for some reason.
To me it looks like the only bonus you were supposed to get were the ones for becoming a prizefighter, and nothing else.

Does this sound plausible and does anyone know anything more?
 
Interesting.

Logically, you should get a temporary bonus to each fight based on the type of gloves you're using (i.e. better bonus for plated gloves).

IF there were meant to be any PERMANENT bonuses to your character they should always be the same, no matter what gloves you've been using during the fight(s).
 
Fascinating work, detective Darek. :clap:

Personally, i have no doubt the devs didn't intend the player to get the boxing bonuses permanently, with the exception of the prizefighter bonus as Darek's research suggests.
 
NovaRain said:
What's the real bonus of Prizefighter?
+5% bonus to your Unarmed skill and damage resistance +5.

@ SkuLL,
What I'm saying is that you were not supposed to get any temporary bonus either (as far as I can see). I don't know what goes on inside the engine but adding bonus stats directly from the weapon data is an awfully strange way of doing things. I just can't believe that was ever intended.

@ Josan
Thanks. Yeah it is fascinating. To think this has gone unnoticed for so long just because the bonus added was fairly small and kinda fit in as well. I'm hoping to get a second opinion to confirm it's correct though.
 
Darek said:
@ SkuLL,
What I'm saying is that you were not supposed to get any temporary bonus either (as far as I can see). I don't know what goes on inside the engine but adding bonus stats directly from the weapon data is an awfully strange way of doing things. I just can't believe that was ever intended.
You're right, it seems like a strange way of doing it... The only real bonus at all should be the Prizefighter.

I've noticed before that there was a small permanent bonus given for each fight, but thought it was an intended feature (i.e. 'you get tougher with each fight'). Seeing how it's coded (relative to weapon used) reveals that it was probably not meant to be like that.
 
Very interesting. So your conclusion is that the code for equipping a weapon actually modifies the critter's stats? Does this only happen to the player? When other critters equip a weapon, do they too have stat increases?

I'm also curious if Timeslip or other engine modders have anything to add to this when they look at what that function actually does under the hood.

Great work Darek. Once again you dig up something important!
 
killap said:
Very interesting. So your conclusion is that the code for equipping a weapon actually modifies the critter's stats? Does this only happen to the player? When other critters equip a weapon, do they too have stat increases?

I'm also curious if Timeslip or other engine modders have anything to add to this when they look at what that function actually does under the hood.

Great work Darek. Once again you dig up something important!

I haven't had much time for Fallout recently, but I've been keeping track of this issue. For now, I've a rough idea where to look, and will take a deeper analysis once RL permits me to do so.

Of course, if Timeslip's RL schedule frees up before mine does, he will crack it open in a fraction of the time that I would. :)

-- The Haen.
 
I haven't time to do a proper check, but from first glance here's my guesses:

op_weild_obj_critter is set to call adjust_ac if the item it equips ends up on the players body rather than in a hand. adjust_ac adds on the items ac and dt/dr stats to the critter. The problem is that the check for armour is broken, with the result that anything that ends up in the players left hand also gets counted as armour. Since the proto is a weapon, it just ends up using the values at the same point in memory as where the armours ac/dt/dr would be. When the weapon is unequipped again, there's no broken check leading fallout to mistakenly believe it's armour, so the modified stats don't get removed.

This only effects the player. op_weild_obj_critter doesn't call adjust_ac on any other critter. You should also find that if you equip something to the players right hand, the bug shouldn't happen. It also doesn't effect weapons equipped by any other method than calling weild_obj_critter from a script.
 
Thanks for looking at it Timeslip. So I guess we can expect a fix for it soon? :wiggle:
Nah, but does it look like something easy to fix or should we rather look for a workaround?
 
So this was a bug? I'm looking forward to its fix in the unofficial patch. I'm glad this is getting fixed, because it's a very big issue.
 
Hi Darek,

May I clarify a few details with you? Are you observing the same results regardless of the weapon type? Say, ranged weapons, energy weapons, big guns, melee weapons?

Also, do you observe the same thing happening if you are not arming dude_obj with a weapon? (For example, try making dude_obj wield a stimpak or an armor or a key or some ammo).

Thanks,

-- The Haen.
 
If Timeslip's hypothesis is correct, and I see no logical flaws in his reasoning, then this should happen for anything equipped in the left hand by that particular script command, including all weaponry and gear. I imagine if the script were to left-hand-equip a stack of ammo or a Stimpak we might see some completely messed up values, or possibly a crash if the engine tries to locate data beyond the proto's size.

The way I'd go about fixing this is, this being me talking, the simplest and most straightforward: find the script that ports you out of the ring after an ended fight, add a line that checks what gloves you have equipped, and another one that makes use of sfall's excellent extended script commands to deduct the appropriate amount from your stats according to said gloves.
 
or use sfall to write a hook for the op_weild_objc_critter function and make the item equip to the right slot, rather than the left. no adding or subtracting of player stats required.
 
@ Haenlomal,
More or less. IIRC energy weapons had one value slightly different.
I didn't test that many weapons, only ten or so. Never any armors or other items, but I'll look into it.

Magnus said:
The way I'd go about fixing this is, this being me talking, the simplest and most straightforward: find the script that ports you out of the ring after an ended fight, add a line that checks what gloves you have equipped, and another one that makes use of sfall's excellent extended script commands to deduct the appropriate amount from your stats according to said gloves.
Yeah that was the workaround I had in mind, but not after the fight. It has to be just after you have the gloves equipped or you will get a temporary bonus during the fight. That was never intended.
Also, a proper fix is always preferable.
 
Heh, I'd say: just subtract the stats afterwards, no cumbersome hook scripts and weapon switching required. I'm a big fan of gaffa tape.
 
I know I'm normally a big fan of unhardcoding stuff and then doing everything with scripts, but in this case its an obvious bug and deserves a fix in the engine. No point in hiding it, or trying to work around it by shuffling weapons to different hands. It wont be too hard to fix the armour check to only trigger on actual armour.

The tests I'd like to see to check my reasoning was correct would be to try equipping something to the players right hand to check that the dt/dr bonuses don't get applied, and finding which value in the weapon proto matches up with ac in the armour proto, checking that it's 0, (since you don't get permanent ac bonuses from boxing,) and then setting it to something else to see what happens.

Edit: Looking at the modding wiki, it's the animation code. That's fine for the gloves, which use the unarmed animation and have a 0 in that field, but it does mean that equipping other weapons should have changed your ac, if I was right. :?
 
@ Haenlomal
Armors are automatically equipped into the armor slot, so they get the correct values and they reset when the armor is removed.
The stimpack will add to your armor stats.

@ Timeslip
I'm not sure what you mean by the right hand not being broken.
The weapon will get equipped to whatever hand I happen to have active. The bonus is applied on both hands and it's permanent.
AC does get changed with other weapons than hand to hand, I just didn't know from what stat so I left it out.
 
Darek said:
@ Haenlomal
Armors are automatically equipped into the armor slot, so they get the correct values and they reset when the armor is removed.
The stimpack will add to your armor stats.

@ Timeslip
I'm not sure what you mean by the right hand not being broken.
The weapon will get equipped to whatever hand I happen to have active. The bonus is applied on both hands and it's permanent.
AC does get changed with other weapons than hand to hand, I just didn't know from what stat so I left it out.

Thanks for the clarification, Darek. The results were as I would have expected, given what was in op_wield_obj_critter. I wanted a further clarification to discount the distant possibility that something was wrong with invenWieldFunc.

At any rate, I believe that I have isolated the cause of the bug, and will submit a fix for it shortly.

Cheers,

-- The Haen.
 
Back
Top