[Status Change Issue]

I'm all for this, I've been trying to get L0ne to commit the same thing for a while now, however I'd like to note that any statuses which are being displayed in the client and running into negative values are not meant to display the timer tick. In the LUA file, it is possible to disable the time display timer and according to some testing done it shouldn't be visible. So if we implement the 'status timer' fix, it will be unofficial since the statuses shouldn't even be showing the timer

[REMOVED]

@Keenan: You need to learn to start debugging scripts instead of relying on everyone to post up the fixes. It was a simple typo:

if (distance(.@px, .@py, .@nx, .@xy) < 5) {

Should be:

if (distance(.@px, .@py, .@nx, .@ny) < 5) {

[[Guide] Syouji's BrowEdit Tutorial Videos]

The adding the sky map tutorial seems slightly familiar excellent job Brandon, truly useful to all!

Oh and I thought I should mention this, the 'wither' map in the sky map tutorial is the one you made for me for the Withering quest it's a custom, lol.

[how to prevent item consumption when status is active]

If you were to try Shinryo's code, you'd need to change the item type to '11' and set the item script to:

{ if( !getscdata(SC_EXPBOOST) ) { sc_start SC_EXPBOOST, 1800000, 25; delitem 14532, 1; } }

[how to prevent item consumption when status is active]

That's probably something that should be optimized anyway. It's not a good idea to hard code such information. Your approach is correct Epoque, it's just that this kind of things have been handled the wrong way from the start and there is no other way to solve this.

A better idea is to add new script commands that allows to check for some status changes and behave accordingly. Here's an example (which hasn't been tested though):

BUILDIN_FUNC(getscdata)
{
struct map_session_data *sd = NULL;
int sc_type = script_getnum(st,2);
if(script_hasdata(st,3))
 sd = map_nick2sd(script_getstr(st,3));
else
 sd = script_rid2sd(st);
if(sc_type >= 0 && sc_type < SC_MAX && sd && sd->sc.data[sc_type])
{
 struct status_change_entry *sce = sd->sc.data[sc_type];
 pc_setreg(sd, reference_uid(add_str("@scdata"), 0), sc_type);
 pc_setreg(sd, reference_uid(add_str("@scdata"), 1), sce->timer);
 pc_setreg(sd, reference_uid(add_str("@scdata"), 2), sce->val1);
 pc_setreg(sd, reference_uid(add_str("@scdata"), 3), sce->val2);
 pc_setreg(sd, reference_uid(add_str("@scdata"), 4), sce->val3);
 pc_setreg(sd, reference_uid(add_str("@scdata"), 5), sce->val4);
 script_pushint(st, 1);
 return 0;
}
script_pushint(st, 0);
return 0;
}

In combination with an exp manual, the item script would look like this:

14532,Battle_Manual25,Field Manual 25%,2,,,10,,,,,0xFFFFFFFF,7,2,,,,,,{ if(!getscdata(SC_EXPBOOST)) sc_start SC_EXPBOOST,1800000,25; },{},{}

This approach does not only benefit from being more flexible. It also allows scripts to use the newly created script commands.

You can check other players for status changes, how long the status will remain, etc. It will simply fill the @scdata array with those information.

Or have I missed something and didn't take it into account?

Agreed, it's certainly been one of those things eAthena has just kind of stuck together for a long time. In my expansion system that was on sale, I ended up creating a command just like that to accommodate items and scripts easier

[how to prevent item consumption when status is active]

Go into map/pc.c and find:

case 14592: // JOB_Battle_Manual
    if( sd->sc.data[sC_JEXPBOOST] )
         return 0;
    break;

Below add:

case 25000:
    if( sd->sc.data[sC_CUSTOM_STATUS] )
         return 0;
    break;

Edit accordingly and recompile afterwards

[[SRC] Smith Armor]

The whole adding of the function itemdb_isequiptype seems a bit pointless. You only used it once:

} else if(itemdb_isequiptype(nameid) == 1){

So you might as well remove the function and just run:

} else if( itemdb_type(nameid) == IT_WEAPON ) {

Otherwise, nice idea

[Hi !]

Pow, right in the kisser.

Good job guys.