malufett

hmm..why not use 2012-04-10 instead of 2012-06-18??

what revision are you using? better check this up http://trac.rathena.org/changeset/16738

if this script uses mac address to check for uniqueness per account then no..

@http://svn.rathena.org/svn/rathena/trunk/conf/battle/player.conf // Max armor def/mdef // NOTE: This setting have no effect if server is run on Renewal Mode (RENEWAL) // NOTE: does not affects skills and status effects like Mental Strength // If weapon_defense_type is non-zero, it won't apply to max def. // If magic_defense_type is non-zero, it won't apply to max mdef. max_def: 99

icheck mo kung tama ba nilagay mong IP sa clientinfo..mukhang sa ibang server ka komokonek..chineck mo ba sa server log mo kung may pumapasok na entry pag naglologin ka? or kahit nagreregister? kung wala malamang ibang server IP pinapasok mo..

a better solution is to update your files.. or http://trac.rathena.org/changeset/16085/rathena or do it by your self by changing the data type of def from char to short in source file

Damn..I laugh hard in here..and I sweat too much..lol

if files like the grfs are modified the server can't tell or detect..but if the client itself has been tampered or injected with the dll that is the time the server will knows if the client is modified if just in case the modified client don't have the capabilities to lie to its hash..

Bump for GreenBox ...

+1 hmm..that is why my patches are broke.. hehe..need to recode everything before commiting....

I suggest we dissect each calculations in 'battle_calc_weapon_attack' for more efficient and to avoid redundancy specially if use in a macro(PRE/RE)...and as the RE formula shows it's a totally different from PRE's calculation flow...

+1 well agreed go for it!

Make sure you use unique ID in the enum e_skill @ skill.h better start at the end of the skill OB_AKAITSUKI

don't forget to include this one bonus bFixedCastrate,-100; id,Weapon,Weapon,4,20,,3500,200,,1,1,0x000xxx,2,2,34,4,55,1,3,{ if(readparam(bDex) == 140) bonus bVariableCastrate,-100;bonus bFixedCastrate,-100; },{},{}

this was an official behavior and had been fixed in rA since r16560 and r16567..just revert if you prefer so..

SC_ALL will trigger this one 'status_change_clear(bl, 2);' oh..wait I forgot..type 2 in 'status_change_clear' means remove all buff regardless the settings..sorry.. ok go to status.c and look for 'status_change_clear' declaration then after case SC_L_LIFEPOTION: case SC_PUSH_CART: continue; } add this if( i == SC_PUSH_CART ) continue; so regardless the type it will not remove SC_PUSH_CART

@Napster if this will be the case 'sc_end SC_ALL;' then by default it cannot be remove so nothing to worried about...

hahahaha..but value 0 is more efficient in this case because no need to change its value every time we change MAX_CHARS..

nope..since 0 means unlimited or by default value of MAX_CHARS

"chars_per_account is the number of characters that you can create within MAX_CHARS slots." so nope it's not..

@status.c find this line case SC_ADORAMUS://Arch Bishop if (sd) tick>>=1; //Half duration for players. case SC_STONE: case SC_FREEZE: sc_def = 3 +status->mdef; break; case SC_CURSE: then add tick += 'your desired duration'; after 'sc_def' this will add/subtract the global duration of SC_STONE and take note its in millisecond and don't forget to recompile

because the bonus is dependent on the target's current HP+SP if its even then you receive an additive otherwise its negative..

just modify this one val2 = status_get_lv(bl) / 2 + 50; this means if you have base level of 150 you will have a bonus of 120% and don't forget to recompile...

@status.c case SC_ZANGETSU: if( (status_get_hp(bl)+status_get_sp(bl)) % 2 == 0) val2 = status_get_lv(bl) / 2 + 50; else val2 -= 50; break; modify as you prefer..