Leaderboard

https://rathena.org/board/topic/117831-showcase-weapon-skin/. https://github.com/rathena/rathena/issues/1779 got people ask how to do that ... so I write a plugin for it Download: 1.1 plugin also need to add a file in conf/import/change_equipment_skin.conf change_equipment_skin: ( { Type: "LOOK_WEAPON" ItemID: 24001 SkinID: 1238 }, //{ // Type: "LOOK_SHIELD" // ItemID: 24002 // SkinID: 2101 //}, ) When player equip a shadow weapon ID 24001, will show the weapon look 1238, which is Zeny_Knife "@reloadequipmentskin" will reload this file ... Note: yes, the clif->sendlook is extremely messy, I attempt to make this support change shield skin but for dunno what reason, equip a shield telling the client changing LOOK_WEAPON ... WTF !! if anybody knows how to make it support shield, I'm open to suggestion

Download: 1.1 sample quest log Download: 1.1 sample daily quest these are 5 sample quests using quest log system this was actually made as a sample script inside a script support section in eathena forum original topic from eathena thanks to paradog eathena admin that makes eathena forum down, almost gonna remake everything from scratch luckily I got a few segment here and there in my old hard-disk so doesn't take too much time to write this sample Quest #1 typical talk to npc A, then npc B ... etc demonstrate how to use *checkquest Quest #2 collect item quest just checkitem with it I still don't know how to use the client to trace is the item collecting has completed or not Quest #3 kill monster quest demonstrate how to use *checkquest( x, HUNTING ) Quest #4 typical talk to npc A, then npc B ... BUT with a time limit demonstrate how to use *checkquest( x, PLAYTIME ) Quest#5 if player having this quest, player can *getitem by killing this monster see https://github.com/HerculesWS/Hercules/blob/stable/db/quest_db.conf#L45-L50 and I want to remind this is just a sample script usually make for source modification on quest log system (now is 3rd time I think ?) 2 sample script for daily system 1. Daily item giver ... although I think this should done with attendance system ... 2. Daily hunting ... self explain ... [109991] = { UI_Type = 0, group = "CHATTING", major = 4, minor = 0, title = "Tavern Helper", content = { summary = "Visit the Tavern Master", details = "Visit the Tavern Master in Prontera." }, resource = { [1] = { text = "Acolyte Trouble" }, [2] = { text = "Gemstone shortage" }, [3] = { text = "Poring Problem" }, [4] = { text = "Hand over the Artifact" }, [5] = { text = "Shining Rocker" } }, reward = { title = 991 }, score = 5 }, [109992] = { UI_Type = 1, group = "GOAL_ACHIEVE", major = 6, minor = 0, title = "Complete Daily Quest for 30 times", content = { summary = "Complete Daily Quest", details = "Complete Daily Quest for 30 times and you can earn some nice rewards!" }, resource = { [1] = { text = "Collect Daily Items 30 times", count = 30 }, [2] = { text = "Complete Daily Quest 30 times", count = 30 } }, reward = { title = 992, item = 513 }, score = 30 }, UI_TYPE - display a bar like in the daily quest screenshot - 0: in the [resource], doesn't support [count] - 1: support [count] group: - read from data\texture\À¯ÀúÀÎÅÍÆäÀ̽º\achievement major - 1: General tab - 2: Adventure tab - 3: Battle tab - 4: Quest tab - 5: Memorial tab - 6: Feat tab

Optionally you can do next:

Related commit: https://github.com/HerculesWS/Hercules/pull/2391 this is part of *setunitdata script command clean-up the UDT_MAPIDXY and UDT_WALKTOXY constant has been deprecated so this script command only dealing with 1 INTEGER value now it has been standardize, all (int) has been removed from the documentation Example 1 : setunitdata UDT_MAPIDXY (old) .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); setunitdata(.@mobgid, UDT_MAPIDXY, "guild_vs2", 50,50); now should be .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); unitwarp(.@mobgid, "guild_vs2", 50,50); Example 2 : getunitdata UDT_MAPIDXY (old) .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); getunitdata(.@mobgid, UDT_MAPIDXY, .@pos); dispbottom(sprintf("%d %d %d", .@pos[0], .@pos[1], .@pos[2])); // apparently we don't have *mapid2name script command ... doesn't matter anymore now should be .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); getmapxy(.@map$, .@x, .@y, UNITTYPE_MOB, .@mobgid); dispbottom(sprintf("%s %d %d", .@map$, .@x, .@y)); Example 3 : setunitdata UDT_WALKTOXY (old) .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); setunitdata(.@mobgid, UDT_WALKTOXY, 158,185); now should be .@mobgid = monster("this", -1,-1, "--ja--", PORING, 1); unitwalk(.@mobgid, 158, 185);

no.1 ... wait until I fix OnPCUseSkillEvent that modification allows to manipulate everything with a skill cursor .... no.2 you mean like adding 3D object into the game without telling player that object is manipulate from server side ? none, perhaps you can try with browedit if you want to customize the map

I don't understand what topic request talking about if anyone understand this topic, please help me rephrase his/her sentence

if you mean like event script, that waitingroom can be open/close, that warp player to event map when its open prontera,158,185,5 script jdshfjsdfh 1_F_MARIA,{ if ( .start ) mes "The event is OPEN"; else mes "The event is CLOSED"; close; OnInit: bindatcmd "asdf", strnpcinfo(NPC_NAME)+"::Onaaa"; waitingroom "Event", 0; end; Onaaa: .start ^= 1; delwaitingroom strnpcinfo(NPC_NAME); if ( .start ) waitingroom "Event", 2, strnpcinfo(NPC_NAME)+"::Onstart", 1; else waitingroom "Event", 0; end; Onstart: getwaitingroomstate 0; unitwarp $@chatmembers[0], "guild_vs2", 49,49; end; } however if it is for player, I have absolutely no idea what your point is ... PS: I think ... like I have to fix my OnPCUseSKillEvent ....

no, i dont think in near future i can work on this patch

About Code Review and Why You'd Want Your Code to Be Reviewed Hello, fellow developers and code contributors! As you certainly know, years ago, Hercules adopted a workflow based on pull requests, that includes code review as one of the necessary steps before any new piece of code makes it into the master branch of the repository. While being an uncommon and somewhat controversial change in Hercules (and in the RO emulator scene in general), code review is part of the workflow of most software projects, both open source and closed source, and has many benefits. Why Code Review The benefits of code review are several: "Given enough eyeballs, all bugs are shallow" [Linus's Law by Eric S. Raymond -- The Cathedral and the Bazaar, 1999]. While the law is not strictly true, it's certainly true that the more developers read and analyze a piece of code, the more likely it is that bugs that might be hidden in it are discovered early. Testing is not enough. It's very hard (or in the case of our codebase just plain impossible) to cover all the possible edge cases when testing a new feature or a fix. An additional pair of eyes reading the code may help discovering those more easily. This includes cases where the client would normally prevent a certain thing from happening, but it's not ensured anywhere on the server side. Better quality of code. By having other developers read a piece of code, they'll end up wondering why a certain approach was taken, rather than another, and discuss it with the submitter, leading to better, more efficient algorithms, or better engineered code. Better documentation. Since the code needs to be read by other people, it'll require proper comments (or they'll ask for explanations about the parts they can't easily explain). This increases the chance that the author, or anyone else that will need to read the same code again months or years after it's been submitted, will be able to understand it again, by finding appropriate comments in the appropriate parts of the code. Better insight into the code across the team. By reading code from different parts of the emulator as part of the review process, every team member increases their own general knowledge of the software, bit by bit. This is a very efficient way of learning how different parts of the emulator work, and why they were implemented that way. Future-proofing. By having public reviews, we keep a permanent trace of what were the hot topics and why certain decisions were taken, when a certain part of the emulator was implemented. If a bug arises, or something needs to be redesigned in future, we can look up the associated pull request and related discussion, and learn more about the discussion that went on in the past, and what's hiding behind code design decisions. Reviewing code from other people, as well as having one's own code reviewed by others might not be easy for everyone, especially at the beginning, but please try your best. Here are some suggestions on how to approach code review from either side. How to approach code review (for code authors) As a code author, the worst thing you can do is to be afraid or shy about other people judging your code. This is the wrong approach! Don't be shy, have your code looked at by others, have them praise you for your genial approach to tackle a problem, listen to their suggestions on how to improve it. But be ready to defend your implementation, if you believe it's better than the suggestions you receive, or if the critics that are moved against it are wrong or meaningless. Always keep in mind that: Having your code reviewed and commented on isn't humiliating. Other people are spending their time looking at your code, asking you why you did something in a certain way rather than another, suggesting improvements. Both sides have a lot to learn from each others. (On the other hand, if no one reviews your code, that's somewhat humiliating!) If someone spots an issue in your code, it doesn't mean that you're a bad developer. We all make mistakes, and we should be happy to learn from them (and it's definitely better if someone spots them and points them out to us before it's too late and they were able to do some harm). Never, ever, take code review personally. No one will laugh about you, fire you, kill you, shame you, etc. if your code is commented on. If you believe you're right and the comments you received are pointless or wrong, chance is that you really are right. Be ready to defend your reasons, it's possible that the reviewer didn't think of them. It is your duty to explain them your reasons. How to approach code review (for code reviewers) Reviewing code is several orders of magnitude harder than having your own code reviewed. You have to check the code for several classes of problems, point out your findings, suggest improvements. And you still have to deal with the worry about hurting the code author's feelings when pointing out a mistake. Here are some things you should keep in mind when reading and reviewing code from other people: You're not judging a person. You're judging code. Don't make your review sound personal. Always think of uncommon and edge cases, and never assume they can't happen, unless there's an explicit check that makes them impossible to happen. Even if the code was tested by the author, it doesn't mean that it can't cause problems to other existing features, or have some issues the author couldn't think of. If the same person writes and tests a piece of code, the chance that they don't test the cases they forgot to handle while coding, is very close to 100%. If the code is not following the project's style guidelines (and this isn't just about indentation, but also about names, conventions about function calls, proper modularization, etc), it is your duty to point it out now, before it's merged. This will make the life of your fellow developers easier later on. Think defensively. Consider the code you have in front of you as buggy until you can prove its correctness. If you see that a sanity check is missing, ask the author to add it. If you believe that a function returns the wrong value in certain cases, even if very unlikely to occur, prepare an example of input for which that happens and point it out. Remember that threats such as overflows, underflows, buffer overruns, null pointers, invalid pointers, numeric (floating point) approximation, etc. are always behind the corner, check for them as often as possible and prove that they can't occur. And remember that, while the code author isn't your enemy (and code review shouldn't generate negative feelings), it's often a good idea to think of them as your "professional enemies". There's a chance that something nasty is hiding in their code, even if they didn't write it with ill intent, and as such, you shouldn't blindly trust the code, regardless of who the author is. Don't be afraid when you comment on other people's code. Your goal isn't to hurt their feelings, you're asking them for explanations and/or suggesting the way you would have done something. Likewise, don't be afraid of making a pointless comment. If the author has a good reason for their implementation, be ready to take back your comment and learn from them. Don't accept compromises. If you're firmly convinced that the author's defense of their code is wrong, your duty is to prove them wrong. But if they manage to convince you, don't be ashamed of admitting you were wrong. Happy reviewing!

Rationale: This changeset offers improvements to the HPMHooking, making it capable to detect, at compile time, an error in the type of a hook function, as well as allowing pre-hooks to be more powerful when it comes to pointer-type arguments. Contents: The HPMHooking macros addHookPre() and addHookPost() have been slightly edited, and they can now detect if the type of the passed function is the correct type for the hooked function. In order to do so, the HPMHookingGen script produces one more header (HPMHooking.Defs.inc) that lists the hook function types. This means that, if a plugin hooks into a function through HPMHooking, and the core function changes, the plugin will show a compile-time warning instead of silently compiling (and crashing at runtime or causing undesired effects). The post-hook function types have been simplified, dropping all the extra indirection levels that were added originally. The pre-hook function types have been changed, increasing the indirection level for pointers (now all variable types require an extra '*' in pre-hooks). This makes it possible to override const pointers from pre-hooks. Impact: Scripts that use the HPMHooking will need some small syntax changes. Details: All plugins that want to use the HPMHooking will need to #include "plugins/HPMHooking.h" (it's recommended to include it just above HPMDataCheck.h) #include "plugins/HPMHooking.h" // Included by plugins that use the HPMHooking #include "common/HPMDataCheck.h" // Included by all plugins Then the addHookPre() and addHookPost() calls need to be updated to the new syntax, separating interface name and function name:/* Before */ HPExport void plugin_init (void) { addHookPre("pc->dropitem", my_pc_dropitem_pre); addHookPost("pc->dropitem", my_pc_dropitem_post); } /* Now */ HPExport void plugin_init (void) { addHookPre(pc, dropitem, my_pc_dropitem_pre); addHookPost(pc, dropitem, my_pc_dropitem_post); } Pre-hook functions will need an additional indirection level in their pointer-type arguments:/* Hooked function: */ int (*dropitem) (struct map_session_data *sd, int n, int amount); /* Pre-hook (before) */ int my_pc_dropitem_pre(struct map_session_data *sd, int *n, int *amount) // Only adds '*' to the non-pointers /* Pre-hook (after) */ int my_pc_dropitem_pre(struct map_session_data **sd, int *n, int *amount) // Adds '*' to everything Note: arguments of type va_list do not require an additional indirection level. 'va_list ap' remains 'va_list ap' and does not become 'va_list *ap' Post-hook functions will no longer need any additional indirection level in their arguments: /* Hooked function: */ int (*dropitem) (struct map_session_data *sd, int n, int amount); /* Post-hook (before) */ int my_pc_dropitem_post(int retVal, struct map_session_data *sd, int *n, int *amount) // Adds '*' to the non-pointers /* Post-hook (after) */ int my_pc_dropitem_post(int retVal, struct map_session_data *sd, int n, int amount) // No longer adds any '*' Merge Date:Sun, 1 May 2016 20:22:03 +0300 Related Pull Requests: - #1253 - https://github.com/HerculesWS/Hercules/pull/1253 - HPMHooking improvements [Haru] Related Commits: 1ec9328 - https://github.com/HerculesWS/Hercules/commit/1ec9328 - Sun, 28 Feb 2016 02:12:48 +0100 Moved HPMHooking-related definitions to plugins/HPMHooking.h [Haru] 5db7c79 - https://github.com/HerculesWS/Hercules/commit/5db7c79 - Sun, 28 Feb 2016 02:17:21 +0100 Added type-checking for the addHookPre() and addHookPost() macros [Haru] 4e49441 - https://github.com/HerculesWS/Hercules/commit/4e49441 - Sun, 28 Feb 2016 02:20:40 +0100 HPM Hooks Update [Haru] 2788afc - https://github.com/HerculesWS/Hercules/commit/2788afc - Sun, 28 Feb 2016 02:40:15 +0100 Replaced memset with braced initializers in the HPMHooking hook handlers [Haru] fa2f2f4 - https://github.com/HerculesWS/Hercules/commit/fa2f2f4 - Sun, 28 Feb 2016 02:41:01 +0100 HPM Hooks Update [Haru] 8aacecc - https://github.com/HerculesWS/Hercules/commit/8aacecc - Fri, 15 Apr 2016 19:37:54 +0200 Removed extra indirection level in HPMHooking post-hooks [Haru] 7eb4ae4 - https://github.com/HerculesWS/Hercules/commit/7eb4ae4 - Sun, 17 Apr 2016 00:38:37 +0200 HPM Hooks Update [Haru] 89e0550 - https://github.com/HerculesWS/Hercules/commit/89e0550 - Sun, 28 Feb 2016 02:48:47 +0100 Added one level of indirection to all variables in pre-hook functions [Haru] e9c98a1 - https://github.com/HerculesWS/Hercules/commit/e9c98a1 - Sun, 28 Feb 2016 02:50:40 +0100 HPM Hooks Update [Haru] 95b4e32 - https://github.com/HerculesWS/Hercules/commit/95b4e32 - Sun, 1 May 2016 20:22:03 +0300 Merge pull request #1253 from HerculesWS/hpmhooking [Andrei Karas]

welcome to my showcase section~ for a preview of my works please check the spoilers below! if you need anything else, just ask. welcome to my showcase section~ for a preview of my works please check the spoilers above! if you need anything else, just ask.