meko

Since Hercules now uses LGTM, If you fix code quality issues during the month of October, Semmle (the company behind LGTM) will donate $3 to the World Wildlife Fund (WWF) to protect endangered species for every point you obtain. You can also win nice prizes, such as a free ticket to GitHub Universe 2018 (including travel and accommodation), a Holy Stone HS160 Shadow FPV camera drone, or a Raspberry PI 3 B+ Starter Kit development board.
 
Points will only be awarded for fixes that reach the main branch of a project’s repository (i.e. for Pull Requests that are merged), and will be awarded as follows:
1 point per recommendation, 3 points per warning, and 5 points per error fixed. Since Hercules has automatic code review enabled, then points awarded for fixes will be 3x the normal amount. This means 3 points, 9 points, and 15 points. So for example, if a participant fixes 3 errors, they will be awarded 45 points ((3 * 5) * 3), and Semmle will donate $135 to WWF.
 
>>>> Register on https://competitions.lgtm.com/ghu-2018

there's no reason you should be using an old version from last year. the newer versions have all of the features of older versions, better compatibility, less bugs and better stability
You should always use the latest release, but please don't download a .zip of the release, use git clone git://github.com/HerculesWS/Hercules.git

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!

Contribute to open source and get a free limited-edition T-shirt
 
What's Hacktoberfest?
Hacktoberfest — brought to you by DigitalOcean in partnership with GitHub and Twilio — is a month-long celebration of open source software. Maintainers are invited to guide would-be contributors towards issues that will help move the project forward, and contributors get the opportunity to give back to both projects they like, and ones they've just discovered. No contribution is too small—bug fixes and documentation updates are valid ways of participating.
 
From October 1 to October 31, contribute to any open source project (Hercules included) on GitHub to get a free T-shirt!
5 pull requests are required. (Pull requests do not have to be merged and accepted; as long as they've been opened between the very start of October 1 and the very end of October 31, they count towards a free T-shirt.)
We will be marking easy-to-tackle issues with the Hacktoberfest tag so that first time contributors can more easily find them.
 
>> Register on hacktoberfest.digitalocean.com

Resources
GitHub Learning Lab How to create a Pull Request on GitHub Understanding the GitHub Flow Open source 101 Hercules documentation Hercules wiki  
 
FAQ
It is free to participate? Yes!  
Is shipping included? Yes. DigitalOcean offers free worldwide shipping.  
What shirt sizes are available for Hacktoberfest 2018? DigitalOcean have not yet made public the size chart for 2018, but we know they at least offer S to 4XL sizes, for both male and female.  
What's included in the package? A thank you letter. A T-Shirt. A bunch of cool stickers.  
Do I need to register for Hacktoberfest before starting to open Pull Requests? No. You may register at any time during the month of October and DigitalOcean will count your pull requests retroactively from October 1 onwards.  
Do all of my Pull Requests have to be sent to the same repository? No. You may send PRs to any number of repositories you like, and as long as they are public and have an OSI-approved license they will count towards the 5+ PRs objective.  
Do I have to wait for the start of October to open Pull Requests? You may contribute all year long, but only PRs that are opened during the month of October will be counted.

Contribute to open source and get a free limited-edition T-shirt
 
What's Hacktoberfest?
Hacktoberfest — brought to you by DigitalOcean in partnership with GitHub and Twilio — is a month-long celebration of open source software. Maintainers are invited to guide would-be contributors towards issues that will help move the project forward, and contributors get the opportunity to give back to both projects they like, and ones they've just discovered. No contribution is too small—bug fixes and documentation updates are valid ways of participating.
 
From October 1 to October 31, contribute to any open source project (Hercules included) on GitHub to get a free T-shirt!
5 pull requests are required. (Pull requests do not have to be merged and accepted; as long as they've been opened between the very start of October 1 and the very end of October 31, they count towards a free T-shirt.)
We will be marking easy-to-tackle issues with the Hacktoberfest tag so that first time contributors can more easily find them.
 
>> Register on hacktoberfest.digitalocean.com

Resources
GitHub Learning Lab How to create a Pull Request on GitHub Understanding the GitHub Flow Open source 101 Hercules documentation Hercules wiki  
 
FAQ
It is free to participate? Yes!  
Is shipping included? Yes. DigitalOcean offers free worldwide shipping.  
What shirt sizes are available for Hacktoberfest 2018? DigitalOcean have not yet made public the size chart for 2018, but we know they at least offer S to 4XL sizes, for both male and female.  
What's included in the package? A thank you letter. A T-Shirt. A bunch of cool stickers.  
Do I need to register for Hacktoberfest before starting to open Pull Requests? No. You may register at any time during the month of October and DigitalOcean will count your pull requests retroactively from October 1 onwards.  
Do all of my Pull Requests have to be sent to the same repository? No. You may send PRs to any number of repositories you like, and as long as they are public and have an OSI-approved license they will count towards the 5+ PRs objective.  
Do I have to wait for the start of October to open Pull Requests? You may contribute all year long, but only PRs that are opened during the month of October will be counted.

the list of maps in atcommand_go is hardcoded in src/map/atcommand.c
you'll want to use @warp instead

@Habilis i will be the first to get the t-shirt.

Contribute to open source and get a free limited-edition T-shirt
 
What's Hacktoberfest?
Hacktoberfest — brought to you by DigitalOcean in partnership with GitHub and Twilio — is a month-long celebration of open source software. Maintainers are invited to guide would-be contributors towards issues that will help move the project forward, and contributors get the opportunity to give back to both projects they like, and ones they've just discovered. No contribution is too small—bug fixes and documentation updates are valid ways of participating.
 
From October 1 to October 31, contribute to any open source project (Hercules included) on GitHub to get a free T-shirt!
5 pull requests are required. (Pull requests do not have to be merged and accepted; as long as they've been opened between the very start of October 1 and the very end of October 31, they count towards a free T-shirt.)
We will be marking easy-to-tackle issues with the Hacktoberfest tag so that first time contributors can more easily find them.
 
>> Register on hacktoberfest.digitalocean.com

Resources
GitHub Learning Lab How to create a Pull Request on GitHub Understanding the GitHub Flow Open source 101 Hercules documentation Hercules wiki  
 
FAQ
It is free to participate? Yes!  
Is shipping included? Yes. DigitalOcean offers free worldwide shipping.  
What shirt sizes are available for Hacktoberfest 2018? DigitalOcean have not yet made public the size chart for 2018, but we know they at least offer S to 4XL sizes, for both male and female.  
What's included in the package? A thank you letter. A T-Shirt. A bunch of cool stickers.  
Do I need to register for Hacktoberfest before starting to open Pull Requests? No. You may register at any time during the month of October and DigitalOcean will count your pull requests retroactively from October 1 onwards.  
Do all of my Pull Requests have to be sent to the same repository? No. You may send PRs to any number of repositories you like, and as long as they are public and have an OSI-approved license they will count towards the 5+ PRs objective.  
Do I have to wait for the start of October to open Pull Requests? You may contribute all year long, but only PRs that are opened during the month of October will be counted.

Contribute to open source and get a free limited-edition T-shirt
 
What's Hacktoberfest?
Hacktoberfest — brought to you by DigitalOcean in partnership with GitHub and Twilio — is a month-long celebration of open source software. Maintainers are invited to guide would-be contributors towards issues that will help move the project forward, and contributors get the opportunity to give back to both projects they like, and ones they've just discovered. No contribution is too small—bug fixes and documentation updates are valid ways of participating.
 
From October 1 to October 31, contribute to any open source project (Hercules included) on GitHub to get a free T-shirt!
5 pull requests are required. (Pull requests do not have to be merged and accepted; as long as they've been opened between the very start of October 1 and the very end of October 31, they count towards a free T-shirt.)
We will be marking easy-to-tackle issues with the Hacktoberfest tag so that first time contributors can more easily find them.
 
>> Register on hacktoberfest.digitalocean.com

Resources
GitHub Learning Lab How to create a Pull Request on GitHub Understanding the GitHub Flow Open source 101 Hercules documentation Hercules wiki  
 
FAQ
It is free to participate? Yes!  
Is shipping included? Yes. DigitalOcean offers free worldwide shipping.  
What shirt sizes are available for Hacktoberfest 2018? DigitalOcean have not yet made public the size chart for 2018, but we know they at least offer S to 4XL sizes, for both male and female.  
What's included in the package? A thank you letter. A T-Shirt. A bunch of cool stickers.  
Do I need to register for Hacktoberfest before starting to open Pull Requests? No. You may register at any time during the month of October and DigitalOcean will count your pull requests retroactively from October 1 onwards.  
Do all of my Pull Requests have to be sent to the same repository? No. You may send PRs to any number of repositories you like, and as long as they are public and have an OSI-approved license they will count towards the 5+ PRs objective.  
Do I have to wait for the start of October to open Pull Requests? You may contribute all year long, but only PRs that are opened during the month of October will be counted.

in the second skill, lookup for nearby BL_SKILL units (with map->foreachinarea) and then you will get a struct block_list so cast it to a struct skill_unit (with BL_UCAST) and check that su->group->skill_id matches the id of the first skill and then you can get the location with su->bl.x and su->bl.y

conf/messages.conf
 
...good luck

.@count = getunits(BL_PC, .@units, false); for (.@i = 0; .@i < .@count; ++.@i) { addtimer(0, "MyNPC::OnMyEvent", .@units[.@i]); } end; OnMyEvent: command(); // <= here  
buf if you only want to revive everyone you can simply do this:
recovery();  

@luizragna in Hercules v2018.06.03 we added support for global lookups with getunits() so there is no need to supply a map. Just update your Hercules installation to v2018.06.03 or a newer version.

Why not use this: 
I think this might be easier. have time to check on it

Duplicate npcs do share variables but this is legacy code that we can't change without breaking backward-compatibility. What we could do however is add a config flag so you can manually choose the desired behaviour.
The problem is that in npc_duplicate_script_sub the function does npc->script = source->script, so it creates a pointer to the parent script_code struct instead of creating its own and variables are stored in this struct. The Evol plugin fixes this by creating its own struct but since I see other people want this change I will move it to Hercules directly instead.

Duplicate npcs do share variables but this is legacy code that we can't change without breaking backward-compatibility. What we could do however is add a config flag so you can manually choose the desired behaviour.
The problem is that in npc_duplicate_script_sub the function does npc->script = source->script, so it creates a pointer to the parent script_code struct instead of creating its own and variables are stored in this struct. The Evol plugin fixes this by creating its own struct but since I see other people want this change I will move it to Hercules directly instead.

if you only want to compare account ID then there is no need to use SQL at all
if (!(#REG_REWARD & (1 << 0)) && getcharid(CHAR_ID_ACCOUNT) < 3000000) { getitem(TIER_1_ITEM, 1); #REG_REWARD |= 1 << 0; } if (!(#REG_REWARD & (1 << 1)) && getcharid(CHAR_ID_ACCOUNT) < 2800000) { getitem(TIER_2_ITEM, 1); #REG_REWARD |= 1 << 1; } if (!(#REG_REWARD & (1 << 2)) && getcharid(CHAR_ID_ACCOUNT) < 2500000) { getitem(TIER_3_ITEM, 1); #REG_REWARD |= 1 << 2; } if (!(#REG_REWARD & (1 << 3)) && getcharid(CHAR_ID_ACCOUNT) < 2200000) { getitem(TIER_4_ITEM, 1); #REG_REWARD |= 1 << 3; } if (!(#REG_REWARD & (1 << 4)) && getcharid(CHAR_ID_ACCOUNT) < 2050000) { getitem(TIER_5_ITEM, 1); #REG_REWARD |= 1 << 4; } if (!(#REG_REWARD & (1 << 5)) && getcharid(CHAR_ID_ACCOUNT) < 2005000) { getitem(TIER_6_ITEM, 1); #REG_REWARD |= 1 << 5; } if (!(#REG_REWARD & (1 << 6)) && getcharid(CHAR_ID_ACCOUNT) < 2001000) { getitem(TIER_7_ITEM, 1); #REG_REWARD |= 1 << 6; } if (!(#REG_REWARD & (1 << 7)) && getcharid(CHAR_ID_ACCOUNT) < 2000300) { getitem(TIER_8_ITEM, 1); #REG_REWARD |= 1 << 7; }  
Just change TIER_X_ITEM to whatever item you want to give. This script uses the first 8 bits (1 byte) of the #REG_REWARD integer variable so you can use the last 3 bytes to store other data if you wish.

getting tired of people keep sending me personal message -> how do I apply your koe patch
after about 6 PMs or so I getting really fed up,
only then I realize there is no guide to properly teach members how to apply a diff file, so here I make one for you guys
First step
A lot of people download hercules in .zip format. This is WRONG.

instead, follow the proper guide and use tortoisegit (if you are using windows) to download your server
This is the proper guide on how to install hercules

 
Question: but I am using rathena, not hercules
Answer: just change the link into rathena ones
https://github.com/rathena/rathena/wiki/Install-on-Windows
 
 
Second step
after you get your proper server, the first thing you have to do is get rid of your current one
this is the painful process, because you did not follow the guide
but on the up side, you can always update your server every week just by Git pull
which already mentioned in that installation topic guide
Question: but every time I Git pull, it always ask to resolve conflicts
Answer: that's the reason hercules community stop providing patch file and transition towards plugin system
you should always keep your server up to date with the latest revision as we always add new features and bug fix
nobody on the board like to give support on old emulator
Question: but rathena doesn't have plugin system
Answer: yes rathena doesn't support right now, but will be soon in the near future. rathena already slowly transition towards C++ format
 
 
Third Step
now you have a .diff file, download the file somewhere, right click on it

then point the link towards your hercules installation folder
Apply Patch Serial... Review/apply single patch... if either option doesn't work, try the other
 
 
Disclaimer:
I am windows user, so I never use Linux or Centos whatever,
so this guide is purely meant for those keep bombard my PM box over and over

View File Hash table
This plugin exposes the internal hash table (strdb) to the script engine to provide a key-value store.
See documentation on hercules-hashtable/doc/script_commands.txt
 
Download here: https://github.com/Helianthella/hercules-hashtable
Submitter meko Submitted 06/18/18 Category Plugins  

As of June 3rd, the specialeffect() command has been upgraded and it now allows to use effects on any kind of unit (player, npc, mob, homunculus, ...) and to show it to any player. This allowed us to deprecate specialeffect2() and misceffect() so now there is a single command for effects instead of 3 different ones, making things simpler for everyone. You can still use specialeffect2() and misceffect() but they will trigger a warning every time, since they will be removed in the future.
 
Here's how the updated specialeffect() command works:
 
specialeffect(effect number{, send target{, unit id{, account id ]}})
 
effect number is the effect to use.
see effect_list.txt for a list of all effects
 
send target is to whom the effect should be sent. The most common values are:
AREA will show the effect to every player in the area
SELF will show the effect to one player only
see constants.md for a list of possible send targets
 
unit id is the unit on which the effect should be centered
it can be a mob id, an account id, a npc id or the id of any other kind of unit
 
account id is the player to which the effect should be sent if SELF was specified as send target
 
To migrate from specialeffect2 to specialeffect:
 
specialeffect2(effect) ➜ specialeffect(effect, AREA, playerattached())

specialeffect2(effect, target, "player name") ➜ specialeffect(effect, target, getcharid(CHAR_ID_ACCOUNT, "player name"))
 
To migrate from misceffect to specialeffect:
Because the behaviour of this command varies depending on if the npc has a sprite or not, what you want is either one of the two:

misceffect(effect) ➜ specialeffect(effect)

misceffect(effect) ➜ specialeffect(effect, AREA, playerattached())

if one doesn't want to rely on mapflags, they could also make the maps use a custom zone, and then it can be checked with
OnNPCKillEvent: if (getmapinfo(MAPINFO_ZONE, strcharinfo(PC_MAP)) == "my_zone") end;  

you can set a custom chat_area_size in battle_configuration
you should find it in conf/map/battle/client.conf
 
if you want to allow everyone on the map to talk to everyone from anywhere I would advise you to use the #map channel instead of increasing the chat area size

IP addresses and mac addresses do not uniquely identify people. Most home internet users have dynamic IP addresses assigned by their ISP, so it changes over time, and some ISPs even assign a different one every single time the router is rebooted (ie: Orange). Even with a static IP, nothing prevents anyone from using a VPN, tor, or any other anonymity tool. IP addresses may also be shared: some schools, dormitories, and organizations have a single address for every single computer on its network, so you could end up mistaking hundreds of people as the same person. Some computers themselves are also shared (ie: with coworkers, family members, friends, …). As for mac addresses, they can very easily be spoofed, and one could even make a script to change their mac address every minute if they wanted to... so yeah, that's a bad idea too.
If this still does not discourage you from using mac addresses, feel free to add this "feature" to Hercules: https://github.com/HerculesWS/Hercules/issues/1734
 
There's really no silver bullet to really be sure of the identity of someone, but one of the approaches that kinda works is to make abuse costly on abusers, while not imposing a huge burden on non-abusers. What works best is doing a physical verification instead of a digital one when someone creates an account. For example, most social media platforms now ask you to provide and validate a phone number. This means if someone were to bypass this verification they would have to have more than one phone. Some sites, such as Paypal, go even further ask you for your credit card number (or bank account number) and then do a transaction on it (usually $1), to see if the card is valid. This means you would have to have more than one credit card if you want to bypass this verification, which implies physically going to your bank, making an appointment, and opening a new account. Some (such as Google) prefer to snail mail you an envelope containing a code, which you then have to enter on their website. To abuse this you would need more than one street address. Keep in mind that this only makes it harder on would-be abusers and that nothing can 100% fingerprint someone. Even DNA profiling isn't perfect.

IP addresses and mac addresses do not uniquely identify people. Most home internet users have dynamic IP addresses assigned by their ISP, so it changes over time, and some ISPs even assign a different one every single time the router is rebooted (ie: Orange). Even with a static IP, nothing prevents anyone from using a VPN, tor, or any other anonymity tool. IP addresses may also be shared: some schools, dormitories, and organizations have a single address for every single computer on its network, so you could end up mistaking hundreds of people as the same person. Some computers themselves are also shared (ie: with coworkers, family members, friends, …). As for mac addresses, they can very easily be spoofed, and one could even make a script to change their mac address every minute if they wanted to... so yeah, that's a bad idea too.
If this still does not discourage you from using mac addresses, feel free to add this "feature" to Hercules: https://github.com/HerculesWS/Hercules/issues/1734
 
There's really no silver bullet to really be sure of the identity of someone, but one of the approaches that kinda works is to make abuse costly on abusers, while not imposing a huge burden on non-abusers. What works best is doing a physical verification instead of a digital one when someone creates an account. For example, most social media platforms now ask you to provide and validate a phone number. This means if someone were to bypass this verification they would have to have more than one phone. Some sites, such as Paypal, go even further ask you for your credit card number (or bank account number) and then do a transaction on it (usually $1), to see if the card is valid. This means you would have to have more than one credit card if you want to bypass this verification, which implies physically going to your bank, making an appointment, and opening a new account. Some (such as Google) prefer to snail mail you an envelope containing a code, which you then have to enter on their website. To abuse this you would need more than one street address. Keep in mind that this only makes it harder on would-be abusers and that nothing can 100% fingerprint someone. Even DNA profiling isn't perfect.

you could either use maptimer() or make your own function with getunits() and a for() loop
EDIT: oops, @Myriad replied while I was writing this