Jump to content


  • Content Count

  • Avg. Content Per Day

  • Joined

  • Last visited

  • Days Won


helvetica last won the day on August 25 2013

helvetica had the most liked content!

Community Reputation

67 Excellent


About helvetica

  • Rank
  • Birthday 07/17/1987

Profile Information

  • Gender
  • Location
  • Github

Contact Methods

  • Skype

Recent Profile Visitors

3,651 profile views
  1. We don't make any effort at breaking older clients that were already supported, but at the same time we won't be doing any regression testing to make sure they still work after any client-affecting code update (minus the 3 listed as supported).
  2. No you're right, the inevitable final product is wholly based on how the administration wants to run it. What our goal is here is that out of the box, our server should be a drop in replacement for Gravity's official servers. If you just pull from GIT and compile and load up the game you should get a 100% point for point accurate recreation of Ragnarok Online. And since this is a open source project, you are free to make modifications and extend it beyond the original gameplay Gravity envisioned, or maybe you just don't like Gravity did some things. That's totally up to you! As far as we the core developers are concerned though, our goal is lock-step emulation with the official servers. Anything custom beyond that is for the community to provide. We provide the base product for everyone to build the game they wish to play.
  3. I'm not referring to just the official Ragnarok Online client when I say client. A client is anything that communicates to the server that isn't another server. A client can be anything from a legitimate player on an official client, a bot created to emulate a player, someone using WPE to craft packets, or someone simply sending garbage to the server on the ports it listens on. It doesn't matter what generates the packets or where they come from, what matters is how the server handles it. If the server can be induced to produce undesired behavior, whether that's something in game like bypassing restrictions or manipulating the server state, or something more severe like being able to crash the server or break out of the server and run arbitrary code, it needs to be fixed and we will put any and all resources into fixing it. The server must be able to handle legitimate input as well as be able to handle illegitimate input gracefully. When the latter doesn't occur is when potential security flaws occur. It doesn't matter how the input was generated or how it gets there.
  4. Remember, these client versions are merely suggestions. You don't have to use the clients we support. As a server admin you know the needs of your playerbase best, so you can best make that call. What we're doing with this policy is giving you, the server admin, a point of stability. You can know that if you choose to use one of our supported clients, we will test our updates against it, and we will fix any and all bugs applying to these versions first. If you choose to go with a different client version than what we support, we won't stop you or actively break things, but be aware that we won't be testing our updates against them, and if bugs do pop up they may end up on a lower priority or not fixed at all.
  5. If there's something that can be exploited from the client side, whether through client bugs/exploits or through crafted packets, that results in undesired or potentially dangerous server-side behavior, then it should be reported and will be handled based on severity. This has nothing to do with securing the client, but whether the server is hardened against input from the client that could lead to abuse. Packet obfuscation is a different story entirely, that's about potentially securing the communication between server and client. I'm not the one that handles the general packet routines so I couldn't tell you where we're at as far as implementing it. I mentioned the quip on DDoS because you mentioned "packet flooding" and I was responding in a general tone that handling such issues is impossible from the server end. There could still be specific denial of service attacks we can and should handle, but when people say "packet flooding" they generally mean distributed denial of service (the extra D) so I wanted to clarify a bit on that. And anti-bot I brought up because that's commonly referenced as part of "server security". I'm not sure how to make this any clearer. If you have any examples of potentially insecurity of any kind and are unsure about other people finding out about it, you can always PM me and I can make sure it gets listed as a private bug so it can't be actively exploited until it gets fixed. If it's something that we can't handle or is better handled outside the scope of this project, then we will let you know. But we will ALWAYS take reports of potential security flaws seriously. Security and stability go hand in hand, you can't have one without the other. A stable server is a secure server.
  6. Bot detection is not within the scope of this project, as every server will have different requirements and tolerances when it comes to anti-bot systems. As for packet flooding/spam, that also depends. A general DDoS protection is impossible, this needs to be handled at the network level. Attacks that involve WPE or other packet crafting to induce undesired or abusive behaviors should definitely be reported and will be handled based on severity. As far as encrypting packets go, I'm not sure where we stand on this. Lighta is our main dev who handles the packet system.
  7. 2012-04-10 is a extremely popular and widely deployed client, hence why it has been chosen to be part of the standard test suite. Having 3 clients to test against isn't the end of the world, but having several hundred potential clients is.
  8. There will eventually be a 2013 client we support. There just hasn't been a decision made on which one. I'm the one mostly driving the push towards client standardization, but I have no experience with any of the 2013 clients on my own servers and I haven't had a chance to sit down and make an evaluation.
  9. That's applied to the person using the skill, not the person getting hit by said skill. I don't think we have an equivalent item bonus that reduces damage from a certain skill as I can't think of any official item that has that kind of an effect.
  10. // Skill Times Database // // Structure of Database: // SkillID,CastingTime,AfterCastActDelay,AfterCastWalkDelay,Duration1,Duration2,Cool Down,Fixed Casting Time //== Explained: // CastingTime : time to cast this skill, in miliseconds // AfterCastActDelay : "normal" delay, character cannot use skills, in miliseconds // AfterCastWalkDleay : amount of time before character can move again, in miliseconds // Duration1 / Duration2 : usually the durations used by the skill, at special cases it is used to hold special data // Cool Down : amount of time until character can re-use this skill, in miliseconds // Fixed Casting Time: the skills fixed casting time (when 0, uses 20% of cast time and less than 0 means no fixed cast time) //== Extra // On all fields you can use ':' as a delimiter to level-specific values, // - Example using SM_PROVOKE // - Original:6,0,0,0,30000,0,1000 // - ModifiedTo:6,0,0,0,30000,0,1000:2500:3000:etc // - Makes lvl 1 have 1000 (1s) cool down, lvl 2 2500 (2.5s), lvl 3 3000, and so on. //========================================== It says right in db/(re|pre-re)/skill_cast_db.txt what it is. It's labelled "cooldown" in our sources but in game it's called after-cast delay. I couldn't tell you why it was done that way but "after-cast delay" is the closest concept in RO to what other MMOs traditionally call "cooldown". "AfterCastActDelay" and "AfterCastWalkDelay" are used for force motion delay skills. Some lock you in place, some just prevent actions but let you walk around. I know it seems confusing and unintuitive, unfortunately I'm not the one that came up with the names D: All I can tell you is the DB's "Cool Down" is "after-cast delay" in-game, and "AfterCastActDelay" and "AfterCastWalkDelay" are collectively used for "forced motion delay". And on top of all of that is a global delay enforced by your ASPD.
  11. There's no such thing as cooldown in RO. There are 3 different types of delay in play, only one is universal. There's the global skill delay, that's based on your animation speed, specifically your ASPD. You cannot cast faster than your ASPD as your character has to finish the animation for the spell or skill casting before you can cast again. The only way to reduce this delay is to raise your ASPD. And you can never cast faster than the max ASPD of the server. The global delay blocks all skills from being cast during the delay period, not just the skill being used. This is imposed on all skills, regardless of after-cast delay or instacast or whatever. Modern clients will block out your skill bar to indicate you're under the global delay, older clients didn't show it but it's always been a part of RO. After-cast delay is a delay enforced on some skills, for example Soul Breaker, where you can't recast that same skill for a certain time period. This is not the same as the global delay. You can still cast other skills and spells during the after-cast delay, just not the same skill. This is what's reduced by Kiel-D MVP cards and by Poem of Bragi. You can reduce via gears after-cast to the point that it becomes shorter than the global ASPD delay, then your delay is fixed to your ASPD (this is what Poem of Bragi does and what happens if you have enough after-cast delay reducing gear). Other skills have a fixed motion delay where you can't do anything, such as Spiral Pierce, that is independent of ASPD. Even though your animation is quicker the higher your ASPD is you still can't cast it faster than the fixed motion time. This is only reduced by Poem of Bragi. It functions similarly to the global ASPD delay, you can't do anything until the fixed motion delay is over. Basically you can reduce after-cast delay and Poem of Bragi reduces/removes fixed motion delay, but you can never avoid the global skill delay, only reduce it to the maximum ASPD value obtainable on the server.
  12. Will most likely require a source mod as I do not know of any built-in statuses that you can set that would reduce damage from specific skills.
  13. Asura Strike ignores DEF, only element (Asura Strike is neutral so Ghostring reduces damage significantly) and neutral/racial reduction gears works against it.
  14. I personally haven't done any evaluation of the 2013 clients yet (my server still runs on 2012 clients). But those are two good starting points I'll look into!
  15. Any and all clients older than 2010-07-30aRagexeRE are considered depreciated and support for them may go away at any time. We will try to announce ahead of time if we do intentionally break support for those older clients, but bugs may appear on their own as we will not be actively testing against those clients. If bugs do show up they will not be addressed nor fixed. We highly HIGHLY recommend moving to a newer client ASAP.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use and Privacy Policy.