Post: #1

This week I'm taking a look on sphere internal combat engine to make many optimizations/improvements, and for my surprise, I found an reasonable big code about some features that honestly I think it must be done by scripts and not hardcoded:

1. the COMBAT_TARGETTEDHIT setting on sphere.ini, which will force the char hit an targetted region of the body (head/foot/...)
2. the internal "hit location" messages, which are just messages like "You hit someone on the head/foot/..." and doesn't make any difference on the real damage
3. the old [Physical/Fire/...]DAMAGE behavior which add an aditional damage for each *DAMAGE used. Note that we already have a new DAM[Physical/Fire/...] which this one works correctly as it should be, it will split the base damage into different types and use RES[Physical/Fire/...] to resist each one. The idea is remove the old *DAMAGE and use only the new DAM*
   

I think these 3 features can be removed from the internal source, it will make the combat code much more clean and optimized (in other words: lightweight / fast), and if someone still want these features, it can be done on script-side without any problem. The main idea is optimize the code making it lightweight, and if someone want aditional damages, formulas, etc, it can be done using scripts

so the question is: someone still using these features? If yes, there's any problem to move it from hardcoded to scripts?

Post: #2

Maybe this is not related:
In the @gethit trigger, ARGN1 holds the value of the "raw damage" (in the case of physical damage, that's the damage before armor calculation), it will be possible to get the "real damage" (so the one that appears in the pop-up damage above the character) in a new trigger/variable?

The current "work-around " for this, is to apply dam_god or dam_fixed to argn2 in @gethit.

Post: #3

I don't care about this hardcoded thing.

My combat systems always have ARGN2 = 01 (dam_god) which means I control the real damage applied on the chars.

Also the targeted hit system is useless. I never ever seen this system working in any shard I played before.

But these stuff should be moved to scripts, yes.

Post: #4

yep, on the new engine @GetHit will return the real damage value on ARGN1 (instead return the base damage before apply any bonus/armor calculation). Also the client status gump will show the real damage that the char can deal (instead show only the base damage), and some others improvements

Post: #5

Wait, you gonna change the @GetHit?

Please, don't mess with it! If the 'problem' is the targeted hit, just remove this. Don't change how @GetHit works.

Post: #6

Yes for avoding conflicts the "real damage" should be held in another variable in @gethit (argn3 ? or a new local? or maybe a completelly new trigger that fires after @gethit ? Or a ini flag ?)

Post: #7

the combat engine have 2 parts: one calculate the attack damage (@Hit), and the other one (@GetHit) will apply armor calculation over this damage -already defined before- by @Hit

but the problem of the current engine is that it doesnt follow this rule, it still calculate the damage value even when applying the armor calculation (where the damage value must be already set, not in progress), and @GetHit is called even when the armor calculation still unfinished

so the only difference is that @GetHit now will be called at the right moment (after the armor calculation, and not before), nothing more. The real damage -before- armor calculation still fully acessible on @Hit, which is where all damage values are calculated. And @GetHit will just apply armor calculations over this damage value already defined before on @Hit

the call sequence is something like this:
1) sphere does all damage calculations and call @Hit (ARGN1 is exactly the real attack damage including all damage bonuses)
3) now apply armor calculations and call @GetHit (ARGN1 is exactly the final damage that the char will get)

Post: #8

Really, leave this. Don't messy the system.

Post: #9

I actually like the idea, what about adding a flag in the .ini for keeping/enabling the old/new behaviour ?

Post: #10

(01-20-2015 10:20 AM)darksun84 Wrote:  I actually like the idea, what about adding a flag in the .ini for keeping/enabling the old/new behaviour ?

since no behavior was really changed I think we doesn't need new flags, all changes are just improvements/optimizations

if you like the "old" sphere internal engine, it will be the same as always, but now running on a fast and lightweight code. And if you're using new combat features (COMBAT_USE_RESISTANCE, COMBAT_SPECIALDAMAGE and COMBAT_OSIDAMAGEMOD) it will be the same as always too but much more improved

(01-20-2015 10:07 AM)Extreme Wrote:  Really, leave this. Don't messy the system.

what kind of behavior do you use on @GetHit? maybe I can explain it better, there's no need to worry since this wont break anything