Ind

I'm glad you guys liked it enough to merge, however this is a unfair statement, the feature's design was the joint effort from our whole team, not only me.

File Name: Inds @dropaitem (drop-a-item) File Submitter: Ind File Submitted: 23 Dec 2012 File Category: Source Modifications Content Author: Dekamaster/Ind About A @command that can drop a item in the floor for as much time the user wishes (great for events, as long as you have no porings around ) Usage @dropaitem <item name or ID> <duration in seconds> Credit Original idea by Dekamaster. Redesigned and coded by me. Support Drop me a PM Click here to download this file

File Name: Inds Sekai 5 Bonus Pack #2 File Submitter: Ind File Submitted: 23 Dec 2012 File Category: Source Modifications Content Author: Ind About Includes 5 custom bonuses, bIndDispellDeflect, bIndHealMaxHPBoost, bIndPerfectDodgeIgnore, bIndAtkElemBoost and bIndAspdLimitIncrease Usage Example 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndDispellDeflect,30; },{},{} Grants the user 30% chance to deflect incoming dispell back at the caster 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndHealMaxHPBoost,50; },{},{} Boosts the user's AL_HEAL skill by 50% of the targets maximum HP (if you normally heal 1.000 and your target has 1.000 HP the final heal would be 1.500) 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndPerfectDodgeIgnore,70; },{},{} Grants the user 70% chance to bypass the target's perfect dodge 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus2 bIndAtkElemBoost,Ele_Fire,50; },{},{} Causes the user's fire attacks to do additional 50% damage. 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndAspdLimitIncrease,1; },{},{} Increases the user's maximum ASPD limit by 1, if limit is 190 that character's unique limit becomes 191. (maximum this boost can get to is 199) Support Drop me a PM Click here to download this file

File Name: Inds Sekai 5 Bonus Pack #1 File Submitter: Ind File Submitted: 23 Dec 2012 File Category: Source Modifications Content Author: Ind About Includes 5 custom bonuses, bIndMatkEvasion, bIndDispellResist, bIndSelfDmgOnSpell, bIndAnkleSnareImmunity and bIndNoNinjaOrbReq. Usage Example 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndMatkEvasion,25; },{},{} Grants the user 25% chance to evade magical attacks 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndDispellResist,50; },{},{} Grants the user 50% chance to resist dispell casts 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus2 bIndSelfDmgOnSpell,"MG_FIREBOLT",25; },{},{} Causes the user to receive 25 non-reduceable damage when casting fire bolt 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndAnkleSnareImmunity,1; },{},{} Grants the user immunity to ankle snare traps 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus bIndNoNinjaOrbReq,1; },{},{} Grants the user (e.g. a ninja) the ability to cast ninja skills without the necessary orbs Support Drop me a PM Click here to download this file

File Name: Inds bIndOnAtkCast Bonus File Submitter: Ind File Submitted: 23 Dec 2012 File Category: Source Modifications Content Author: Ind About A bonus that allows an item to cause the user to cast a specific skill upon attack (instead of attacking). Usage Example 1601,Rod,Rod,4,50,,400,15,,10,3,0x00818315,7,2,2,1,1,1,10,{ bonus2 bIndOnAtkCast,"WZ_FIREBALL",5; },{},{} The above gives rod a attack range of 10 cells, and causes the user to cast WZ_FIREBALL Lv 5 when they try to attack It works with all skills/types. Support Drop me a PM Click here to download this file

looks good

Applied as per the criteria here suggested by you guys: r16936

but va_list type is also system dependent at times it is a pointer, at times it isnt: (be aware its 5am i might have missed something D: bear with me) #if defined(__PPC__) #if defined(__NT__) typedef char * __va_list; #else typedef struct { char __gpr; char __fpr; char __reserved[2]; char *__input_arg_area; char *__reg_save_area; } __va_list; #endif #elif defined(__AXP__) typedef struct { char *__base; int __offset; } __va_list; #elif defined(__MIPS__) typedef struct { char *__base; int __offset; } __va_list; #elif defined(__HUGE__) || defined(__SW_ZU) typedef char _WCFAR *__va_list[1]; #else typedef char *__va_list[1]; #endif it appears my table from above is outdated; I've used gdb to take a look at my current one and its like this (not like any of the above): ap = {{ gp_offset = 24, fp_offset = 48, overflow_arg_area = 0x7fff5fbfc500, reg_save_area = 0x7fff5fbfc400 }} I've found some more about the above one in Apple's Darwin stuff: http://opensource.apple.com/source/cc/cc-798/cc/ginclude/va-ppc.h

After some tests I realized va_arg moves the va_lists' internal offset whenever you retrieve a arg (moves equivalent to the size of that arg), so indeed the va_start must be re-run (we can't simply zero the offset because the offset field is platform-dependant). I'll move the va_list outside the loop as you suggested

reviving this as proposed over #rdev; One thing I'm highly uncomfortable with: PACKET(PKT_MC_CUTIN) pkt = { PKT_MC_CUTIN }; since each packet version has its own code and length/sizes for its vars (e.g. check the inventory_list1/2/3 crap) I'd like to propose we use the packet id in the name e.g. struct packet_0xf5 { char offset[5]; uint32 item_oid; }; .... func() { struct packet_0xf5 p; p.item_oid = 1; }

they were never passive (ever since we added homun-s units, months ago) -- the server would output a message if you tried to use ones that werent fully implemented. if you see them as passive it is your game client fault, not rathena.

I agree it should be optional, however if the name is already in use I think the command should fail instead -- you may not want to create a warp with a random name.

you dont need to remember it, gms can right-click npcs to unload them -- alternatively right clicks also lists the name of any npcs you click.

Map Server [info]: Initializing random number generator. [info]: Logging item transactions to table 'picklog'. [info]: Logging commands to table 'atcommandlog'. Char Server [status]: rAthena server has been initialized [info]: Reading configuration file conf/import/char_conf.txt... [info]: Done reading conf/import/char_conf.txt. [info]: Done reading conf/char_athena.conf. [info]: Reading the configuration file conf/subnet_athena.conf... [status]: Read information about 1 subnetworks. [info]: Reading file conf/inter_athena.conf... [info]: Reading file conf/import/inter_conf.txt... [info]: Done reading conf/import/inter_conf.txt. [info]: Done reading conf/inter_athena.conf. [info]: Finished reading the char-server configuration. [info]: interserver initialize... [status]: set char_server_ip : 127.0.0.1 [status]: set char_server_port : 3306 [status]: set char_server_id : ragnarok [status]: set char_server_pw : ragnarok [status]: set char_server_db : ragnarok why does it waste time outputting the ones it aint using?|: or" why output any of that info at all [info]: Finished reading the inter-server configuration. [info]: Initializing char server. [info]: Begin Initializing....... [info]: Finished initilizing....... [info]: char server initialized. [info]: End of char server initilization function. [info]: open port 6121..... whats the point of the above when it got the following (which is output right after them) [status]: The char-server is ready (Server is listening on the port 6121). Login Server [info]: Reading configuration file conf/inter_athena.conf... [info]: Reading configuration file conf/import/inter_conf.txt... [info]: Finished reading conf/import/inter_conf.txt. [info]: Finished reading conf/inter_athena.conf. [info]: Reading configuration file conf/import/login_conf.txt... [info]: Finished reading conf/import/login_conf.txt. [info]: Finished reading conf/login_athena.conf. [info]: Reading the configuration file conf/subnet_athena.conf... [status]: Read information about 1 subnetworks. [info]: Initializing random number generator. [info]: Using account engine 'sql'.

I vote yes because it'd allow us to throw in the garbage the current (and ancient -- and HIDEOUS) way to change a mobs size //FIXME: This implementation is not stable, npc scripts will stop working once MAX_MOB_DB changes value! [skotlex] if(data->class_ > 2*MAX_MOB_DB){ // large/tiny mobs [Valaris] data->state.size=SZ_BIG; data->class_ -= 2*MAX_MOB_DB; } else if (data->class_ > MAX_MOB_DB) { data->state.size=SZ_MEDIUM; data->class_ -= MAX_MOB_DB; }

aah o-o minicore ifndef is used by the mapcache (and previously the converter stuff), i think there is little point on keeping it

if (sc->count && ( sc->data[sC_ANKLE] || sc->data[sC_AUTOCOUNTER] || sc->data[sC_TRICKDEAD] || sc->data[sC_BLADESTOP] || sc->data[sC_BLADESTOP_WAIT] || (sc->data[sC_SPIDERWEB] && sc->data[sC_SPIDERWEB]->val1) || (sc->data[sC_DANCING] && sc->data[sC_DANCING]->val4 && ( !sc->data[sC_LONGING] || (sc->data[sC_DANCING]->val1&0xFFFF) == CG_MOONLIT || (sc->data[sC_DANCING]->val1&0xFFFF) == CG_HERMODE )) || (sc->data[sC_GOSPEL] && sc->data[sC_GOSPEL]->val4 == BCT_SELF) // cannot move while gospel is in effect || (sc->data[sC_BASILICA] && sc->data[sC_BASILICA]->val4 == bl->id) // Basilica caster cannot move || sc->data[sC_STOP] || sc->data[sC_CLOSECONFINE] || sc->data[sC_CLOSECONFINE2] || (sc->data[sC_CLOAKING] && //Need wall at level 1-2 sc->data[sC_CLOAKING]->val1 < 3 && !(sc->data[sC_CLOAKING]->val4&1)) || (sc->data[sC_CAMOUFLAGE] && //Must be against a wall on level 1. Cant move on level 1 and 2. sc->data[sC_CAMOUFLAGE]->val1 < 3 && !(sc->data[sC_CAMOUFLAGE]->val3&1)) || sc->data[sC_MADNESSCANCEL] || (sc->data[sC_GRAVITATION] && sc->data[sC_GRAVITATION]->val3 == BCT_SELF) || sc->data[sC_WHITEIMPRISON] || sc->data[sC_ELECTRICSHOCKER] || sc->data[sC_BITE] || sc->data[sC_MAGNETICFIELD] || sc->data[sC_THORNSTRAP] || sc->data[sC_CRYSTALIZE] || sc->data[sC__MANHOLE] || (sc->data[sC_FEAR] && sc->data[sC_FEAR]->val2 > 0) || sc->data[sC_DEEPSLEEP] || sc->data[sC_VACUUM_EXTREME] || sc->data[sC_CURSEDCIRCLE_ATKER] || sc->data[sC_CURSEDCIRCLE_TARGET] )) return 0; became if( sc->cant.move /* status placed here are ones that cannot be cached by sc->cant.move for they depend on other conditions other than their availability */ || (sc->data[sC_FEAR] && sc->data[sC_FEAR]->val2 > 0) || (sc->data[sC_SPIDERWEB] && sc->data[sC_SPIDERWEB]->val1) || (sc->data[sC_DANCING] && sc->data[sC_DANCING]->val4 && ( !sc->data[sC_LONGING] || (sc->data[sC_DANCING]->val1&0xFFFF) == CG_MOONLIT || (sc->data[sC_DANCING]->val1&0xFFFF) == CG_HERMODE ) ) || (sc->data[sC_CLOAKING] && //Need wall at level 1-2 sc->data[sC_CLOAKING]->val1 < 3 && !(sc->data[sC_CLOAKING]->val4&1)) ) return 0; it basically reduced the amount of status the server checks whenever any unit (player/mob/etc) attempts to move a single cell (-- you move 10 cells, it is run 10 times.)

"MINICORE" as it is defined in over a dozen locations within the source, are there any reasons not to purge it? I'm asking because I myself have little clue why that thing was coded in the first place

I find it to be the worst thing I've ever put into rAthena, it sure is an performance improvement however whenever I look at it I feel its incredibly unpractical and perhaps even confuse, which makes me wonder whether we should revert/purge it. I'd like to hear the opinion of each one of you

for no particular reason at ~4:20 am i stumbled upon http://svn.netlabs.org/repos/gl2/include/cstdarg and then realized all the va_stuff business rathena makes use of in all map_foreachin<whatever> procedures, for instance: map_foreachinmap for(i=blockcount;i<bl_list_count;i++) if(bl_list[i]->prev) { va_list ap; va_start(ap, type); returnCount += func(bl_list[i], ap); va_end(ap); } wouldnt va_list ap; va_start(ap, type); for(i=blockcount;i<bl_list_count;i++) if(bl_list[i]->prev) { returnCount += func(bl_list[i], ap); } va_end(ap); be way more efficient? the arguments being passed are never changed during the loop, whats the point in recreating the damn thing bl_list_count times?

its far more evasive than the stat reporter, and at most cases pretty pointless -- there is little to no useful information it outputs prior to crashing.

I understand it was designed to be thread safe, but at its current stage it is not -- nevertheless you have a good point.