Playtester

The latest fully supported client is 2013-07-08. Newer clients might or might not work.

But there are already such min delay protections server-sided, so there isn't really a need to check for it. You can't cast skills faster than aMotion anyway. It's better to have the min delays depending on ASPD. But if you put them too high, the players will lose the ability to chain skills the normal way. // What level of leniency should the skill system give for skills when // accounting attack motion (ASPD) for casting skills (Note 2, between 0 and 300) // // NOTE: Setting this to 100% may cause some issues with valid skills not being cast. // The time difference between client and server varies so allowing 90% leniency // should be enough to forgive very small margins of error. skill_amotion_leniency: 90 Setting the value to 140 would be an idea for example.

Yes.

Easy. All Classes : 0xFFFFFFFF Priest: 0x00000100 Monk: 0x00008000 Substract both from all classes: 0xFFFF7EFF

Yeah, though that just means it tries to delete a unit that was already deleted. Which is not too critical as long as we don't forget to check for it anywhere it's used (that's why I suggested my update in the code). Does it no longer crash now?

Pretty sure it's physical only. For magic there is "bMagicAddRace".

But the link on the forum still points to the old bug tracker.

Yes. Because on pre-renewal armor def is percentual. So 99 def would already mean only 1% damage from all physical sources which basically makes you invincible anyway. I think the maximum def you can reach is ~85 def anyway with official equip even if you upgrade all to +10. You can get 90 def with Steel Body, though.

I guess for default movement speed for players which is 150ms/cell a 50ms interval is more fluent because on official interval it alternates between 140ms and 160ms per cell. But the moment you have Agi Up it should a lot more fluent with the new interval because instead of alternating between 100ms and 150ms per cell it will only alternate between 100ms and 120ms per cell. Of course irregular intervals might be welcome as it makes it easier to escape hitlock. And in any case, default rAthena really should aim to be closest to official kRO as possible by default. In case of "official bugs and annoyances", we can always just provide a define or a conf option for it. Then it's up to the server owners to decide what they want to be official and what not.

Since both is pretty much west coast, I don't think it matters much. West Coast US is pretty bad for Europeans but otherwise good.

Yes all default settings are official kRO unless stated otherwise. If you have a question about a particular setting I can also explain it.

Well in this case, the crash seems to always occur when someone is casting GN_FIRE_EXPANSION at level 5. But I honestly don't see what's wrong in it. It accesses ud->skillunit->unit before and doesn't crash then so why would it crash when unit_delunit is called? Wait... maybe the "skill_castend_damage_id" deletes the unit already in some cases? You could try: if(ud && ud->skillunit[i] && ud->skillunit[i]->unit) skill_delunit(ud->skillunit[i]->unit); break;

You need to check skill_castend_pos2 (skill.c line 10895). It doesn't even get to skill_delunit, it crashes before that because ud->skillunit does not exist and you still access an element from it. That line that crashes for you no longer seems to exist in the sourcecode, so I can't help you further.

0xC0 to be exact. Yes.

Why not just make a friendly mob spawn with large view range? Patrolling is harder I guess.

You need to sum it up in a hexidezimal way. It's easier like that because each digit is NOT influenced by other digits. It goes like this: 0-9 A - 10 B - 11 C - 12 D - 13 E - 14 F - 15 0x80 + 0x10 = 0x90 If you have: 0x80 + 0x08 + 0x02 you can split that into: First digit: 0x80 (8) Second digit: 0x08 (8) + 0x02 (2) = 0x0A (10) Then combine it together: 0x8A 0x just means "the following number is in a hexadecimal system" rather than the decimal system most humans use.

When starting a RO client it will load a lot of stuff into memory. If you run another client it uses the already available memory. That's why it's not really possible to run two different RO clients at the same time.

Just add 0x20 to the nk field: 0x42 -> 0x62

Players and server owners should use the Issue Tracker, though! We need help knowing which issues are there. So use it as much as possible (but only for real bugs, not for support questions).

{ bonus2 bSubEle,Ele_Wind,50; bonus2 bSubEle,Ele_Earth,-50; }

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.