Login
User Name:

Password:



Register
Forgot your password?
Vote for Us!
parse description bug
Dec 15, 2017, 10:08 pm
By Remcon
Couple bugs
Dec 12, 2017, 5:42 pm
By Remcon
Bug in disarm( )
Nov 12, 2017, 6:54 pm
By GatewaySysop
Bug in will_fall( )
Oct 23, 2017, 1:35 am
By GatewaySysop
Bug in do_zap( ), do_brandish( )
Oct 18, 2017, 1:52 pm
By GatewaySysop
LOP 1.45
Author: Remcon
Submitted by: Remcon
LOP Heroes Edition
Author: Vladaar
Submitted by: Vladaar
Heroes sound extras
Author: Vladaar
Submitted by: Vladaar
6Dragons 4.3
Author: Vladaar
Submitted by: Vladaar
Memwatch
Author: Johan Lindh
Submitted by: Vladaar
Users Online
CommonCrawl, Bing, Yahoo!

Members: 0
Guests: 10
Stats
Files
Topics
Posts
Members
Newest Member
477
3,706
19,240
608
LAntorcha
Today's Birthdays
There are no member birthdays today.
Related Links
» SmaugMuds.org » Codebases » SWR FUSS » Damage calculations in fight.c
Forum Rules | Mark all | Recent Posts

Damage calculations in fight.c
< Newer Topic :: Older Topic >

Pages:<< prev 1 next >>
Post is unread #1 Feb 21, 2009, 2:20 am   Last edited Feb 21, 2009, 2:25 am by Kasji
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

Hello everyone. This may or may not be a bug, depending on your point of view, but I thought I would bring it to everyone's attention.

I recently revamped the combat system for a FotE based MUD, and this particular line is one of interest:
   if( !wield )   /* dice formula fixed by Thoric */
      dam = number_range( ch->barenumdie, ch->baresizedie * ch->barenumdie ) + ch->damplus;
   else
      dam = number_range( wield->value[1], wield->value[2] );

For quite a while I was always mystified how damage was calculated (because I never bothered to look.) Mainly because what is written in the "oset" command is misleading. There are two values that you can oset to determine damage on weapons. They are: "numdamdie" and "sizedamdie".

This has always implied to me that weapon damage is calculated as <num>D<size> (in RPG terms) or in code terms, the following in the "else" code block:
   if( !wield )   /* dice formula fixed by Thoric */
      dam = number_range( ch->barenumdie, ch->baresizedie * ch->barenumdie ) + ch->damplus;
   else
      dam = number_range( wield->value[1], wield->value[1] * wield->value[2] );

Also note how that actually matches the preceeding unarmed damage calculation as well!
This issue exists on SWR FUSS, SWFotE FUSS, and SWRiP 2.0. It probably exists on SMAUG too, but I didn't check that code.

What do you all think? I know this is a fairly dramatic change. I imagine none of you would like to go through every single weapon in your MUD just to adjust its damage values to fall in line with this formula change.

Also, I actually took a slightly different route. I know this is a bit less efficient than using the above, but in the spirit of traditional tabletop RPGs, I actually went with the following code in hopes of a more traditional "feel" for damage calculations since it simulates throwing multiple die:
   if( !wield )   /* dice formula fixed by Thoric */
      dam = number_range( ch->barenumdie, ch->baresizedie * ch->barenumdie ) + ch->damplus;
   else
   {
//      dam = number_range( wield->value[1], wield->value[2] );
      int x;
      dam = 0;
      for (x = 0; x < wield->value[1]; x++)
         dam += number_range(1, wield->value[2]);
   }
       
Post is unread #2 Feb 21, 2009, 7:59 am
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

What difference does it make if you generate a random number in the correct range, versus summing up several random numbers? What exactly are you trying to accomplish there?
       
Post is unread #3 Feb 21, 2009, 10:27 am
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

The problem here is that you're misunderstanding what the values are used for. On weapon damage, the first value is the minimum amount, the second value is the maximum amount. It's not a dice formula. So there's no bug here to fix and if you go ahead with what you're doing you'll be finding things way off balance.
       
Post is unread #4 Feb 21, 2009, 3:20 pm
Go to the top of the page
Go to the bottom of the page

Keberus
Conjurer
GroupFUSS Project Team
Posts341
JoinedJun 4, 2005

Samson is right on, but I thought an example might help. Let's say you make a vibro-blade and set value[1] = 25 and value[2] = 75. The way the code currently works is that when someone uses that vibro in a fight, the damage they do (because of it) is between 25 and 75, which is how its supposed work. So if you input the values the function would look like:
dam = number_range( 25, 75 );

Which just generates a random number between 25 and 75.

Your modified one would yield:
dam = number_range( 25, 1875 );

Which will yield a number between 25 and 1875. So in this particular case, you would effectivly be making the vibro blade potentially do 25x more damage than before.

Hope the example helps.

KeB
       
Post is unread #5 Feb 21, 2009, 3:30 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I think what he's complaining about is this:
Kasji said:

There are two values that you can oset to determine damage on weapons. They are: "numdamdie" and "sizedamdie".

In other words, he understands that the formula is doing something different than what the object value names suggest, and instead of fixing the names, he is suggesting that the formula be fixed to be more in line with "traditional tabletop RPGs".

Obviously there is a problem of inconsistency here. I think the easier (and far less) disruptive fix is to just fix the names.

Incidentally, having an actual min/max gives you more control over the values than dice. It is impossible, for example, to construct a die-based formula that goes from 3 to 7. (unless you use modifiers like XdY +/- Z)
       
Post is unread #6 Feb 21, 2009, 4:46 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Yes, much easier to change the names if its that much of a sticking point.

And David: 2d3+1 is a perfectly valid way to represent 3-7. I'm sure this is not lost on the D&D people either as they didn't make up fractional dice to solve it. :)
       
Post is unread #7 Feb 21, 2009, 4:57 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

I was talking about doing it in the current framework, which according to Kasji only allows number and size -- in particular, not the modifier that you need to in this case.
       
Post is unread #8 Feb 21, 2009, 7:28 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

This is with the current framework. Look at how the barehand damage is done. A dice roll and a modifier value. It's just that they chose not to keep the same consistent formula to handle weapon damage values for some reason.
       
Post is unread #9 Feb 21, 2009, 7:40 pm   Last edited Feb 21, 2009, 7:46 pm by Kayle
Go to the top of the page
Go to the bottom of the page

Kayle
Off the Edge of the Map
GroupAdministrators
Posts1,195
JoinedMar 21, 2006

But on objects there is no sizedamdie or numdamdie. That's on Mobs.

[Edit:] Damn preview button. >.< Anyway.

You need to look at the formulas:

   if( !wield )   /* dice formula fixed by Thoric */
      dam = number_range( ch->barenumdie, ch->baresizedie * ch->barenumdie ) + ch->damplus;

This is pulling from the character data to get the persons unarmed damage. Which requires the 3 values, plus the damplus. Because that's how mobs are set up to handle things.

   else
      dam = number_range( wield->value[1], wield->value[2] );

This is pulling value 1 and 2 off the weapon. There is no plus. Thus these numbers are the bounds of damage you want the weapon to be able to do. In the case of the helpfile for item values, it's wrong. If you want to make it work like that, you're going to have to rework a lot more than just this formula. You're going to have to go through and look at every item in every area, and rework the numbers, because like KeB demonstrated. with this one change you're going to end up multiplying the damage by a rather large amount. And that's not the way the system was designed. It was merely documented wrong in the helpfiles.
       
Post is unread #10 Feb 21, 2009, 8:01 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

Yes, and wrong helpfiles are a far simpler thing to fix, as are the names of the values used to edit stuff through the OLC.
       
Post is unread #11 Feb 21, 2009, 9:28 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Samson said:

It's just that they chose not to keep the same consistent formula to handle weapon damage values for some reason.

If you can't do it with weapons, how is this something you can do in the current framework. :evil:
       
Post is unread #12 Feb 21, 2009, 10:30 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

What difference does it make if you generate a random number in the correct range, versus summing up several random numbers? What exactly are you trying to accomplish there?

I'm sorry David, I'm not a statician or mathematician or anything. I'm not saying that the method I chose has any impact at all on what numbers are rolled (although we could take some samples and see if there's any difference.) I gave my explaination: It's just simply a closer simulation of how tabletop rolls are done.

The problem here is that you're misunderstanding what the values are used for. On weapon damage, the first value is the minimum amount, the second value is the maximum amount. It's not a dice formula. So there's no bug here to fix and if you go ahead with what you're doing you'll be finding things way off balance.

No, I'm not misunderstanding at all. I understand that it represents a specific min and a specific max. What is shown in do_oset is not consistent with that though. And, I did say in my initial post that depending on your point of view, this may or may not be considered a bug, and also that if the formula were altered, rebalancing of all weapons would be required.

In other words, he understands that the formula is doing something different than what the object value names suggest, and instead of fixing the names, he is suggesting that the formula be fixed to be more in line with "traditional tabletop RPGs".

Obviously there is a problem of inconsistency here. I think the easier (and far less) disruptive fix is to just fix the names.

Incidentally, having an actual min/max gives you more control over the values than dice. It is impossible, for example, to construct a die-based formula that goes from 3 to 7. (unless you use modifiers like XdY +/- Z)

Yes, you are correct on all accounts. It would be much simpler to change do_oset to be consistent with the current formula. I've already been considering adding a damplus value to my weapons. And the muds I'm actually working with don't really have a player base or much of anything in terms of weapons, so rebalancing items wasn't a particular concern for me. Not to mention this is the LEAST of the changes I've made to the combat system.

But on objects there is no sizedamdie or numdamdie. That's on Mobs.

On your MUD? That's fine. But apparently you haven't looked at do_oset on SWR, SWFotE, or SWRiP. I admit, I haven't looked at Smaug's do_oset myself.

Yes, and wrong helpfiles are a far simpler thing to fix, as are the names of the values used to edit stuff through the OLC.

Indeed it is. Well at least if the helpfiles and do_oset is changed, any confusion for newer builders will hopefully be avoided.

If you can't do it with weapons, how is this something you can do in the current framework. :evi:

Yeah, there's currently no damplus value on obj_data as far as I know, but like I said I'm thinking of adding it.
       
Post is unread #13 Feb 21, 2009, 10:46 pm
Go to the top of the page
Go to the bottom of the page

David Haley
Sorcerer
GroupMembers
Posts903
JoinedJan 29, 2007

Kasji said:

I'm sorry David, I'm not a statician or mathematician or anything. I'm not saying that the method I chose has any impact at all on what numbers are rolled (although we could take some samples and see if there's any difference.) I gave my explaination: It's just simply a closer simulation of how tabletop rolls are done.

Well, my point was kind of that there's no point in doing this if all you're trying to do is emulate reality. You might as well simulate tabletop rolls by developing a physics model for dice to accurately roll them on a table to see what side comes up on top. There's really no point in replicating the real world exactly when you can accomplish the exact same thing more simply. You don't want to model the real world just to get (I say this with no offense intended, truly) a fuzzy feeling about the program pretending to roll dice in some manner approximating ours.

But, there is indeed a statistical difference. To answer the question, 3 times 6-sided dice is not quite the same thing statistically as generating a number between 3 and 18 inclusive.

Probability of getting 3 with 3 times 6-sided dice: 1/6 * 1/6 * 1/6 = 0.0046
Probability of getting 3 with number uniformly distributed in range 3...18: 1 / 16 = 0.0625

but

Probability of getting 10 with 3 times 6-sided dice = P(1 then 3 then 6) + P(1 then 4 then 5) + P(1 then 5 then 4) + P(1 then 6 then 3) + P(2 then 2 then 6) + P(2 then 3 then 5) + .....
Probability of getting 10 with uniform distribution: 1/16 = 0.0625

The uniform distribution will generate numbers that are, well, more uniformly distributed. The dice method will generate numbers more centered around the average, with the tails of the curve being harder to get.

If you change the calculation method, it should be for statistical reasons, not reality-modeling. Maybe you want average numbers to come out more often. Or maybe you want every outcome to be equally probable. But whatever you choose, you should do so knowing what you're choosing, and what effect it will have on your game.
       
Post is unread #14 Feb 21, 2009, 11:06 pm
Go to the top of the page
Go to the bottom of the page

Samson
Black Hand
GroupAdministrators
Posts3,639
JoinedJan 1, 2002

DavidHaley said:

Samson said:

It's just that they chose not to keep the same consistent formula to handle weapon damage values for some reason.

If you can't do it with weapons, how is this something you can do in the current framework. :evil:


Because you can. It's just not the most intuitive way to go about it. You have to add an affect to the item with whatever the +dam affect is called and there you go. The particular line in fight.c does not factor that in right away either. That happens a bit further down. But it is there, unless I hallucinated it all these years :)
       
Post is unread #15 Feb 21, 2009, 11:36 pm
Go to the top of the page
Go to the bottom of the page

Kasji
Apprentice
GroupMembers
Posts62
JoinedDec 23, 2007

I did suspect what you're saying David. And I actually do like that. More power to me!! Heh. Thanks for the information though, much appreciated.
       
Pages:<< prev 1 next >>