Leaderboard

Defined rAthena NPC scripting language for Notepad++. Link: https://github.com/Sehrentos/rAthena-syntax-highlight Keywords contents NPC script commands. Constants from db/const.txt How to add to Notepad++? Open your Notepad++ and go to the Language > Define your language... > Import. Use default styles in the Settings > Style Configurator > Select theme: Default. Or you can download example style theme /themes/rAthenaWhite.xml and import it Settings < Import < Import style theme(s).... Restart Notepad++ after changing language or styles. Make a new style theme or edit existing one: Make a new theme by copying stylers.xml in %APPDATA%\Notepad++ and rename it for your theme and edit it. Save it in %APPDATA%\Notepad++\themes folder. Restart Notepad++ after edit. Auto-completion Copy APIs/rathena.xml to Notepad++ installation folder APIs/rathena. Open menu Settings > Preferences... > Auto-Completion tab, check "Enable auto-completion on each input". Restart Notepad++. Sources: rAthena Script Commands rAthena Constants Happy editing Image: Thanks, @Cydh for auto-completion

Hello all, As of yesterday's commit (https://github.com/rathena/rathena/commit/525e8178c27327f000e15ba557c6ed37a371c0b2) the default timer interval was reduced from 50ms to 20ms. This might increase CPU usage of your map-server. If you have trouble running your server with these settings, you can simply change it back. To change it back just find /src/common/timer.c and change #define TIMER_MIN_INTERVAL 20to #define TIMER_MIN_INTERVAL 50 In the following I will explain in-depth why we decided to change it despite the additional cost and what it'll effect. First of all, the official interval is 20ms, for everything. This was known for quite a while already, even back in eAthena. Back then it was decided that performance is more important, so higher intervals were set and for certain cases workarounds were written. Workarounds, however, are usually not a perfect emulation. Eventually there will always be a special case that is then again different from official servers and then you write another workaround for that. In the end, your code is full of workarounds (or simply not emulating accurately). The intervals were added the way they are around 10 years ago. Of course back then not only was the hardware a lot worse, but there were also a lot more servers with a high population. These days the hardware is a lot better and you already consider a server with 100 players as one with a high population. The official timer interval of 20ms, should no longer be a hindrance for most machines and servers anymore. Even if some server really has trouble with the interval, the owner can simply set the timer interval to what he needs (or buy better hardware alternatively), but we decided that the default setup for rAthena should be as close to official as possible. So what are the benefits? The greatest benefit of using the official interval for our timers is that it strongly improves the synchronisation between client and server. I realized this when I investigated why skills could be "chained" on official servers but failed to chain most of the time on my local rAthena test server. I originally thought the official server had implemented some kind of "skill queue" system that remembers all commands from the client and then executed them whenever there was time, this proved to be wrong. In fact, the client is the part that handles the skill queueing itself. It will remember skill requests the user requested and only send them to the server when it thinks a new skill can be used. But this also means that server and client need to be in perfect sync or otherwise the client will send a new skill request while the server still thinks that no skill can be used yet. This is especially noticable at the end of a cast time. When the client doesn't receive the skill use packet fast enough, it will think that the skill failed and then send the next skill requests from its queue. To illustrate this, here is an example: Basically what happens with 50ms interval is this (assuming 160 aspd = 400ms aMotion): - 0ms: the player casts a skill with 2000ms cast time - 0ms: we tell the client "cast time 2000ms" - 0ms: we create a timer to execute skill_castend at 2000ms - 1000ms: the player issues another command to cast the same skill again, the client will remember it - 2000ms: nothing happens (timer interval not reached yet) - 2030ms: we receive a skill request from the client to cast the skill again, but since the current skilltimer is still active, we just drop it - 2050ms: the skill gets executed - 2450ms: now the server is ready to receive a new skill request (aMotion ended) Because of this the skill request given during cast time gets completely lost. With a timer interval of 20ms the following will happen: - 0ms: the player casts a skill with 2000ms cast time - 0ms: we tell the client "cast time 2000ms" - 0ms: we create a timer to execute skill_castend at 2000ms - 1000ms: the player issues another command to cast the same skill again, the client will remember it - 2000ms: nothing happens (timer interval not reached yet) - 2020ms: the skill gets executed - 2020ms: client realizes the skill is executed and applies aMotion delay to the remembered skill - 2420ms: now the server is ready to receive a new skill request - 2450ms: we receive a skill request from the client to cast the skill again, server will accept it and execute the skill In this case the skill request is not lost and you can easily chain skills together. Note, that only some skills can be chained like this, particularly those with no after cast delay like e.g. Holy Light. Of course this is just one example where client-server synchronisation matters. Timers are used almost everywhere, so there is a wide array of benefits from using the official interval. Everything simply feels more "fluent". Another benefit is that with a timer interval of 50ms, skills with cast time would go off 30ms later than officially. It might only be a small delay, but especially for skills with low cast time or special situations where you get attacked a lot while trying to cast, an interval of 20ms is a noticable improvement. It also closes the gap between instant cast and cast time a little. The interval is also relevant for "timer damage" as in, damage you receive in regular intervals. The timer interval used can for example have an effect on whether you manage to walk to the next cell between hits or not. While we updated the timer interval, we did not update the skill unit timer interval you can find in skill.c: #define SKILLUNITTIMER_INTERVAL 100Even though the official interval is again 20ms, reducing this interval will have quite a big cost increase as it means that every single placed skill unit needs to be checked in this interval and there are only two skill units that even still use an interval this small: Firewall and Crimson Fire Formation. With the default settings these skills will simply deal 5 hits every 100ms rather than 1 hit every 20ms. It is different from official servers and it is noticable and certainly not perfect in all situations. If you just have a small server or think your machine can take it, then feel free to change the interval to 20ms: #define SKILLUNITTIMER_INTERVAL 20I tested this locally and it works perfectly fine (but of course me playing alone and placing a few fire walls and blaze shields is nothing compared to a big server with hundreds of units placed all the time).

This is already fixed in v1.1 just update your trunk. Commit: https://github.com/rathena/rathena/commit/1d2160758c686454ee0560944c6215132c9c249c

I very much doubt it. The most popular server back then was AnimaRO and it peaked at 3.5k-ish players in 2007. A lot of drama happened, the server splitted and it got somewhat ruined after that. So 30k...? Nah, no way. A little background while we're at it (screenshot of Gravity's annual report). 2002 to 2006 (Notice the USA & Canada servers couldn't even reach past 10k players in 2005) 2007 to 2010 Report : http://secfilings.nasdaq.com/edgar_conv_html%2f2010%2f06%2f01%2f0000950123-10-054555.html

In your conf/battle/status.conf look for: debuff_on_logout: 3 Change that "3" into a "1", or paste this into your /conf/import/battle_conf.txt debuff_on_logout: 1 That's it.