Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 03/03/13 in all areas

  1. Hello everybody, Just a Better (intuitive) Log System Problem In my life of server administration always happened a few episodes where I had to check the logs and this always was a so boring task. Despite the caution, I had problems with players beign hacked (stolen their items) and even corruption of GameMasters. So I decided to spend some good time (I do not have much experience with the source of rAthena) to make a better system logs, so I can solve all kinds of problems (hacking, GM corruption, Bug Abuse, etc.) quickly and efficient. Solution In this system I improved some things and I left these things the way I initially had idealized the logs (in a more intuitive way), I'll try reporting the changes for each transaction: 1. A General View -- Trade/Vending/Buying Store/Mail Very simple, the new values of the row (related_char_id, related_account_id) is the another player of the trade/vending/buying store. -- Pick In every player Pick (type = 'P') the (related_char_id, related_account_id) can be another player or a mob (both columns = mob_id). It varies between who primiraly dropped the item to the floor: A player or a mob (when the mob die). -- Auctions In every auction transaction will be a info code to help you to discover what's going on! Later I will explain each code. -- Loot Mobs can loot items, when this happens will be a row with type='L'. Related_ids of this row is the item origins (a player or another mob, is who primarily dropped the item). -- Drop When a mob or player drops an item, it's still not related to anybody because we can't know who WILL pick the item. So in this case related_ids = 0. -- Scripts/NPCs If a NPC give/delete a item, the row column related_npc_name = npc name. -- Stolen/Mvp prizes It are in essence equal to mob drop, and works just like this one. 2. Explaining better some features These are the features that give me the harder work to make. It's hundreds of lines changeds in the source, but I think it's worth. The Drop/Pick System is a little complex, and I explain above how it works, but if you don't want to know everything you can just jump this section! -- Trade/Vending/Buying Store Very simple, the new values of the row (related_char_id, related_account_id) is the another player of the trade/vending/buying store. -- Drops/Picks Improved To understand this improvement well, you need to know that the emulator handles in different way the actions of: Mob drops a item (type='M') and Mob drops a looted item (type='L', amount negative). Also there's an operation where Mobs Loot a item (type='L', amount positive). But let focus on the informations that will be provided on the log rows, and how the system works: - Mob drop an item (type='M') Main ID is the mob_id. Item origins are setted=mob_id. Related_IDs = NULL. The monster dies and drop the item to the floor. - Player drop an item (type='P', amount negative) Main ID is the player. Item origins are setted=player_id. Related_IDs = NULL. The player just dropped the item to the floor. - Mob Loot an Item (type='L', amount positive) Main ID is the mob_id. Item origins aren't changed. Show item origins in related_IDs (can be a mob_id or a player_ids). - Mob Drop an Looted Item (type='L', amount negative) Main ID is the mob_id. Item origins aren't changed. Show item origins in related_IDs (can be a mob_id or a player_ids). - Player Pick an item (type='P', amount positive) Main ID is the player. Show item origins in related_IDs (the player who dropped) or (the mob_id that dropped the item). NOTE: Here is when you know the source of a player pick. So as i said: A player can't pick another player item without making a trace in related columns. More properly speaking, a player can't pick a item without you know the REAL SOURCE that primarily put it on the floor. - Mail In this system, mail transactions are full logged with related player that send and receive items/zeny on attachments. - Extra info on Auctions (and other systems that use mail_sendmail). New parameter send_is_NPC: Field of NPC Name will be logged. Alter on sender_id: If send_is_NPC is true, can use it to log a Related Player to this transaction. New parameter extra_log_info: If send_is_NPC is true, this string will be added on the end of npc_name_related on the logs. Extra info on NPC NAME of Auctions: "#0": new auction created, "#1": auction ended by time, "#2": auction ended by seller, "#3": auction ended by buy now, "#-1": auction canceled by seller, "#-2": auction no buyers, "#-3": auction {returned} bids, "#-4": auction failed by techinical error. - Other Systems that uses mail_sendmail() If you have a mod in source that uses mail_sendmail() you can add the new parameters (send_is_NPC, extra_log_info) to put information that you can view later on LOGs. And also, you can turn send_is_NPC=ON and use sender_id param to LOG that transaction binding a player to that transaction as a sender. Imagine that: A NPC system (that uses mail_sendmail()) that the GMs uses to give rewards to players in events, so you can call mail_sendmail() with send_is_NPC=true, sender_id=acc id of GM, send_name = "Event Rewards", extra_log_info = "". And all will be fine. In mail picklogs the GM CID and AID will be logged as related. 3. Tables PickLog Table 4 New columns: account_id: just the account_id of the player who triggered this picklog. related_char_id and related_account_id: These are the fields that will represent a person related to that transaction picklog BUT not the main person. (The other person in the trade, sale, mail, etc.). If is a pick from original mob drop (mob die and drop-NOT LOOT), it will be both = mob_id. related_npc_name is used when a npc is related to the transaction (name of the npc). Note: In transactions where there's no other player/npc/mob related, these related_values will be just 0 or a empty string. IDs 5-6: Trade IDs 8-7: Vending IDs 9-10: PlayerA drop and then playerB pick. IDs 15-18: PlayerA drop, mob(1153) loot, PlayerB pick. IDs 19-23: mob(1153) drop, mob(1177) loot, player pick. IDs 58-59: NPC buy/sell IDs 67-70: PlayerA make mr.smile quest IDs 71-72: Mob drop, player pick. IDs 79-81: Weapon Refine Skill IDs 109-110: mob 1159(phreeoni) 'drop' mvp prize item, playerA pick. IDs 112-113: PlayerA send mail, PLayerB pick attachment. IDs 116-117: Auction Started, Auction finalized (no buyers in time). IDs 122-121: BUying Store. ID 123: PlayerA atcommand "#item playerB poring_card" ZenyLog Table 4 New columns: account_id: just like picklog. (main player who triggered zenylog) related_char_id and related_account_id: just like picklog. (another person/mob related) related_npc_name just like picklog. (npc related) The transactions Trade, Vending, #Zeny, Mail, Auction, Buying Store create a related_ids to the another player in the transaction. Buy/Sell and "set Zeny, x" are NPC-Related so related_npc_name will be = the related npc name. (oh rly!?) Example: ID 1: Kafra "set Zeny, Zeny - 820" -> Cart Rental IDs 2-3: Trade IDs 4-5: Vending IDs 6-7: Zeny Knife granted zeny IDs 9-10: Buy/Sell on NPC IDs 12-13: Loss zeny on skills IDs 17: PlayerA sent a mail to playerB with zeny attached IDs 19: PlayerA started a auction a pay the fee. IDs 20-21: Buying Store AtcommandLog Table There are very few modifications in this table. Just the related_ids that are used when someone uses a #command that affects another player. So, related_ids = who typed #command. ID 191: Rafa2 gives card to Merchant player. -> Related info! ID 216: Rafa2 picks a card to himself ID 217: Rafa2 gives zeny to Merchant player -> Related info! ID 220-221: Rafa2 uses #command but to himself, no related info. #Commands also works well with picklog and zenylog, as you can see on the screens: Pick: Zeny: Note: If playerx types #zeny playerx 1000 the related_ids should be = 0, because in this case it's just not related to someone else. ChatLog 2 new fields: dst_charid, dst_accountid. As the name says, it's the player who received the whisper message (to others types of message it's = 0). SQL Indexes I also added some very useful indexes IMO on sql logs to make the select queries faster (I know that it make the insert slower), but when you have a 4 GB picklog DB it's better to have some CPU Cycles lost everytime than can't make queries without mysql going to 99% CPU utilization. If someone knows better about indexes optimization I can edit this to get a better performance to all of us 4. Download I would recommend to do a manual diff apply, it's not a big deal for who know. For download, there's a one that is completely based on rAthena 17170. Improved Logging System v1.2 rAthena.diff And another to eAmod-rAthena r49. Improved Logging System v1.2 _eAmod.diff SQL mail modified table: improved_log_mail.sql Logs SQL Modifieds tables: improved_logging_system.sql Maybe it's best you download a new revision of 17170 rAthena locked in, apply the patch and then update the SVN. Because are many changes in source, edit it is boring (I did twice and I'm very tired). 5. Changed Functions (how to handle with the new parameters!) I do not intend to update this code often to be laborious. I changed the code in much the second parameter of the functions, I did it because if there is something wrong it will generate compilation errors more easily. Compilation errors are your friends! So you can see where the error is and fix, which is much better than having a bug and do not know where to fix it. But I will not leave you in deep shit and above are the modified functions and how to handle with them: typedef struct // Improved Logging System [rafoka] { /* field // equivalent on SQL row */ int type; // int int1; // `related_char_id` int int2; // `related_account_id` char str1[40]; // `related_npc_name` } Related_Log_Info; typedef enum e_log_improved_system // Improved Logging System [rafoka] { LOG_RELATED_NOTHING = 0, LOG_RELATED_PLAYER = 1, LOG_RELATED_NPC = 2, LOG_RELATED_MOB = 3, LOG_RELATED_OTHER = 4, LOG_RELATED_PLAYER_BUT_SD_OFFLINE = 5, LOG_RELATED_LOOT = 6, LOG_RELATED_CUSTOM_MAIL = 7, LOG_DO_NOT_LOG = -1, } e_log_improved_system; Explanation: This struct is used to keep the related_values (who is related to that transaction) and it's passed by function to function until get on the log_pick/log_zeny/log_atcommand functions, that saves in SQL all the row and uses Related_Log_Info. IF your transaction don't have a related object (player, npc or mob) you can just put NULL on a function that receives Related_Log_Info* as argument (it's safe to!). Explanation: The related_log_infos is obviously: It is to receive the info to fill the (related_ids and related_npc_name) on the SQL rows. Explanation: It's explained in the text: send_is_NPC is a flag to custom mails (not ordinary mails sended by players) and extra_log_info is a optional argument that writes a little extra text on Log ROws when the player picks the attachment of this mail. Explanation: All the cases are already handled I don't think do you need to edit any of this. You can just put NULL because these functions are used only when mails are failed to be sent. There is just one time when we need to use mail_removeitem(sd,&info,1) in the place of common mail_removeitem(sd,NULL,0) and it's of course already handled in the diff. mail_getattachment() is when the player will pick the item so you always need to call this function with info correctly setted, actually it's handled on the diff but we don't know, the things can just change. Explanation: If there's no one object related to the transaction (player, mob or npc) you can just put NULL on these parameters. If there's a object (but not the main player) that is related to that transaction so you need to create a Related_Log_Info object and set the related object informations using make_related_log_info() and then call the function with all information correctly setted on the Related_Log_Info. There's a lot of examples on the DIFF. This varies if is a player, mob or npc. If If I'm not mistaken, pc_cart_delitem(sd,&info..) is only used on vendings and pc_setparam(sd,&info...) is only used to "set Zeny" in scripts. Functions that are your friends If someday you want to create a new transaction or the SVN Update just created a new transaction on the source and you want to fill the related_Columns of this transaction so you can use these functions. There's a lot of examples in the DIFF on how to use it. If it's related to a mob, char_id and account_id = mob_id, if it's related to a npc, char_id and acc_id = 0 and npc_mob_name = name of npc. The 1st function catch info of log and put on the Related_Log_Info, the second just fill the Related_Log_Info with NULL (but sometimes it's needed to avoid crashs). Data structures changed When in the source you drop a item (map_addflooritem), you need to use droppedBy_charid and droppedBy_accid to write who dropped the item (or the mob). Soo.. that's all folks! I worked hard here so that everyone who wants to use the system, able to do this. And use it without any problem in the future (or few problems) and being able to edit something from the source if necessary. EDIT: 6. Updates I explained how to do when there's a update that "conflits" with the Improved Logging System. But I will put here a update (example) and also because I think this one is important: Revision 17142 (cashshop inside the game creation): cashshop.c IMPROVED LOG SYSTEM patch r17142.patch It is at the same time a example how to create new logs with this system. See ya!
    2 points
  2. Index: atcommand.c =================================================================== --- atcommand.c (revision 17161) +++ atcommand.c (working copy) @@ -1726,7 +1726,10 @@ clif_displaymessage(sd->fd,msg_txt(995)); // You cannot use @go on this map. return 0; } - + if( map[sd->bl.m].flag.town && !pc_has_permission(sd, PC_PERM_WARP_ANYWHERE) ) { + clif_displaymessage(sd->fd,"You can only use @go inside towns."); + return 0; + } memset(map_name, '\0', sizeof(map_name)); memset(atcmd_output, '\0', sizeof(atcmd_output));
    2 points
  3. What you need is a statpointcount() function that would count their StatusPoint, including points they already put into stats (similar to skillpointcount). Here you go! statpointcount.txt The script functions are based on trunk/src/map/pc.c::pc_need_status_point() ~line 5900 /// Returns the number of stat points needed to change the specified stat by val. /// If val is negative, returns the number of stat points that would be needed to /// raise the specified stat from (current value - val) to current value. int pc_need_status_point(struct map_session_data* sd, int type, int val) { PS: yes, we could have just created a 'statpointcount' script command with about 25 lines of code from pc_resetstate() (vs 600 lines of script) but writing the script was more fun!You could trigger this script with OnPCLoginEvent by replacing lines 3-40 with this: - script check_statpoints -1,{ OnPCLoginEvent: if (getgmlevel() > 50) end; function pc_need_status_point; // src/map/pc.c function pc_maxparameter; function read_statpoint_table; // db/re/statpoint.txt OR db/pre-re/statpoint.txt set .@should_have, read_statpoint_table(BaseLevel) + ( Class&EAJ_UPPERMASK ? 52 : 0 ); //==== statpointcount() ==================================================== set .@actual_statpoint, pc_need_status_point(bStr, 1-readparam(bStr)) + pc_need_status_point(bAgi, 1-readparam(bAgi)) + pc_need_status_point(bVit, 1-readparam(bVit)) + pc_need_status_point(bInt, 1-readparam(bInt)) + pc_need_status_point(bDex, 1-readparam(bDex)) + pc_need_status_point(bLuk, 1-readparam(bLuk)) + StatusPoint; //========================================================================== if (.@actual_statpoint > .@should_have) { set .@name$, strcharinfo(0); mes "We have detected your stats are over the limit."; mes "You will be disconnected shortly. Please contact a GM."; atcommand "@kick " + .@name$; atcommand "@block " + .@name$; debugmes .@name$ + " was blocked for having more stat points than normal."; atcommand "@request <-- was blocked for having more stat points than normal."; } end;
    2 points
  4. All headgear official bRO, cRO, euRO, fRO, idRO, iRO, jRO mysgRO, twRO, tRO Update November 2022 Headgear November 2022.7z Iclude list and miss headgear
    1 point
  5. try this my edit. FindTheMushroom.txt
    1 point
  6. Replace x2 set $top3_pvprank$, implode( .@name$, "?" ); to for( set .@tmp, 0; .@tmp < getarraysize( .@name$ ); set .@tmp, .@tmp + 1 ) set $top3_pvprank$, $top3_pvprank$ + .@name$[ .@tmp ] + ( .@tmp == getarraysize( .@name$ ) -1 ? "" : "?" );
    1 point
  7. You'll have to modify your attr_fix table in the db folder (add a new column and row to each level). The attr_fix table holds all of the values so you don't have to modify any formulas when adding a new element. Check out battle.h to increase the attr_fix array size and map.h to add the two new elements to the enum. You should be good to go from there to modify whatever else you want for status resistance and stuff.
    1 point
  8. February Digest 2013 The following digest covers the month of February, 2013. Development Team Playtester has joined as Script / DB Developer. Joseph has been moved to Community Contributors. Development Highlights Major Renewal updates: Max level increased to 160, max stat increased to 125. (r17133, r17160) Post-balance skill changes applied to Rune Knight and Arch Bishop. (r17140, r17145, r17150) Item database updates. (r17122, r17151) Mapcache updated up to 2012-08-08. (r17141) Octopus Cave instance added. (r17158) New commands: Greatly extended 'readparam' functionality. (r17131) Added 'consumeitem' command. (r17137, r17138) Added 'checkidle' command. (r17126, r17127) Other noteworthy changes: Overhaul of msg_athena system. (r17153, r17154) Implementation of MySQL Reconnect. (r17120) Added a Perl configuration tool. (r17143, r17144) Misc. Stats During the period there were 51 commits. Of these 51 commits 28 included bug-fixes.
    1 point
  9. A hand full of new skill tags was added to the client on Feb 15th, 2013. These skills all appear to be related to the 3rd job's and may be quest skills. Here's a list of the new skills.... // Rune Knight RK_DRAGONBREATH_WATER RK_LUXANIMA // Warlock WL_TELEKINESIS_INTENSE // Ranger RA_UNLIMIT // Arch Bishop AB_OFFERTORIUM // Mechanic NC_MAGMA_ERUPTION // Guillotine Cross GC_DARKCROW // Royal Guard LG_KINGS_GRACE // Sorcerer SO_ELEMENTAL_SHIELD // Minstrel/Wanderer WM_FRIGG_SONG // Sura SR_FLASHCOMBO SR_FLASHCOMBO_ATK_STEP1 SR_FLASHCOMBO_ATK_STEP2 SR_FLASHCOMBO_ATK_STEP3 SR_FLASHCOMBO_ATK_STEP4 // Genetic GN_ILLUSIONDOPING // Shadow Chaser SC_ESCAPE // Unknown ALL_FULL_THROTTLE More info will be posted when I find more details.
    1 point
  10. Please post in Graphics Requests for your graphic requests not in the map showcase I've given some links in this topic : http://rathena.org/board/topic/73389-n-christmas-maps/
    1 point
  11. This is the most complete pack for xmas maps : http://code.google.com/p/aerie-pinkpanther/downloads/detail?name=xmas.7z&can=2&q= This one is from jRO : http://code.google.com/p/aerie-pinkpanther/downloads/detail?name=Xmas2011-jRO.rar&can=2&q=
    1 point
×
×
  • Create New...