Playtester

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).

Some equip that recovers HP/SP on kill maybe?

@mi only shows monsters that give exp, not slaves / event monsters. I'll try to reproduce it...

To be fair there's no emulator suggestions forum. =p So you always end up thinking "What I have: Source + Suggestion - Forums available: Forum Suggestions / Source Discussion - in each one one word matches!"

Did you try to removing the "while" loop in the script (and all similar occurences). Issue still persists? Loops like that could cause it.

We use the issue tracker now: https://github.com/rathena/rathena/issues/ Strange, so you just walk around while being attacked by Hydra and before it uses a skill you are suddenly unable to walk and talk and do anything really? Is that a renewal or a pre-renewal Hydra? Also monster ID (as there are several hydra versions).

As you can see here: https://github.com/rathena/rathena/commits/master Or here: http://rathena.org/board/topic/98871-october-digest-2014/ rAthena still gets many updates every month. I'm most active at the moment and I purely focus on fixing bugs that are relevant for pre-renewal. If you ask me, Hercules focuses more on new features, renewal skills and improving the performance whereas rAthena focuses more on very accurate emulation of official kRO, bugfixes and clean code structure. I can't really recommend either. As a server owner, Herc seems more attractive because of better protections, performance and features, but as a player I'm always annoyed that Herc servers still have many bugs that have already been fixed on rA (some already since several years). As a developer I prefer rA simply because of better code documentation and the other devs care more about good code (and tell me if I need to improve something).

Most ATK/DEF stat changes are not actually visible in the character window, make sure it's not increased by comparing the damage.

Shouldn't modifying party_check_exp_share be enough? But if should be: if (p->max_lvl < 80) Because otherwise you can always share with a level 90+ as long as there is one member below 80.

Right now each Vit increases HP by 1%. In status.c: status_calc_maxhpsp_pc Find: max = job_info[idx].base_hp[level-1] * (1 + (max(stat,1) * 0.01)) * ((sd->class_&JOBL_UPPER)?1.25:1); If you want to double the effect of vit you need to change the 0.01 to 0.02.

Probably I'm bothered more by the emulator situation. Every time someone fixes a bug, it needs to be fixed on watch 4-5 emulators? There are some really talented devs in all the projects and if they'd work together instead of being busy merging each others fixes, the emulator could 4-5 times more stable by now. =< For servers I can at least understand that there are so many, because there are so many different preferences. Alone if I imagine myself making my own server... sure I know some server owners really well and I could probably get some to work together with me, but the moment someone asks for customization like... a warper... or a healer... or dumbing down monster AI so it's easier to mob... I'd be strictly against it. Eventually I'll just end up thinking "screw it, I want my server exactly like old euRO and if nobody else wants it, I rather play alone locally".

Are you sure you want to make those weapon breakable? That's a huge nerf for Blacksmiths (as their weapons will break from their own Adrenaline Rush).

I have vacation for 1 week so I used that time to fix a lot of things that bothered me for a long time. ^^;

It just looks like it because the client doesn't support endure display on multi-hits. You can still walk it will just display you as standing.

Well first of all, wrong forum, you probably wanted to post this on Herc forums? But anyway, certain weapon types like rods are unbreakable by default. They will never break. Setting equip break rate from 100% to 10% will do just that. 10 times less likely for equipment to break.

Easiest solution would be to just make the ticket unstoreable and then let the NPC delete all tickets regardless of how many tickets the player has. That's effectively the same and doesn't require source code edits. If you want to do it so that even on share parties the item always goes to someone who hasn't gotten it yet, then you need to code some algorithm for that in party.c: int party_share_loot(struct party_data* p, struct map_session_data* sd, struct item* item_data, int first_charid) That's the best place to put it, you have all the info you need (struct item* item_data contains information about the item so you can check if it's your item).

I want to add that this does not necessarily mean that you will get more players when you create a pre-renewal server. It's not just about the demand but also about what is offered.

One of those blue buttons at the top-right of your screenshots - I think the dot - will open up a chat configuration where you can set what messages should show.

If it's in PVP/WoE then that's official. Only the owner of a trap can see it until the trap activates. I didn't even know we have that implemented. (On official PVP servers, traps are invisible except for the owner everywhere.) Honestly not sure how far this is implemented. You should be able to detect traps with Detect, though.

Hi, since I was curious myself, I created a statistic over all server requests of the past 2 months, here is the result: Pre-Renewal: 43.5% Renewal: 24.6% Don't care / Custom: 17.4% Pre-Trans: 14.5% So I guess the winner is pre-renewal.

Don't think ASB is still alive. Muad Dib is pretty much gone, not sure what he's doing lately, but he only even comes online like every 3 months, so he probably has a real life now. Thought he wanted to do his own project, but haven't heard from him since then. Peter is still with Ragnarok but he's focusing on his own server, Ragnarok Frontier, mostly (Ultramage is playing on it too). Aegis is simply too resource intensive and not customizable enough, so not many want to use it. ASB still has episode 13 released, though.

Skotlex quit for good. He never really liked the game and doesn't want to code at all anymore. He's more the party guy now. Ultramage is still around though he's now more interested in Aegis than *Athena. eAthena just kind of died out. Well I stuck with it for a while because I hate renewal, but then lost interest. When I came back I realized that rAthena offers a switch to easily switch back to pre-renewal so there wasn't really the need for eAthena anymore. Honestly don't really know if eAthena even has any fixes that are not on rAthena. Some other devs are probably all doing their own projects now, some are commercial versions of eAthena or tools.

I'm here. :-)

Problem with the timer in the script I guess?

This is actually official. Only people who did the quest can open the gate but everybody can enter once it's opened.