Leaderboard

New GM, Commands & Permissions system has been added in r15572. Unfortunately, this update is not backwards compatible with previous revisions and requires reconfiguration of existing rAthena installations. This new approach is designed for easy maintenance, increased flexibility and readability. Hopefully it will make up for migration difficulties. General description The whole concept of GMs and non-GMs as well as GM levels has been abondoned in favor of more role- and privilege-oriented player groups. Each account belongs to exactly one group. Player groups are independent of each other, so unless you decide to do so, they don't have to share any privileges like it was with top-down GM level hierarchy. There is, however, a way to say which group is higher, and which is lower: it's group level. Each group has following atributes: ID — unique number name level — it can be interpereted as (GM) level of all group members commands settings — what commands can group members use permissions settings — what other permissions group members have inherited groups — permissions and commands from which groups are inherited log commands — should commands issued by this group be logged or not Groups are configured in conf/groups.conf file. The file itself is fully documented and contains default configuration that should be adjusted to your needs. Details Column `login`.`gmlevel` has been renamed to `group_id`. It now stores ID of the group player belongs to, so you need update your database accordingly. Atcommand configuration file conf/atcommand_athena.conf no longer defines GM levels required to use the command. Permissions to use commands are now defined for each player group separately in group configuration file conf/groups.conf. Command aliases are still being defined in conf/atcommand_athena.conf. File syntax has changed. Import is no longer supported for this file. File is fully documented and contains default aliases that were present in previous revisions. GM configuration file conf/battle/gm.conf no longer defines GM levels required to get some privileges (like trading or partying). See full list of removed settings:These permissions are now defined for each player group separately in group configuration file conf/groups.conf. Player titles defined by conf/battle/gm.conf settings title_lvl1 to title_lvl8 and conf/msg_athena.conf (335~342) are replaced with group names. Removed @adjcmdlvl command. Replaced @adjgmlvl command with @adjgroup, which allows to temporarily (until relog) move player to another group. In login-server configuration file conf/login_athena.conf min_level_to_connect setting has been replaced with group_id_to_connect setting, which allows you to define account group id that is required to connect to server. In char-server configuration file conf/char_athena.conf gm_allow_level setting has been replaced with gm_allow_group setting, which allows you to define group id that is allowed to bypass the server limit of online users. In log configuration file conf/log_athena.conf log_gm setting has been replaced with log_commands setting, which allows you to decide whether commands should be logged or not. Even with command logging enabled, only commands issued by groups that have log_commands set to true will be logged. About group level Group level is used only: when determining if player can override trade restrictions defined in db/item_trade.txt when determining if player can use @command on another player (existing rule that low-level player can not use some commands, eg @kick on high-level player has been kept) or see another player with @who commands (if they have "hide_session" privilege). as a return value for getgmlevel() script command when determining if player can use commands in a map with nocommand mapflag set Other CMakeLists were not updated. If you know cmake and want to contribute, just send me (or other dev) a diff. There were multiple minor changes in this revision. For full list, see rAthena Trac (r15572) or SVN log.

Preamble I have written an achievement system I want to share with you. It is not the best way to solve achievement systems nor is it very efficient(though it might be more efficient than NPC scripting) and if you already have an achievement system(src or npc) and it's working for you, please don't change to mine. Mine is rather old(about half a year or more) and back then it was the first time I wrote something completly new for eAthena. What I did today was applying the system to rA and create a working diff. If you are willing to use this system then I beg you to report any bug found. Also, if there is enough demand, I might consider re-writing it from scratch, because I am overall unhappy with the system, but not really motivated to further work on it in greater detail. Also the code-style I used back then is totally going against the one I am using nowadays... Don't judge me! Functions There are pre-defined types of achievements in this system Monsterkill Achievements Itemfind Achievements (Only use this for Items NOT trade/drop/storage-able, or else it will result in abuse) Itemuse Achievements Explore Achievements Quest Achievements Special Achievements Let me explain them one after another: Monsterkill Achievements(0): Well, name says it mostly, but there is a bit more to it. You can define different types per achievement. The types are counting by ID(0), by size(1), by race(2), by element(3) or for all MvPs(4). And if player A has killed X monsters that meet the requirement, then he gets the achievement. Itemfind Achievements(1): Again, name says what it does. If you find certain items, you get the achievement. Make sure you only use it on non tradeable etc. items or it will be abused. It can also be filtered into types. They are the following: ID(0), Equip(1)[see item_db->equip), Type(2)[see item_db->type]. It will count if you drop it and pick it up again, so really, only use it on items not storageable, tradeable and dropable! Itemuse Achievements(2): Its porpuse is to count every item used. This achievement might be bugged, report anything you find fishy! It uses the same filtering as Itemfind, so please refer to that. Explore Achievements(3): When entering a map, the system checks whether the map is inside the database for explore achievements and if so, it sets the count. If the player visited all maps for one achievement, then he receives the achievement. Quest Achievements(4): When finishing certain quests, you are able to gain quest achievements. Simple as that! Special Achievements(5): This are achievements in the achievement database. But they are only applicable over @achieve from a GM or with the achieve script_command. This achievement has Event porpuses and is only added for a complete database for your website etc. Now comes the technical stuff... How to install the achievement system 1. Download the *.diff and the *.sql file(they are in the *.rar provided). 2. Import the *.sql into your rAthena database. 3. Apply the *.diff onto your rAthena server. 4. Check your ./conf/battle/exp.conf and ./conf/battle/misc.conf: Two new configs have been added: achievement_cutin_duration and achievement_exp_rate. Read the conf files for more information and change it to whatever you wish it to be. 5. Add the two new files ./src/map/achievement.c and ./src/map/achievement.h to your MAKEFILE or to your project solution and recompile! (^ Up to this point, I won't provide ANY support ^) How to add achievements Well, that is mainly why I would like to find another way of solving the achievement system. But currently it is like this: 1. Add your achievement to achievement_db. Here is a brief summary of the columns: If you chose 5 as type, you are nearly done, skip step 2. If you chose another type, please read on. 2. Go to the respective table of your chosen type: 0->mob_achievement 1->item_achievement 2->itemuse_achievement 3->explore_achievement 4->quest_achievement Now add an entry for your newly added achievement. The columns are rather similiar, but I'll explain in greater detail: mob_achievement: achievement_id: Set to ID assigned by achievement_db for your new achievement type: See description of Mobkill Achievements. There are numbers in brackets for each filtering type valueX: The value for what to filter. I.e. if you chose ID, then place an ID here. If you chose elements, place a number from the element enum here (see script_commands or src for reference) amountX: How many to kill itemfind_achievement: itemuse_achievement: achievement_id: Set to ID assigned by achievement_db for your new achievement type: See description of Itemfind Achievements. There are numbers in brackets for each filtering type valueX: The value for what to filter. I.e. if you chose ID, then place an ID here. amountX: How many to find/use explore_achievement: achievement_id: Set to ID assigned by achievement_db for your new achievement mapX: Name of the map. I.e. prontera quest_achievement: achievement_id: Set to ID assigned by achievement_db for your new achievement questX: ID of the quest 3. Last step is to reload the AchievementDB ingame via @reloadachievement or restart your server. Atcommands So, I added two atcommands working together with this System: @achieve <Achievement_ID> <Player_Name>. Give <Player_Name> Achievement with <Achievement_ID> as ID. IT DOES NOT CHECK WHETHER HE MEETS THE REQUIREMENTS! Built in for debugging and special achievements @reloadachievements. Reload the Achievement DBs. Helpfully if you added new achievements and don't want to restart the server. Scriptcommands *Achieve( <AchievementID>{, <Account_ID>}); Same as the Atcommand. If no account_id is given, use attached player. Does also not check if player meets requirements. Intended for special achievements *GetAchievementInfo(<AchievementID>, <flag>); Flag determines what to return: 0 = type, 1 = bexp, 2 = jexp, 3 = nameid, 4 = points, 5 = status 5 Only works with attached players and returns 1 if the player finished the achievement and 0 otherwise. *GetAchievementName(<AchievementID>); Returns the name of the achievement *GetAchievementCutin(<AchievementID>); Returns the name of the cutin of the achievement I think this is about all you need to know. Please report any bugs and post any suggestions. If you overwhelm me enough, I might rework it to be more user-friendly! Only post bugs and suggestions after you've read through the whole article. I will notive if you haven't. At last Download achievement.patch achievement.sql €dit: I really want to stress the following facts again: Read the whole article! Only use if you are unable to script/code a system that is suficient to suit your needs or this system matches your needs perfectly(well, w/e)! Report any found bug! €dit²: Forgot to mention. The last achievement is stored within the permanent playervariable "LastAchievement" and it stores the ID of the achievement. So you can check it via NPC script etc. Changelog: 1.0 FIrst version 1.1 Fixxed bug of not deleting the cutins properly [Thanks Dexter] 1.2 Fixxed cutin bug fully, fixxed typos in config

I made some changes but I am currently too lazy to seperate them. This includes New status ids New cart support Favorite item tab in inventory Status icon for sitting http://www.aegisdev....a/20120213.diff You also need to add a new column to inventory, cart and storage table. ALTER TABLE `inventory` ADD COLUMN `favorite` TINYINT UNSIGNED NOT NULL DEFAULT '0' AFTER `expire_time`; ALTER TABLE `cart_inventory` ADD COLUMN `favorite` TINYINT UNSIGNED NOT NULL DEFAULT '0' AFTER `expire_time`; ALTER TABLE `storage` ADD COLUMN `favorite` TINYINT UNSIGNED NOT NULL DEFAULT '0' AFTER `expire_time`; For Cart Support you need 2012-02-07bRagexeRE client. For Sitting Icon you need 2011-02-23bRagexeRE client. For Favorite Tab you need 2011-11-22aRagexeRE client.

http://rathena.org/tools/login_background/

too heavy borders specially on fonts.... 4/10

you mean when your mouse move to the item ( mouseover ) then it will show the ItemID + Name ?? if yes..then just edit it at your data/idnum2itemdisplaynametable.txt edit every single item together with the ID if you are refering to put the ItemID in the Item Description.. then you have to edit it here data/idnum2itemdesctable.txt there is no shortform i guess.......

You might want to double/triple check that. I just tried: pvp_y_2-2,118,132,4 script Runes 403,2,2,{ using proper tabs between 4, script, runes, and 403, and it loaded just fine. When replaced with spaces, it received the same error as you had (as it should) o.o

Try using [jobtbl.JT_E_TREASURE1] = "E_TREASURE1", in jobname. You defined the spritename "TREASUREBOX_2.gr2" but you used "E_TREASURE1" in the mob_db

Sorry for the wait everyone. Ive been busy with life and other developments. I updated the 1st post with new info and added a V2 download that has updated skill description files, english status icon info, and is fully usable with the "Load Lua Before Lub" diff. Gravity appears to have switched from Lua 5.0.3 to Lua 5.1.4 around December or January and the clients arnt fully diffable. So my focus will continue around this client date for another few months at least. Their's a few things noted that I haven't done yet and probably wont do anytime soon due to busyness. So if anyone wants to work on the things I didn't do yet your welcome to do so.

[ Update ] : Added a Class Restriction Script : Description : This Script allow certain Maps to Block / Restrict certain Job Class. Configurations can be varies across the Maps settings. If the Class that are Blocked entering the Map, the Characters will be warped out from the Map within few seconds after they enter the Map. This Script will be able to answer / solve those below problems. Configuration : Bitwise Table and Usage : // -------- BitMasks -------- // 1 - Normal jobs, // 2 - Adv jobs. // 4 - Baby jobs, // 8 - Normal 3rd jobs. // 16 - Adv. 3rd jobs. // 32 - Baby 3rd jobs. // 64 - Certain Jobs ( Specific ) // ----- Mode Example : ( Blocked Class ) ------ // 63 - All Class that has been defined // 64 - Only the Specific Job you defined // 7 - Normal + Advanced + Baby Jobs // 56 - Normal 3rd + Advanced 3rd + Baby 3rd Jobs Notes : Just add in the Value for the Bitmask. Aware of the Usage of Certain Jobs. --- If you using Bitmask Above , aware of the Limit Reach. ( ~128 Total Class ) --- If your Bitmask = ( 63 + 64 ) , Your "Certain Jobs" have only about 20 Slots. --- Anyway, i dont think you will do so since Bitmask 63 will block most of the Class already. * Common Sense : Make sure the Array ".@Restrict" didnt exceed limit of 128 element. You may edit these below parts... but by default, i have list down most of the Job Class accordingly... // Normal Jobs if( getarg(0) & 1 ) setarray .@Restrict[getarraysize(.@Restrict)],0,1,2,3,4,5,6,7,8,9,10,11,12,14,15,16,17,18,19,20,23,24,25,4046,4047,4049; // Adv Jobs if( getarg(0) & 2 ) setarray .@Restrict[getarraysize(.@Restrict)],4001,4002,4003,4004,4005,4006,4007,4008,4009,4010,4011,4012,4013,4015,4016,4017,4018,4019,4020,4021; // Baby Jobs if( getarg(0) & 4 ) setarray .@Restrict[getarraysize(.@Restrict)],4023,4024,4025,4026,4027,4028,4029,4030,4031,4032,4033,4034,4035,4037,4038,4039,4040,4041,4042,4043,4045; // Normal 3rd Jobs if( getarg(0) & 8 ) setarray .@Restrict[getarraysize(.@Restrict)],4054,5055,4056,4057,4058,4059,4066,4067,4068,4069,4070,4071,4072; // Adv 3rd Jobs if( getarg(0) & 16 ) setarray .@Restrict[getarraysize(.@Restrict)],4060,4061,4062,4063,4064,4065,4073,4074,4075,4076,4077,4078,4079; // Baby 3rd Jobs if( getarg(0) & 32 ) setarray .@Restrict[getarraysize(.@Restrict)],4096,4097,4098,4099,4100,4101,4102,4103,4104,4105,4106,4107,4108; However,.....this is a special case ....... // Certain Jobs ( Specific Your Own Class Restriction ) if( getarg(0) & 64 ) setarray .@Restrict[getarraysize(.@Restrict)],4046,4002,4004,4013,4011; It would be better to Not using Bitwise 64 if your script already block all of the job class above ( Bitwise : 63 ) This is because, the limit might be exceed if you add too much Job Class in the Array for Bitwise ( 64 + 63 ) Anyway, i think it is still Okay to use Bitwise ( 64 + some of the other Bitwise ) ...but not All Bitwise combined. Settings : I guess you should be able to understand this part right ? so, i will skip this parts. // Wait X Seconds before warped out. set .Sec,5; // Lowest GM Level to Bypass set .LowGMLvl,80; Here come the Maps Settings Parts. setarray .Map$, // <Mapname>,<Mode>.... ( Mode = Bitwise Value ) Max of ~64 Map Settings. "prtg_cas01","63", "prtg_cas02","64", "prtg_cas03","3", "prtg_cas04","2", "prtg_cas05","1"; You should be able to realize that....the setting are done in this Format.. <MapName>, <Mode>, ......... <MapName>, <Mode>; the Mode refer to the Bitwise Value ( Blocked Class for the Map ) and the Mode are write within Quotation Mark ( " " ) as a string. refer to above Bitwise Table for how to configure the Bitwise Value for Restrict those Job Class. You may add up to ~64 Maps. Example : "prtg_cas01","63", // --------> Restrict "All" the Job Class ( Except "Certain Jobs" ) "prtg_cas02","64", // --------> Restrict "Certain Jobs" ( Specified by Yourself ) "prtg_cas03","3", // --------> Restrict "Normal & Advanced Job" Class "prtg_cas04","2", // --------> Restrict "Advance" Jobs "prtg_cas05","1"; // --------> Restrict "Normal" Jobs Class Restriction [ Version 2 ] Changelog : Scripts : View ♥ Download Please spend your time to read all the things i have write / mentioned in the post before you asking any questions. if got bug / problems please do report to me.

Hello. I want to inform you of the two new flags in item_trade.txt from r15564. (Please ignore the "(nor mailed/auctioned)" behind flag 1; that's a wrong comment and will be fixed soon.) If an item wasn't dropable (flag 1) it was impossible to send it as mail attachment or sell it via auction, too. We now separated all three flags to be more flexible: Dear server owners, please make sure to check your custom entries when updating your SVN to avoid exploits. ~Kenpachi~

To my knowledge the client is hard coded to support a maximum of 5 carts. They are named as follows: 1. ¼Õ¼ö·¹ (Cart 1) 2. ¼Õ¼ö·¹1 (Cart 2) 3. ¼Õ¼ö·¹2 (Cart 3) 4. ¼Õ¼ö·¹3 (Cart 4) 5. ¼Õ¼ö·¹4 (Cart 5) Each cart is available for use via 'Change Cart' skill. They also have a level requirement: if( level > 90 ) // show 5 carts else if( level > 80 ) // show 4 carts else if( level > 65 ) // show 3 carts else if( level > 40 ) // show 2 carts else //show 1 cart If you wish to add a custom cart what I know remains true is you can create a folder with the following path below: data -> sprite -> ÀÌÆÑÆ® -> cartname files (requires a .act and .spr) *Refer to cart list name for proper sprite names that must be used*. ex.) data -> sprite -> ÀÌÆÑÆ® -> ¼Õ¼ö·¹1.spr AND ¼Õ¼ö·¹1.act (Represents Cart 2) If you go to the rAthena download section and look up some custom carts it will come with a .spr and .act file. Simply rename the act and spr file to one of the cart names that falls in the cart list position. Afterwards compile the data folder with the pathways set above and have that GRF be a higher priority than data.grf so that it loads first in the client. You have successfully over-rided the original carts and now possess custom cart sprites in use. Repeat this for the rest of the cart lists when needed. Other than that, this is the only method i know that works when applying custom carts. Hopefully this answers your question. NO server side work is required for adding custom carts, ONLY client side. I have attached my own custom set of 5 carts. All you have to do is extract the .7z file, compile the data folder in a GRF and use it. Feel free to rearrange them as you like. They are in the order of the following: 1. Poring Cart (Custom) 2. Panda Cart 3. Flower Cart 4. Bloody Cart (Custom) 5. Filir Cart (Custom) data.7z

Time for more detailed description of changes I've done so far. General description: The whole concept of GMs and non-GMs as well as GM levels has been abondoned in favor of more role- and privilege-oriented player groups. Player groups are independent of each other, so unless you decide to do so, they don't have to share any privileges like it was with top-down GM level hierarchy. There is, however, a way to say which group is higher, and which is lower: it's group level. Each group has following atributes: ID — unique number, the same that is used in `login`.`group_id` name level — it can be interpereted as (GM) level of all group members commands settings — what commands can group members use permissions settings — what other permissions group members have inherited groups — permissions and commands from which groups are inherited [*]Groups are configured in 'conf/groups.conf' file. [*]Each account belongs to exactly one group. In `login` table, `level` column has been renamed to `group_id`. [*]In login-server configuration file 'conf/login_athena.conf' "min_level_to_connect" setting has been replaced with "group_id_to_connect" setting, which allows you to define account group id that is required to connect to server. [*]In char-server configuration file 'conf/char_athena.conf' "gm_allow_level" setting has been replaced with "gm_allow_group" setting, which allows you to define group id that is allowed to bypass the server limit of online users. [*]Atcommand configuration file no longer defines GM levels required to use the command. Permissions to use commands are defined for each player group separately in group configuration file. [*]GM configuration file (conf/battle/gm.conf) no longer defines GM levels required to get some privileges (like trading or partying). See full list: These permissions are defined for each player group separately in group configuration file. [*]Player title defined by 'conf/battle/gm.conf' settings "title_lvl1" to "title_lvl8" and 'conf/msg_athena.conf' (335~342) are replaced with group names. [*]Group level is used only: when determining if player can override trade restrictions defined in 'db/item_trade.txt' when determining if player can use @command on another player (existing rule that low-level player can not use some commands, eg @kick on high-level player has been kept) or see another player with @who commands (if they have "hide_session" privilege). as a return value for getgmlevel() script command when determining if player can use commands in a map with nocommand mapflag set [*]Modified GM whisper system to deliver messages basing on permissions, not level. [*]Remote trade request is now possible only if player is allowed to use @trade command as well. [*]Added a proper permission to use /changemaptype command. [*]clif_displaymessage is now capable of displaying multiline messages [*]all ACMD_FUNCs are static now, and the only way to invoke them is with is_atcommand(); all client commands (starting with /) are now translated into corresponding atcommands (with exception of /kick used on monster, as there is no atcommand to kill single monster). List of commands: [*]Removed nonsense "bot check" triggering when player blocked (/ex) Server. [*]Merged @monster, @monsterbig and @monstersmall. [*]Removed @adjcmdlvl command. [*]Replaced @adjgmlvl command with @adjgroup, which allows to temporarily move player to another group. [*]@help command requires "commandname" param and shows more detailed info about commands. Technical details: All occurences of GM level have been replaced either with Group ID (in login and char-server) or Group Level (in map-server). Login-server and char-server are not aware of player groups, they just know the group_id of the account. In map-server group level is used only if there is a need to compare "level" of two players (to preserve the rule that low-level GM can not use commands like @kick on high-level GM), and in script command getgmlevel(). [*]Player groups implementation Player groups are implemented in separate source file and only provide functions to: check if group can use command check if group has permission to do something get group name get group level initialize groups (for server startup) finalize groups (for server shutdown) [*]Player groups use libconfig to load configuration from config file to memory. group permissions are cached and packed in one unsigned int to faster lookup group allowed commands are looked up by name by libconfig API directly from configuration struct inheritance rules are evaluated once, at config load; there is a simple check against inheritance cycles [*]Atcommand changes atcommands use libconfig to load configuration from config file to memory atcommand aliases now use a separate DBMap that points to the same AtCommandInfo structs as original commands [*]"GM" permissions ("can trade", "can party" etc) are defined as enum now. If you're interested in even more details, just ask or wait until I post a diff, which should be ready soon. I need however an opinion on libconfig. It looks like libconfig package for Debian (dunno about other distros) has not been updated in a while, so users will have to compile it from source anyway. So maybe it's better to just link it statically in both Linux and Windows? It's LGPL, so we can include its code in rAthena and change it to GPL.