Ind

if anyone can tell me the revision number where they were removed I'd be able to understand the reasons behind that.

whops thanks for letting we know, will get that back.

as per the diff xantara has provided it works on all cases despite how many slots a item has.

hum o.o it appears the documentation still says the unit commands work for mobs while they dont

oh that's most interesting. looks good.

As detailed here: topic:70389 @cart please post your opinion, thank you.

indeed testing stuff with carts is now a pain since they no longer work with @option (since the new carts ain't a option)

how this implements the color on 4-slotted items e.g. say a knife [4]? (as i understand the colours are added by the client to items with stuff in hidden sockets/slots)

yes that can also be a option

we don't have one, not even two, but three "standard" (wat) config parsing subsystems: /common/strlib.c::config_switch stuff (with relatives all over the place within all 3 servers) libconfig (most awful code i've ever seen) /common/raconf.c and thats what I'd like to discuss in this topic, please post all your opinions, my opinion: drop all 3, write a new one with a input similar to libconfig one which is, imo, pretty good-looking and easy to read.

@mkbu95 sent me this early this week, its a great update for the msg_athena system however there is one small detail impeding me from moving on with it and I'd like your opinion about it, it seems the whitespaces are being screwed up at some point (not by his additions to the system, but by something else) which makes many messages layout end up wrong (e.g. @job's one), any ideas? Thank you for your time. atcommand_msg_athena.patch

in the end its not a formula. it's cause in kro they uses a fixed bonus table (while we use a generic formula) for each level/class (daegaladh has been working on a similar implementation for rathena)

none of this is coded. what is coded is rathenas new irc server, but again this feature would be little amount of code, since most of it relies on the irc server (except for the local version but it'd be a very small amount as well)

this thing is over a year old, it was added during rremu as a way to toggle the new mounts w/o the script command however ever since we've been tagging it as /** * For Testing Purposes, not going to be here after we're done. **/ so what do you think should we do about it? do we remove? do we move its functionality to @mount, do we do something else?

During planning we expected not everyone to want their servers chat channels available through other servers, so we did plan for a switch (and therefore a local, version), it however still should be smaller than @main and yet support multiple concurrent channels.

Thank you very much, added in r16669

do any of you got the packets for that specific hp bar?

either way I'm asking because I couldn't think of a place the player ip would be needed script side (whether its a query or this function)

how'd you have it checked? we could create a policy e.g. upgrade files are kept for a range of y revisions (if anyone wants older for whatever reason they can use trac or checkout a older revision of the sql-files folder)

Current: convert_engine_innodb.sql convert_engine_myisam.sql convert_passwords.sql item_db.sql item_db2.sql item_db_re.sql logs.sql main.sql mob_db.sql mob_db2.sql mob_db_re.sql mob_skill_db.sql mob_skill_db2.sql mob_skill_db_re.sql upgrade_svn10575_db.sql upgrade_svn10575_log.sql upgrade_svn10580.sql upgrade_svn11018.sql upgrade_svn11106.sql upgrade_svn11388.sql upgrade_svn11548.sql upgrade_svn11582.sql upgrade_svn11721_log.sql upgrade_svn11895.sql upgrade_svn11915.sql upgrade_svn12043.sql upgrade_svn12278.sql upgrade_svn12294.sql upgrade_svn12368.sql upgrade_svn12464.sql upgrade_svn12559.sql upgrade_svn12561.sql upgrade_svn12581.sql upgrade_svn12725.sql upgrade_svn12975.sql upgrade_svn12975_log.sql upgrade_svn12975_view.sql upgrade_svn13025_log.sql upgrade_svn13115_mercenary.sql upgrade_svn13117_char.sql upgrade_svn13166_mercenary_owner.sql upgrade_svn13370_inventory.sql upgrade_svn13390.sql upgrade_svn13541.sql upgrade_svn13583.sql upgrade_svn13719.sql upgrade_svn13881.sql upgrade_svn13890.sql upgrade_svn13960_questlog.sql upgrade_svn13963.sql upgrade_svn14036.sql upgrade_svn14085.sql upgrade_svn14242.sql upgrade_svn14507.sql upgrade_svn14579.sql upgrade_svn14672.sql upgrade_svn14700.sql upgrade_svn14713_log.sql upgrade_svn14759.sql upgrade_svn14796.sql upgrade_svn14797.sql upgrade_svn15003.sql upgrade_svn15420_log.sql upgrade_svn15519_log.sql upgrade_svn15531_db.sql upgrade_svn15572.sql upgrade_svn15818_log.sql upgrade_svn15885.sql upgrade_svn15926_log.sql upgrade_svn16490.sql upgrade_svn16518.sql upgrade_svn16639.sql upgrade_svn16645.sql upgrade_svn16663.sql Proposal: item_db.sql item_db2.sql item_db_re.sql logs.sql main.sql mob_db.sql mob_db2.sql mob_db_re.sql mob_skill_db.sql mob_skill_db2.sql mob_skill_db_re.sql tools/convert_engine_innodb.sql convert_engine_myisam.sql convert_passwords.sql [*]upgrades/ upgrade_svn10575_db.sql upgrade_svn10575_log.sql upgrade_svn10580.sql upgrade_svn11018.sql upgrade_svn11106.sql upgrade_svn11388.sql upgrade_svn11548.sql upgrade_svn11582.sql upgrade_svn11721_log.sql upgrade_svn11895.sql upgrade_svn11915.sql upgrade_svn12043.sql upgrade_svn12278.sql upgrade_svn12294.sql upgrade_svn12368.sql upgrade_svn12464.sql upgrade_svn12559.sql upgrade_svn12561.sql upgrade_svn12581.sql upgrade_svn12725.sql upgrade_svn12975.sql upgrade_svn12975_log.sql upgrade_svn12975_view.sql upgrade_svn13025_log.sql upgrade_svn13115_mercenary.sql upgrade_svn13117_char.sql upgrade_svn13166_mercenary_owner.sql upgrade_svn13370_inventory.sql upgrade_svn13390.sql upgrade_svn13541.sql upgrade_svn13583.sql upgrade_svn13719.sql upgrade_svn13881.sql upgrade_svn13890.sql upgrade_svn13960_questlog.sql upgrade_svn13963.sql upgrade_svn14036.sql upgrade_svn14085.sql upgrade_svn14242.sql upgrade_svn14507.sql upgrade_svn14579.sql upgrade_svn14672.sql upgrade_svn14700.sql upgrade_svn14713_log.sql upgrade_svn14759.sql upgrade_svn14796.sql upgrade_svn14797.sql upgrade_svn15003.sql upgrade_svn15420_log.sql upgrade_svn15519_log.sql upgrade_svn15531_db.sql upgrade_svn15572.sql upgrade_svn15818_log.sql upgrade_svn15885.sql upgrade_svn15926_log.sql upgrade_svn16490.sql upgrade_svn16518.sql upgrade_svn16639.sql upgrade_svn16645.sql upgrade_svn16663.sql please share all your thoughts. thank you for your time.

awesome malufett *-*

as for the patch just something I think would be changeworthy, in if ( (sd = map_nick2sd(script_getstr(st, 2))) != NULL ) it runs a nick check without checking if the argument is a str, i'd say a script_isstring would be of good use there. the code aside, where do you think this would come in to be useful?

jman masao and other developers have been suggesting something similar to this, added r16656

http://trac.rathena.org/changeset/16651/rathena

http://trac.rathena.org/changeset/16651/rathena there you go.