23 Sep, 2007, Zeno wrote in the 1st comment:
Votes: 0
Is it possible to have a weapon do 500 to 600 damage (without changing code)? If so, could you explain how?
23 Sep, 2007, Guest wrote in the 2nd comment:
Votes: 0
This is the code in SmaugFUSS 1.8 for figuring weapon damage:
dam = number_range( wield->value[1], wield->value[2] );


There's no weird dice formulas being used or anything so you should simply be able to set value[1] to 500 and value[2] to 600 to get what you want.
23 Sep, 2007, Conner wrote in the 3rd comment:
Votes: 0
I don't think you can because you can only assign xdy dam dice to a weapon and I can't think of a way that you could assign x or y as whole numbers that would limit it to 500-600. But I'd be delighted to hear anyone's solution if I'm mistaken.
23 Sep, 2007, Conner wrote in the 4th comment:
Votes: 0
You sure, Samson? The help file for object values says that v1 is num of dice and v2 is size of dice. But I hadn't bothered to see if that's what the code says… or is that something that changed in 1.8?
23 Sep, 2007, Zeno wrote in the 5th comment:
Votes: 0
Yeah I tried that. v1 is 500, v2 is 600. With the weapon, I just did 1242 damage.
23 Sep, 2007, Guest wrote in the 6th comment:
Votes: 0
I'm quite certain it wasn't changed later. Here's the block from 1.4a:
/*
* Hit.
* Calc damage.
*/

if ( !wield ) /* bare hand dice formula fixed by Thoric */
dam = number_range( ch->barenumdie, ch->baresizedie * ch->barenumdie );
else
dam = number_range( wield->value[1], wield->value[2] );


The helpfile is wrong. You also need to keep in mind that weapon damage values are not the only thing the system considers. There's other bonus applications that come further past this in the one_hit function in fight.c.
23 Sep, 2007, Zeno wrote in the 7th comment:
Votes: 0
This is making little sense lol. Look at what happens when you oset it:
obj->pIndexData->value[2] = value;
if ( obj->item_type == ITEM_WEAPON && value != 0 )
obj->value[2] = obj->pIndexData->value[1] * obj->pIndexData->value[2];


Wtf?
23 Sep, 2007, Guest wrote in the 8th comment:
Votes: 0
Heh. Yep. That would certainly add to the confusion. I did wonder why the bonus applications would have made your attack damage so much higher than the max. Someone somewhere got their wires crossed between setting the values and implementing their use. That bit of code there would seem to make it impossible to get what you want without altering it.
27 Sep, 2007, Vladaar wrote in the 9th comment:
Votes: 0
Thanks for pointing out how gay, weapon value system was.

I have quickly commented out the offending ifchecks.


if ( obj->item_type == ITEM_WEAPON && value != 0 )
obj->value[2] = obj->pIndexData->value[1] * obj->pIndexData->value[2];


Thus making it truly run by number_range of value1 to value2

Now making a weapon like this for my Minas Tirith area….

Name: Glamdring Sword of Gandalf
Vnum: 32018 Area: Minas Tirith
Type: weapon Count: 2 Gcount: 1
Serial#: 3826 TopIdxSerial#: 3826 TopSerial#: 3892
Short description: the Glamdring Sword
Long description : A steel long sword has been left here.
Wear flags : take wield
Extra flags: magic bless
Number: 1/1 Weight: 5/5 Layers: 0 Wear_loc: -1
Cost: 0/gold
Color: 8
Rent: 0 Timer: 0 Level: 100
In room: 0 In object: (none) Carried by: Vladaar
Index Values : 12 50 100 1 1 0 100.
Object Values: 12 50 100 1 1 0 100.
Affects mana by 200.
Affects hitroll by 10.

Gives a easier to understand weapon damage value. Now I c 'ident' sword as…


The glamdring sword appears to be a weapon.
It should be held as: take wield
Special properties: magic bless
Its weight is 5 and level is 100.
It cannot be determined what this object is worth.
Damage is 50 to 100 (average 75).
It's edge seems to be as sharp as humanly possible!
Skill needed: 1h Long Blades
Damage type: Slash
Affects mana by 200.
Affects hitroll by 10.


Vladaar
27 Sep, 2007, Guest wrote in the 10th comment:
Votes: 0
I'd almost be willing to call that a bug since it makes it impossible to get a commonly desired result.
27 Sep, 2007, Conner wrote in the 11th comment:
Votes: 0
The only problem with that, is that if you fix it, what's it do to all the weapons that already exist… :tongue:
27 Sep, 2007, Zeno wrote in the 12th comment:
Votes: 0
Actually I do think you can get the desired result. A builder of my managed to do it, sort of.

Quote
Basically… I have to multiple value2 with value1 first.
THEN, I have to rewrite value1 to give it a minimum damage.

Alter value2 even the slightest after editing value1 to set a minimum damage (which is also the multiplier), and you get it thrown to hell
27 Sep, 2007, Vladaar wrote in the 13th comment:
Votes: 0
We are making a areaconvert command to convert all weapons in an area with one command. So no extra finger leather worn here.

Vladaar
Conner said:
The only problem with that, is that if you fix it, what's it do to all the weapons that already exist… :tongue:
27 Sep, 2007, David Haley wrote in the 14th comment:
Votes: 0
Samson said:
I'd almost be willing to call that a bug since it makes it impossible to get a commonly desired result.

I agree with Conner; the results of changing this could be almost disastrous for some MUDs since they've been built around this assumption (knowingly or not) and this would change rather dramatically their weapon damages.

I think it's the kind of bug that has (unfortunately) become a feature. Maybe you could play games with area versions, and add a version flag to the object itself, and the fight/build/etc code could compute the damage range appropriately depending on the versions.
27 Sep, 2007, Guest wrote in the 15th comment:
Votes: 0
That is of course why I said I was ALMOST willing to call it a bug. Sometimes though you just have to let it go.
27 Sep, 2007, Conner wrote in the 16th comment:
Votes: 0
It's a shame really, because technically it's got to have been a bug, the devs couldn't have intended it to be done both ways, and their help file (help object flags) indicates that it was intended to be yet a third way altogether.. but the fact remains that, at this point, every weapon in every area of every smaug based game to date was built around this bugged situation, whether the staff involved knew about it and simply took it into account or just worked around what they expected to be the case due to only realizing one of the three scenarios existed or even just took it on face value from the help file, and no matter how we might try to fix it at this point, all of those weapons are going to suddenly take on an entirely new value meaning. *shrug*

In this case, I think Samson's dead on, sometimes you just have to let it go, this one really is a bug, but it'll cause more problems to fix it than to just acknowledge that it's a known issue.
27 Sep, 2007, Zeno wrote in the 17th comment:
Votes: 0
What I am going to do is simply make a new argument for oset. "oset item value1raw 30".
27 Sep, 2007, David Haley wrote in the 18th comment:
Votes: 0
It's not a known issue or a bug, it's a feature. :grinning:

A good solution would be to update the help files, and leave the code as is.
27 Sep, 2007, Conner wrote in the 19th comment:
Votes: 0
Zeno, that sounds like a good approach to it.

David: Sure, just like all those wonderful undocumented features M$ includes in Windows, right? But yes, in tis case, simply fixing the help file to reflect how it really works is probably the best we can hope for.
27 Sep, 2007, David Haley wrote in the 20th comment:
Votes: 0
Well, what I meant is that it isn't really a bug in the code sense: nothing is really "broken" from a technical perspective. The bug lies in the translation of design docs (and I bet there weren't any) to code. So in a sense, it really is a "feature" in the not quite tongue-in-cheek sense, in that it doesn't break anything except for our preconceptions about how the code is supposed to work.

But all this is far too much analysis for such a simple problem that has such a simple solution. :smile:
0.0/23