defense and offense

[utunnels]

I have been fixing the defense bug recently.

I found the logic had been changed since openbor 3.x was out, so maybe we need a discussion.

The defense factor was planned to be used like the antigravity logic.

Code: [Select]

damage = basedamage * (1.0 + attacker.offense + attacker.model.offense)
totaldamage = damage * (1.0 - target.defense - target.model.defense)
But now it works like this:

Code: [Select]

damage = basedamage * attacker.model.offense
totaldamage = damage *  target.model.defense
So you see the problems: changing one entity means changing all of its type.

First of all, I'm about to transfer the values to entity from model. So it will be like this:

Code: [Select]

damage = basedamage * attacker.offense
totaldamage = damage *  target.defense
This should fix the first problem, but leaves a question: when giving a new model, should the values from the new model be copied to current entity?

For example, there is a player who has a scripted level up bonus, say, it changes current defense factor from 1.0 to 0.8, now he picks up a new weapon, which has a defense factor of 0.9, should the new factor 0.8 or 0.9 or 0.8*0.9 or another value?

Ideas?

[MatMan]

For example, there is a player who has a scripted level up bonus, say, it changes current defense factor from 1.0 to 0.8, now he picks up a new weapon, which has a defense factor of 0.9, should the new factor 0.8 or 0.9 or 0.8*0.9 or another value?

I don't like the idea of the weapon taking over the defense/attack factor. This would suggest that the weapon makes the fighter (The way 99% of d&d games are like, anyone play diablo before). personally I would prefer that it takes the fighters skill into account so something like a half way mark, say about 0.85.

[utunnels]

Hmm, then things go complicated. Some people use weapon to change capabilities,  while others only wants a new look. The weapon feature is never good enough to cover all situations we need.

For backward compatible sake, the safest way is let the engine perform the easy copy job, and add an onmodelcopyscript for those who like exceptions .

The difficult part is the script needs to get both old and new values, unless we add 2 different scripts, one before the copying and one after the copying.

[MatMan]

Lol, I had a feeling you might say something like that.

Then I might suggest with letting the engine take the best/strongest/most beneficial option as I would imagine that the average game would prefer that.

[Damon Caskey]

Yeah, the engine should not have any say in the math, at all. The player is free to do that themselves.

BTW, sorry about the screw up. I'm the one who changed the logic. I meant to simplify the math and make it more straight forward. It's much easier to think Damage = Base * %. I didn't mean to make it model based instead of entity though. Mea culpa.

DC

[utunnels]

It's OK.

I'm thinking about some script additions recently.

One of them is a model copy event driven script. The hard part is get both old and new values from the same entity. Maybe there can be a global dummy entity which can be used to transfer values, like the global drawmethod.