Ind Posted November 9, 2012 Posted November 9, 2012 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
Ind Posted November 9, 2012 Author Posted November 9, 2012 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.)
Cookie Posted November 24, 2012 Posted November 24, 2012 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.) I understand the intention behind the change (as Ind pointed out above). It is important to note, there was a few kinks we had to fix as well as odd unintended problems that have arisen from the change. As it stands now, I'd say we leave it as is, and potentially improve upon the current set-up. Originally, I found some problems that I had fixed with Ind in previous commits. I'm going to Dev Only this topic, and if there isn't much developer attention on the issue I will reject it.
Lighta Posted November 24, 2012 Posted November 24, 2012 It's really an improvement for the status in last position on the check, like we could put the less frequent there. I think we should keep it, sure we're not that use too it now and increase debuging but I think it's a good improvement anyway.
Recommended Posts