20 Jul, 2007, Darmond wrote in the 1st comment:
Votes: 0
ok I will try to explain this problem as best I can its not an easy taskt I dont thinkg *scratches his head*

any ways I have taken my skills and set them up to run through the hit function *which I renamed and redesined a slight bit for skills and spells* any ways thing is I dont want all skills to hit the same nore do I want all skills to be the same my goal to add another field somehow to all my skills that adds an accuracy bonus only for that skill to your dice roll.

my general problem is I have no clue where to start to go about this and I was hopeing for some sagestions I was thinking about placeing it right in the skill function itself but have only basic knowledge of code *mostly reading it sadly* and dont know how to make it check the command beeing exicuted for possabole bonuses but there could also be a better way to do this I want it as easaly editabole and versitaile as possabole this way I could make the bonus dependent on more then one variabole and keep it from static

any ways to better convey what I meen I will try an exampole useing kick and punch lets say max accuracy to hit is 100 for eases sake

kick bonus 60
punch bonus 40

so when attacking kick would have a 6 in 10 chance of hitting with its bonus punch only a 4 in 10 this is just the raw chance without factoring in the dice roll

now that is more of a static bonus what I idealy want to be abile to set up is

kick bonus 60 + character levle /10 + skill level / 3
punch bonus 40 + character level / 5 + skill level /2

this would make accuaracy grow with your caracter so that skills dont become obsolite

I hope I was abile to make it clear enough to understand if not I shall try again in the morning as right now its late and I am exhosted from cooking food all day
20 Jul, 2007, Omega wrote in the 2nd comment:
Votes: 0
your doing for skills what I did for spells with my magic_dam function.

skill_level, your level and some funky math = outcome.

For spells, its quite simple, just do a saves check to ensure that they can be affected first, and then simply write the damage algorythm for it.

so if you know that fireball at level 10 does 7-25 damage, then all you do is create a modifier.

case and point, heres how my magic_dam function works.

magic_dam(ch, victim, skillnumber, DAM_FIRE, number_range(7, 25));

really easy right?

inside the function, it reads the save's that the victim has vs spells, and vs that dam-type (ie, fire)

based on their saves (if they are positive or negative) they affect the damage, bringing it up, or down.
so, my mud has a get_saves functor ;)
addition = get_saves(victim, dt); (dt = DAM_FIRE);
damage =+ addition; // if addition is a negative, it will deal with it properly

now, heres where level comes in.
bonus = (ch->level /7)+( get_skill_level(ch, sn) / 3);

now, the bonus is only added on a 'chance' so your real addition to the spell come from the get_saves determination,
however, based on how high of a chance you have (for every point greater then 50%) the bonus is calculated.

SO.. Heres what I mean.

lets say (this is just rough because i don't have the code infront of me at the moment) (or else i'd just post it all)
it does this.

switch (chance)
case 50: case 51: case 52: case 53: case 54: case 55: case 56: case 57: case58: case 59:
damage =+ (bonus /10);
And so on and so-forth till it hits the case 100, where it returns the pure bonus (which can get quite high)

in anycase, its how I did things to make my spell casting different.

I also created a dam_message for spells, so they have different damage messages when they get hit by spells.

If I remember i'll post the whole function tonight when I get home.
14 Nov, 2007, BumpInTheNight wrote in the 3rd comment:
Votes: 0
I'm taking a similar approach and found it was easiest to re-invent the wheel so to speak. Copied one_hit, damage and damage_mes into a seperate file just for clarity and immediately renamed them other names. In my case I have a tree going one_attack->raw_damage->damage_mes.

Now everything that does damage (short of perhaps on-tick poisoning/dying etc) should be funneled through one_attack and here is how I did it:

Made up a structure called attack_data, ala:
struct attack_data
ATTACK_DATA *next; // only used in clean up and recycling purposes, as in putting it into a free pointer list to re-use it like how char_data works
char *string; // A string for the name of the attack, it gets used by damage_mes and in my parry, dodge and shield block functions
long raw_damage; // Unmodified damage, both one_attack and raw_damage modify this as it passes through (sanc, hitting a sleeping victim etc etc)
int damtype; // Used in raw_damage to determine res/vuln/imm flags or however you have that set up.
int raw_accuracy; // your 1-100 range, I also included -1 as being an unavoidable hit
long flags; // I defined ones for parriable and shield block'abe etc, you'll want a flag for magic attack so that one_attack knows to check your saves system against it
OBJ_DATA *obj; // typically the wield weapon but good if you want alternate attacks where an object is involved(dual wield immediately apparent)

Create yourself the appropriate allocation and recycling functions along with defining the struct in your main header (merc.h for Rom), follow any of the _DATA types for examples if you need them.

Now here is the fun part, everywhere you want an attack you'll need to create one of these attack_datas and fill it in, sorta like how affects are handled in the Rom spells, now your one_attack function takes that struct (as a pointer) and uses it for all the variables. Its much cleaner and infinitely expandable. Just make sure that at some point during either one_attack or raw_damage you free it back to the recycled pile to avoid orphaned memory, like right before every return you use.

An example of my acid blast spell:
attack->string=str_dup("acid blast");
attack->defense_flags=ATTACK_DEF_SB|ATTACK_MAGIC; // shield block'able, also this attack is magic so anti-magic defenses are called within one_attack

Inside one_attack you can modify anything to your heart's content, same with raw_damage. If you follow this technique for all attacks and replace the old system you're left with an extremely pliable system where you can adjust base rates within one_attack and raw_damage as your needs suite you.

All the functions and struct data are just what I happened to call them/use in my particular system.

Edit: I also ensured that one_attack was a bool return so that the function that called it could be informed on whether the attack worked so it could then do additional things, like in bash's case it applies the daze state afterwards if one_attack returned true.