Leaderboard

This afternoon I enabled all groups on the forums to be able to upload their work to Files and put a price on them. What does this mean? Two things. Firstly, it means that any user on the forum is able to charge for their uploaded File. This has proven to be profitable in more ways than just of a monetary value. In the past, amazing features, code, maps, sprites, images, etc were created knowing that hard work would be met with funds in their account to either spend on the forums, or request via paypal. This encouraged a higher standard of working which produced a large number of projects. Secondly, it means that rAthena can survive for longer without further cashflow injections from elsewhere. Donations are marvellous, but they don't cover the monthly costs. Paid Files have a Tax value of 20% which covers the paypal fees and ensures that a few cents are kept in rA's coffers. Over the course of a month, these values would help to pay for our hosting. All paid files will be approved by either @Aleos or myself to begin with. The approval process will be strict - if your file is not of high quality, it will be rejected. Files that were previously uploaded to the forums when Nexus was alive no longer exist. If you had a paid file and want to charge for it, you will need to re-upload it (I deleted them all when i found that moderators had still been downloading them after they were hidden during my absence last year). If you run into any problems with permissions, please let me know as soon as possible via Forum PM!

So, no wonder why? most paid files got a lot of downloads because they're using superior Member as Moderator. I would suggest don't let 'Moderators' able to download the file. they must PAID it before they can download the certain files.

Better be careful with high poly models. We recommend to split to 2000 faces. You might see some models with more faces work tho, (like that of 9k) sometimes, but most of the times can make your client crash. Regarding animation you have 2 options, and I did two videos on my channel, one with RSM ro models (only supported with old clients tho) or as npc GR2 models (supported by all clients)

Hi there, browedit has no limits but the RO client has: 1500 to 2000 as said before. I have to disagree about the increased limit tho, is the same even by recent RO clients. Recent models have better quality yes, but what Gravity does is they split some buildings in pieces (for ex. new prontera church) so they can trick that face limit.

Syouji estimates 1500-2000 EDIT: Given these tutorials were made ages ago and Gravity uses higher quality models now, this may no longer be accurate. Regards, ~Azura Skyy

Forgotten features While revisiting games I've played for years, one of the things I find the most exciting is discovering new features. By this I mean features that were planned at some point, but in the end never made it into the final product. When projects get to a certain size there will always be a few ideas that are rejected - some at a stage where you can still find remnants in the final product. In the case of Ragnarok we even had the lead designer leaving the company relatively early on. Despite the reason for this not being public, one of the reasons I've heard cited is that he didn't get the creative freedom he wanted. Who knows what might have been? In any event, what follows are a few features I've discovered that never made it into the final game. Highly immersive footwear As you're probably aware, the player characters change appearance based on the equipped items. The first layers are the body and head sprites, followed by up to three different accessories (upper, lower, mid). There's the left and right hand weapons, as well as the shield. Different sprites for different shoes were planned as well. In old versions of the network protocol you can even find shoe IDs in the player structures. This feature was most likely eventually left out because it would simply be too much work to animate the shoes for all the different classes. Even special weapon and shield sprites have been somewhat limited in use, and I believe these require significantly less work than it would take to create shoe sprites. Having players leaving footprints was also planned early on. From the looks of it this was originally meant to complement the different shoe types. I think when they scrapped shoe sprites idea they also forgot about the footprints. The effect is still present in the client, although I believe they intended to refine it a bit more. I guess it was eventually used for the Stalker class' Stealth skill. Here's what it would originally have looked like if enabled when normal players walk around: Destroyable maps? In Ragnarok the map is completely static, which is pretty boring. A partially implement feature would allow dynamic changes in the map elevation. It's uncertain how this would be used in practice, and therefore also why they chose to leave it out. Maybe they intended that the map could be destroyed by skills? E.g. have meteor storm leave a deep crater on the ground. That could be a pretty cool feature. Maybe I'll try implementing it myself someday. Model culling Another cool effect that was left out was having static models between the camera and the player disappear so that they don't hide the player. I'm not sure if the models were planned to be completely or just partially hidden. This feature was more or less complete, but the approach used is maybe to simple so that it doesn't always work as intended. I also discovered a bug in the calculation of the bounding box used especially for this purpose. You can actually try out this feature by using NEMO patcher, as I found a relatively simple approach to enabling it. Just enable "Restore model culling" when patching your client. Sky box This one is pretty self-explanatory if you've ever worked with 3D. Instead of having the background of the map be completely black (or blue like in Yuno), the client could instead show a picture of the sky or a landscape in the far distant. It's one of the simplest and most common effects used in video games to improve immersion, so it's a shame they never got around to finishing it. Weather There are some working weather related effects like snow and fog in-game, but a much more comprehensive system was planned at some point. This would include dynamic sun location and a true day/night cycle. One problem was probably that model shadows in Ragnarok are precomputed. A rain effect was implemented, but it was probably never finished as it looks pretty bad. The jRO team used to have some pictures related to this on their news page, and I believe they planned to release the new weather system with the Yuno update. Private server developers took matters into their own hands. If you played on an eAthena server around 2004 you may remember the horrible night effect that was enabled by default: Enabling the blind effect on all players until it was "morning" again! Everything 3D Considering the fact that licensing the RAD Game Tools SDK must have been pretty expensive, it's strange that Gravity never did more with Granny3D than implementing guild flags, the emperium and the castle guardians. (Not to mention Zombie Dragon!) Additionally as I mentioned in a previous post, Gravity already had their own RSX format which would have been sufficient if they only wanted a few simple 3D actors. The obvious explanation is that they wanted to do much more with it. Indeed, it appears that at one point they planned to introduce 3D customizable player characters. Perhaps this was a reaction to contemporary MMO titles, where full 3D quickly became the norm. The results of these experiments were never disclosed, so what it would have looked like is a mystery.

A brief look at RagExe Game Framework Class (GFC) is Gravity's own name for the game engine or application architecture used in Ragnarok Online. With the Ragnarok beta release in 2001, Gravity announced the finalization of GFC 2.0. But what exactly is GFC, and where did it come from? Most game developers use commercial proprietary engines for their games, while GFC is an in-house product by Gravity's RND-1 development division. In truth, it's misleading to call it a game engine, as GFC in its current form has been used in exactly one game and is tightly coupled to it. In all likelyhood the name GFC and the notion of a game engine are just buzzwords Gravity used in an attempt at impressing investors in their early days. However, my client is strictly based on Gravity's RagExe implementation, and I guess it can therefore be said to be a clone of GFC. Here's a brief look at its history. Gravity Corp. was a relatively small developer before Ragnarok Online became an international success. Certainly no one outside of South Korea knew of them. In fact, right up until Ragnarok become ready for alpha testing they were still just Team Gravity. In 1999 they partnered up with Sonnori Entertainment in a joint venture to develop an action RPG. Arcturus: The Curse and Loss of Divinity was released with success in 2000. At this point Gravity obtained the rights to publish a game based on the popular Korean comic Ragnarök. They decided to reuse source code from Arcturus. While Arcturus and Ragnarok don't have much in common in terms of game play, resemblances can be noticed in aspects such as artistic style and music. Making Arcturus into the Ragnarok we know today required a severe overhaul of the code base. However, in many architectural decisions were left intact. What was retained became the base of GFC. Ragnarok, like Arcturus, is a 2.5D game. While Gravity at one point experimented with 3D actors in Ragnarok, the main focus has always been on sprite-based characters in a 3D world. Most of the file formats from Arcturus could therefore be reused directly in Ragnarok. This is one of the reasons why some of Gravity's file formats have strange features. For instance the world resource format (RSW) contains strings pointing to scripts files, a feature not used in Ragnarok. Some formats, like RSX (think RSM for actors) were retained and is still in the code base, but never used. A few formats from Arcturus you may know include: SPR - indexed color bitmap format ACT - actor animation RSM - hierarchical 3D models with basic animation support GND - tile based ground mesh GAT - tile based property map RSW - map format (defines a scene with objects) They also made new formats, like the worthless IMF format that no one understand what is supposed to do... (Just kidding, IMF is used when combining ACT files for player characters, but it turns out it wasn't really necessary or useful. The client uses IMF offsets when drawing the player on the character select, which is probably why headgear sometimes looks a little wonky there. It also uses it for drawing order for player character sprites in-game.) While based on DirectX 7.0, from a modern perspective GFC can be said to be software rendered. If you've ever wondered why Ragnarok uses so much CPU, that is why! Direct3D is only used as a glorified triangle rasterizer with blending and depth buffering. GFC has a fairly large entity-based actor system where every actor is responsible for rendering themselves every frame. There are a few principal object types: ground (GND), models (e.g. RSM) and game objects (actors, effects, etc). Rendering done by registering a render pass from with the renderer - basically a list of screen projected vertices and a texture. The renderer sorts the render passes by depth, opacity and other attributes, and draws everything at the end of each game cycle. This all makes for a pretty horrible design. Easy to work with, but unnecessarily taxing on the system. The only reason it worked in the first place is the low amount of polygons on the screen. (Typically below 10,000 triangles at any time.) Game objects communicate by passing messages around to each other. In Ragnarok, there is also a global state (the session) and the current game mode, which is responsible for tasks like processing input, creating actors, handling network messages and signalling actors. The diagram above shows part of the base object hierarchy in Arcturus, which is pretty tall and convoluted. In Arcturus, each enemy needed its own class specialization. In comparison the diagram below shows the object hierarchy at the time of the Ragnarok alpha release. While simplified, the principal structure is the same. I have colored a few classes that provide similar functionality in the two games. CRenderObject is any type of object that is draw on the screen, while CGameActor is any object that can be interacted with. CPc is the object type for characters controlled by a player. CNpc covers static NPCs and monsters. In Arcturus you could interact with certain 3D models (e.g. doors, chests), so C3dActor was a part of the game object hierarchy. In Ragnarok, all 3D models are just decoration and not part of the game play and aren't considered game objects. (The exceptions to the rule are Granny actors and traps, the latter of which are actually RSM models drawn by a Skill object.) From the Ragnarok alpha to commercial release the renderer was improved a bit, and the 2D actor system become more flexible. A few libraries from RAD Game Tools was integrated to provide sound, video playback and a more practical 3D format (namely GR2, thought it's only been used for a few models). Aside from that, not much has changed.