Leaderboard

Can you test this one? - script Monster_Walk -1,{ OnInit: monster "prontera",150,150,"Poring",1002,1; .@id = $@mobid[0]; setarray .@path[0], 155,150, 155,155, 160,155, 165,160; .@size = getarraysize(.@path); while(true) { unitwalk .@id,.@path[.@i*2],.@path[.@i*2 + 1]; .@i = (.@i + 2)%.@size; sleep 1200; } end; }

Forgot the amount. Just change it to: .@id = monster("prontera",150,150,"Poring",1002,1);

I don't know if this will be useful for your or not. - script Monster_Walk -1,{ OnInit: .@id = monster("prontera",150,150,"Poring",1002); setarray .@path[0], 155,150, 155,155, 160,155, 165,160; .@size = getarraysize(.@path); while(true) { unitwalk .@id,.@path[.@i*2],.@path[.@i*2 + 1]; .@i = (.@i + 2)%.@size; sleep 1200; } end; }

Yes, you can download it from this thread

As of now, there isn't a script command to retrieve the timer or the hunted amount of a given mob in a quest. There's only checkquest(<id>,PLAYTIME) or checkquest(<id>,HUNTING) which only retrieves if the timer has been reached, or if the amount has been hunted. It'd be useful to have a command which returns the sd->quest_log[id].time parameter or sd->quest_log.count[j] This way there wouldn't be a need for variables like etower_timer, and this would be useful to retrieve this info instantly for multiple specified quests. Here's what I propose: *getquestinfo(<quest>,<type>{,<mob id>{,<char_id>}) Returns the quest information of the given character. Valid info types: PLAYTIME: returns the internal timer of the quest. HUNTING: returns the amount of <mob id> already hunted. Examples: mes "You've hunted "+getquestinfo(60301,HUNTING,1155)+" Petit."; .@timer = getquestinfo(60200,PLAYTIME); mes "You still have to wait "+Time2Str(.@wait)+" to enter Endless Tower again."; And here's a little snippet to check instance timers easily, which would be one of the main uses of this type of command I think. setarray .@instance$[0],"Endless Tower","Sealed Catacomb"; setarray .@quest_id[0],60200,3040; setarray .@status$[0],"Unavaiaible","990000","Avaiaible","009900"; for(.@size = getarraysize(.@instance$);.@i < .@size;.@i++) { .@time$ = ""; .@status = checkquest(.@quest_id[.@i],PLAYTIME); .@status = .@status == -1 || .@status == 2; if(.@status) { .@timer = getquestinfo(.@quest_id[.@i],PLAYTIME); .@time$ = Time2Str(.@timer); } dispbottom .@instance$[.@i]+": "+.@status$[.@status*2]+" "+.@time$+".","0x"+.@status$[.@status*2 + 1]; } end;

Try this guys. I just had this problem like 5 minutes ago and searched... Just tried it on a novice but should be okay. Just place it inside the lua file. Although it seems like it's messed up.. So we may need still need to get a fix for this. I am using the 2018-06-20e client. Update: Seems it got fixed when I did skillall and then changed bodystyle @_@

Hi all, Sometime last year I started working on a Ragnarok client. (Again...) It's very close in behavior to the original client, using DirectX and the original 3rd party libraries (granny2.dll, mss32.dll etc). It doesn't have a name yet, but I like to think of it as my "SakExe", since that's what it's based on. At this point it can be used for basic gameplay, though much of the user interface is still missing, as well as a lot of the effects. Recently I've made a few changes, making an alternative rendering implementation using OpenGL. After a little work I was able to compile my client for Linux and finally Android. I'll use this topic as a showcase/work log. Feel free to ask any questions. And now for some pictures... DirectX mode on Windows 8. Some features like the Granny3D actors are only supported on Windows. It's working great on Android, although some additional tweaks are needed to make it more accessible. What I've done so far is to scale the UI to make it easier to hit buttons, and adding touch gestures for things like camera rotation. This is with OpenGL ES rendering on my x86 Android phone (1920x1080). It also runs on 32 bit ARM. I've been testing it on both my newest phone and my old Samsung Galaxy Note II, the latter of which is a little over 3 years old at this point. Originally I got like 0.5~2 FPS on my phones with my naive GL renderer, but after some work the performance it pretty solid on both of my phones.

I'm currently working on a custom client and wanted to share some screenshots about the progress. Some of you might wonder why there is again another project like this one with the same goal as the others, and why not just join the others to speed up development? In fact, I thought about this opportunity. However, I'm still learning to work with virtual reality and I want to learn as much as possible. And that's why this projects main goal is not to be finished as fast as possible. But still, it looks like I'm at good pace. I still don't have a "good" name for this project, even though there's a proto-name. One of the other goals of this project is to provide a stable client that runs on both, unix and windows systems. It is being developed in C/C++ and Ogre3D, takes advantage of multithreading where it is appropriate, uses atlas textures to reduce batch count and some other fancy algorithms to improve performance. Even though the complete terrain is being loaded instantly, it takes some milliseconds to finish the objects. That's why I'm currently working on further algorithms, allowing caching and paging of objects. I will release a working demo in the style of RagCam as soon as the new algorithms are finished and working. Here's a list of things that are implemented so far: GND (Terrain) Lightning Shadowmaps Colormaps (with reduced colors to match the original client) Vertex diffuse color Walls Smooth Normals RSM (Objects) Smooth Normals (with smooth groups) Animations Transparency Two Sided Triangle Faces (with correct normal vectors for both sides) RSW (World) Water (with texture and wave animation) Objects Ambient and diffuse lightning Performance is always a very important part for me. A lot of things are optimized as good as possible. This project will stay closed-source providing plug-in functionality in the future. Most of the information that has been used in this project has been discovered through reverse engineering of the original client. Rendering a map is almost completely done using the same and some improved approaches done by the original client itself. The main focus after this will be the visual improvement of the maps themself, like BumpMapping, Cel Shading support, etc. blah blah. When this is done also, I will focus on implementing network functionality and a GUI. I have started in november and worked effectively 5-6 weeks on this project. I had to stop at the end of december and started to work again two days ago. Enough talked, here are some screenshots using OpenGL as renderer (the results in DirectX are the same): Vertex color mapping: Each tile can have a diffuse color. This color, however, is not being applied to all four corners of a tile, but only to the bottom left vertex and all vertices that share the same coordinate. Textures have been disabled in this image to show that diffuse colors are being applied correctly. The border of a map is also being rendered correctly when vertex diffuse colors are applied. Shadowmaps: Some devs are still wondering why their shadowmaps look a bit weird. The reason is plain simple: A lightmap consists (most of the time) of 8x8 tiles, where only the 7x7 pixels in the center are used. Nothing new. However, the tiles are combined into a large texture. If texture filtering is being applied, then the borders of the different textures interpolate into each other, fatal for colormaps when they have different colors. This is called texture bleeding. Because of this, Gravity added a padding of 1 pixel to each tile (resulting in 8x8, instead of 7x7) and filled them with colors that still look nice when they are interpolated. The image below shows the correct display of shadowmaps. Colormaps: They are the same as shadowmaps, but use RGB colors instead. When applied to the terrain, they look smooth. If you look into a dungeon, you will notice that colormaps are not smooth at all. In fact, they look like the colors were reduced. This process is also called posterization. The best result are done with 16 levels. The idea is basically to use float colors, multiply them with the amount of levels, convert the result to an integer (and so dropping the decimal part) and divide the result by the amount of levels. Done. This image displays correct colormaps. Notice the borders of the lightning. Prontera indoor: Transparency: I've used BrowEdit to compare my results and found an issue that was the same as in my project. Some models had wrong depth writing. Using the correct order, it is possible to render objects regardless of their transparency. You can try to open BrowEdit and compare dicastes01 with this image. Instancing: A lot of objects in a map reference the same model, so it makes common sense to combine them for reducing the batch count. This image shows pretty could FPS, even though all objects of yuno are rendered. Instancing in prontera: I would also like to show animations, but am too lazy to upload a video. I am not generating MipMaps yet, since this will be part 2 of this project. As you can see from the screenshots, rendering itself is almost complete. Only some minor issues that have to be done. If you want to see a screenshot of a specific map, don't hesitate to ask. I will upload one. I let you guess which of the posted screenshots are made on linux and which on windows.

Load times are probably only slightly better than the regular client, since it's the same approach. The ground mesh is built on the main thread and must be completed before the map is displayed, while model loading runs on a separate thread and finishes later. On mobile phones it takes a couple of seconds to load a map, and on my PC a typical map loads in under one second. I believe map loading is mostly bound by I/O. No problems with FPS so far and so I haven't bothered to measure it. As mentioned I have both Direct3D or OpenGL implementations to support the renderer. I believe OpenGL is the most performant one since I've made some adjustments to heavily batch render calls. Effects are for the most part identical to their originals effect. I can't quite copy-paste from the original client, but I can borrow the approach. Here's an example of how a simple effect is implemented: void CRagEffect::IncAgility(void) { matrix vtm; tlvertex3d vert; vector3d src; src = m_master->m_pos; vtm = g_modeMgr.GetGameMode()->m_view->m_viewMatrix; g_renderer->ProjectVertex(src, vtm, &vert); m_tlvertX = vert.x; m_tlvertY = vert.y; m_pos = m_master->m_pos; if (m_stateCnt == 0) { auto player = g_modeMgr.GetGameMode()->m_world->m_player; float z = m_pos.z - player->m_pos.z; float x = m_pos.x - player->m_pos.x; PlayWave("effect\\EF_IncAgility.wav", x, 0.0f, z, 250, 40, 1.0f); g_prim = LaunchEffectPrim(PP_2DTEXTURE, { 0, 0, 0 }); g_prim->m_duration = m_duration; g_prim->m_longitude = 0; g_prim->m_speed = 1.5f; g_prim->m_accel = g_prim->m_speed / g_prim->m_duration * -1.2f; g_prim->m_widthSize = 40.0f; g_prim->m_heightSize = 20.0f; g_prim->m_alpha = 0; g_prim->m_maxAlpha = 200.0f; g_prim->m_alphaSpeed = g_prim->m_maxAlpha * 0.06666667f; g_prim->m_fadeOutCnt = g_prim->m_duration - 15; g_prim->m_texture = new CTexture*[g_prim->m_totalTexture](); g_prim->m_texture[0] = g_texMgr.GetTexture("effect\\agi_up.bmp", false); } if ((m_stateCnt % 2) == 0) { g_prim = LaunchEffectPrim(PP_3DCROSSTEXTURE, { 0, 0, 0 }); g_prim->m_duration = 50; g_prim->m_matrix.MakeYRotation(GetRadian(rand() % 360)); g_prim->m_deltaPos2 = vector3d(0.0f, 0.0f, (float)(rand() % 7 + 2)) * g_prim->m_matrix; g_prim->m_matrix.MakeXRotation(GetRadian(90)); g_prim->m_speed = (rand() % 50 + 20) * 0.01f; g_prim->m_widthSize = (rand() % 60 + 30) * 0.1f; g_prim->m_heightSize = 0.18f; g_prim->m_alpha = 0; g_prim->m_maxAlpha = 200.0f; g_prim->m_alphaSpeed = g_prim->m_maxAlpha * 0.05f; g_prim->m_fadeOutCnt = g_prim->m_duration - 20; g_prim->m_texture = new CTexture*[g_prim->m_totalTexture](); g_prim->m_texture[0] = g_texMgr.GetTexture("effect\\ac_center2.tga", false); } }

It's very helpful that Athena developers have attempted to keep backwards compatibility with older clients -- all despite an increasing pile of spaghetti code as seen in functions such as clif_set_unit_idle. With rAthena you can ostensibly compile the server for any given version network protocol. Of course, as people move on to newer clients, the old clients aren't really tested anymore and many things can go wrong. The result is that rAthena supports a lot of strange packet versions that are something of a mix between old and new. But in the end, the only thing that matters is that the server and client understands each other. Luckily it didn't take too much effort to get my client working with the latest trunk revision. Renewal seems to work also, although I got resource crashed from some new monster called "little poring" or something?? Below: me battling it out @ glast with rAthena pre-RE

To settle the question of open source once and for all: I'm planning to release the full source code sometime in the future. When the code is released, anyone who wishes to do so will be free to fork the project, add renewal features, organize their own development teams and whatever. As I've already stated, I will not be interested in collaboration. I will release when I've reached my milestone for feature completion, and this will be the first and final release.

That is about right. All effects (CRagEffect) simply configure instances of effect primitives (CEffectPrim), with the only exception of effects based on the STR format (what Gravity calls the "EZ effects" ). Effect primitives are animated in code, and buffers for effect primitives are constructed on a per-frame basis. Making these effects is basically like working with a 3D canvas from the code, where everything is dumped in the renderer's queue. In many cases an effect primitive is something non-specific like a half sphere, where properties like radius and opacity is changed over time. There are also many primitives specific to individual skills. A skill can have multiple effects, which in turn can use multiple effect primitives and STR effects. For instance, Acolyte's Heal uses four different effects based on the amount healed. A rough description of how the skills you picked out are implemented: Magnum Break - Two expanding spheres and a 3D circle on the ground Cold/Fire Bolt - The bolts are just textures moving towards the target, combined with an expanding 3D circle on target Frost Diver/Grimtooth/Frost Nova - just multiple spikes growing in random directions, spawned one by one for the duration of the skill Safety Wall/Heal - 3D cylinder changing height with the texture fading out in the top, plus some floating particles here and there Cart Revolution - Combination of STR effect, an expanding 3D sphere and an expanding 3D circle Attack skills will often have one part for the skill itself, and one for when the target is hit. Damage effect is also varied, often based on the element of the attack. Most skills will additionally have a special effect on the player, like the glowing cylinder around the magician when a spell begins. There are lots of different ones. Skills using only a simple STR are relatively uncommon. By the way, looking forward to updates on your project.

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.

pre-renewal is better all in all.