Shinryo

Unfortunately, my HDD got a problem and I lost the source code. Nah, just kidding. The HDD is lost, but I still had backup of rev25. The most important stuff is still available. However, the bugfixes after this revision have to be remade. I have uploaded the source code for both, the patcher and the plugins here: https://subversion.a...ls/src/WeeDiff/ Read the notes for further information. I don't have the time anymore to maintain the source, maybe someone else will be able to continue it. Thanks to everyone who supported it up 'til now!

I have finished with an algorithm that allows me to create a raycast from the mouse into the terrain to find out on which cell the mouse currently is over (splitting the cells up into bounding boxes, up to the root node). Thanks to KeyWorld for some hints! Basically, there is almost no performance decrease with this algorithm. Besides that, I have worked more on the camera control and have finished it completely. This means the camera behavior is now exactly the same (and even better) than the original clients camera. I have also finished a normalmap generator to apply bump mapping. I have applied them only to the ground yet. And since I have promised to post some screens the last time, here they are (models and shadows are hidden for debuggin purposes): Testmap without bump mapping: http://www.abload.de/img/screenshot04202012_1961kdk.png Same testmap with bump mapping: http://www.abload.de/img/screenshot04202012_19l9d7q.png Prontera field: http://www.abload.de/img/screenshot04202012_234ei0c.png Hugel: http://www.abload.de/img/screenshot04202012_23d5dvf.png I'm stil working on the shader, so there will be some improvements in the near future.

Your snippets seems to contain only sanity checks for the camera related to distance and latitude/longitude. The function name CRenderer::SetSize sounds confusing, but seems to contain the code for the matrix.

No screens this time, but expect to get some with my next post. I have finished orbit camera control today (even though it's pretty easy to do with ogre) and noticed something while I compared some old screens made with the orignial client and those screens made with my implementation. It looks like objects have a different angular area. Most applications use 45° - 60° for the y-dimension field of view. Ragnarok, however, seems to have 20° (gives almost identical results). However, I doubt they use 20°, but moreover 340°, which results in a verticaly flipped y-axis (sounds familiar, huh? probably a mistake made by Gravity a decade ago when they built the projection matrix with DirectX7). I don't have the desire to reverse engineer this part of the original client to be 100% sure, so did someone made already research in this area and can confirm my assumption?

Thanks! I've spent some time today to fix a problem related to opacity. Every 3D artist or programmer dreams about order independent transparency. Sadly, 'til now there's no real efficient solution for real-time rendering in games and I had to find another solution that is order dependent and still works with mipmaps. Here are two screenshots. Before: http://img4.picload.org/image/rlgcgip/screenshot031320.png After: http://img2.picload.org/image/rlgcgpr/screenshot031320.png It seems like there's no map with opacity artifacts anymore and I'm pretty satisfied with the result.

Just a quick drop: I'm still working on this project and have used my recently free time to focus on the rendering part and improve it further (since this is one of the main goals). Here are some high resolution screenshots from the current real-time rendering. Take note that I have disabled shadows on objects, since I have written a new concept for calculating the normals and haven't implemented it yet. Will follow soon. These screens have been made with OpenGL as rendering system. Izlude: http://img3.picload....nshot031120.png Prontera: http://img3.picload....nshot031120.png Hugel: http://img2.picload....nshot031120.png Comodo: http://img2.picload....nshot031120.png Yuno: http://img3.picload....nshot031120.png Prontera Field: http://img2.picload....nshot031120.png Rachel: http://img3.picload....nshot031120.png Prontera Guild Castle: http://img4.picload....nshot031120.png Payon Dungeon: http://img2.picload....nshot031120.png WoE 2.0 Castle: http://img3.picload....nshot031120.png Dicastes: http://img2.picload....nshot031120.png @Gepard: Right now, it seems like the source will be released after I graduate from school (this will be somewhere around september). I will try to build up a community which focuses on those stuff you have mentioned. You can implement this behaviour yourself if needed. The reason why it will go open source is because I have already lost most of my intereset in ragnarok. I have promised that I will release the source if this shall happen (Tera Online is the culprit..!).

You mean the decentralized approach used by GIT, where each developer has his own full copy of the project? I'm note quite sure if this would really improve the workflow of such a small project as rAthena.. Doesn't the first part sound exactly like subversion? In addition, it has the diff option, but you're not forced to use it. Or do you mean that anyone, even without access to the CVS, can commit changes and the rAthena developers have to decide whetever a commit will be accepted or not? I'm actually doing this myself with subversion, where I just merge the changes from the original repository to my own (with conflicts coming up now and then). Is it correct to believe that GIT does not have this conflicts? If it has them, why is it better than SVN? On what os are you developing? I'm on windows and don't want to miss something like TortoiseSVN's integration into the explorer. Has GIT similiar tools or what tools sound better than those for SVN? rAthena does not have the same size as the linux core (GIT was developed for this purpose, no?). So could someone make a comparison of the size difference between GIT and SVN with rAthena? Isn't this also possible with SVN, even easier? I don't fully agree on this one. Who are those end-users? Probably not the players on a server, but those that run the emulator and therefore maintain the server. Especially critical for bug hunting which is only really successful with the help of those end-users. I won't say that it is impossible to hunt bugs the other way, but this way lessens the burden on the developers. It seems like the decision should be made on the type of project, but so far I haven't really saw any real reason why rAthena would actually benefit from using GIT. I have read some recent articles that wrote about "Why GIT is better than SVN!" and felt sad that there is no realy "Why SVN is better than GIT!" which leads to the thoughts that it really is just some hype with praised features that work in theory, but haven't proved yet in practise since it's a pretty young project, whereas subversion have been proven to be easy to use. Here are also some links that don't praise GIT: http://www.databasesandlife.com/why-subversion-is-better-than-git/ http://programmers.stackexchange.com/questions/111633/what-does-svn-do-better-than-git http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/

Just because Linus Torvalds is involved with GIT or because of the hype? I might not be a GIT-Guru, so could you clarify some of your arguments? What functionalities and compression methods has GIT? How would a project, such as rAthena, benefit of using GIT instead of Subversion? Can you give a link where it is written down, that Mozilla really saved 80% of memory? Is this related to the compression methods (just out of curiosity)? What exactly seems to be faster? I thought Subversion is popular for their definition of "branching", where does GIT differ from Subversion in this case? Why is it easier to work in teams? How does the merging work like? What do you mean with "still getting updates and also creating hotfixxes"? Seems like I'm quite a noob, so could you explain this benefits in details from your personal experience with GIT?

@mrjnumber1: You obviously look only onto one side of a medal, and it's probably the one that gives you the most advantage. Almost all your points are related to exactly the same thing. Even if there shall be a huge bug, I doubt that most of the people out there would share the knowledge about the existence of such a bug as long as there is no "real team" behind this project. Fixing a bug and keeping it to the own server gives an advantage after all. That's what most (not all) people would do. Keeping the critical parts closed source will force everyone to at least drop a note if they seriously shall use my implementation. However, you basically say that open source would be much better, 'cause everyone could fix and improve everything on their own. So where shall this fixes and improvements go to? This is just a hobby project to learn more about virtual reality. I'm not Linus Torvalds with a team behind this project that maintains the core. It's just a project for personal use, giving the possibility for others to use this client and add custom implementations. I won't force anyone to use it after all. As you might already noticed by now, it really makes no sense to release such project as open source as long as there is no team behind it. Summary: IF there shall be a huge bug, IF there shall be an exploit and IF there shall be bad code that hurts the performance, then there are two options: 1) Drop me a note and I will fix those bugs as soon as possible. In the end, I'm the one who wrote the code and therefore the one who knows how to fix the bug as fast as possible. People that focus on adding customizations (while open sourced) will never know how the core really works as long as they never work on the core itself. And if you think that an open source project would give them the access to the core so that they could work on it: don't you think it would be much better when they drop me a PN asking to join the project, instead of creating just another clone? It is no coincindence that the other client projects died so easily. I wonder how that could happen, they were open source after all? 2) I lose interest or don't do anything for a long time on this project. So what? If that happen, I will make sure to release the source anyway, so that's not much of a problem. If I should have a stable base client and a decent team that works on this project, then the source might get released. As long as this is not the case, this project will stay closed source.

I've spent some time to improve resource loading. There's no caching done yet, but I'm still pretty satisfied with the current performance. Should be increased even further as soon as the caching is done. Here's a small video that shows how the rendering is actually done: The objects in this video are rendered based on the distance from characters position. I've set an initial position at the origin. Take note that I have forgotten to enable object lightning and noticed this only after I have finished rendering the video, lol...

Tried to use /showname?

The points in your list can be easily implemented with the help of a plugin system. I know how most of the users out there feel to have an open source client to add customizations to it. That's why I will focus to allow a lot of modifcations. However, as you might already read out from my first post, I don't hesitate to share the information that I have extracted from the original client. And these information are probably what most people are interested in anyway. So why am I still going for closed source? Simple: If reduced down, there are two factions of people. Those which focus to implement the ideas you're talking about and those that will use this ideas and indeed make money from the work of others (most likely how it is with eAthena/rAthena). I don't see the point why the second faction shall gain all the money without doing anything. I am working with a lot of interfaces that allow splitting very easy. Basically something like this: As you can see, those people with ideas can hook everywhere they want to extend whatever they want. They can even completely reimplement the closed parts and use it for whatever they want. Let's say if I have implemented a class that allows a sprite to run around, but someone wants a 3D character instead, he can write his own implementation and exchange it without changing any other parts. Some could even change the rendering engine from Ogre3D to Irrlich, if they want to. They just have to make sure to implement the given interfaces, which will be open source since they are only guide lines. You might still wonder what to do when some interfaces themself have to be modified. Well, I'll add the ability to hook the core which might be risky. But I assume that the one who wants to change one of the interfaces knows what he does, so that should not be a problem. This ensures that those with gread ideas have the possibility to chose if their implementations shall be closed or open source (for the same reasons as I have) and those that want only money still have to do something on their own. And even if I drop this project, as long as the base is done and available, anyone else can still further improve it. Besides that, you don't really have to worry. If I lose intereset or stop working on any of my projects, I'm gonna release the source anyway. So when I shall disappear, I will make sure to release the source (as I will do with WeeDiffGen). The only problem that might come up is the fact, that only a small amount of people are willing to continue such a project as soon as it gets open sourced. I hope you can understand this decision of mine.

Mind to explain your opinion?

Heh.. good catch. I have the same model there: However, the solution is pretty simple. The original client uses a quadtree to improve culling performance. Each model intersects or is within at least one quadtree node. If a model does not belong to a node, than it won't get rendered at all. Basically, those nodes are bounding boxes. The client gets all those boxes that are within the viewing frustum. Afterwards, the client checks which models belong to which quadtree node and renders them. The object in the screen does not belong to any node and therefore shall not be rendered. If you don't use a quadtree (or octree, whatever), then there is another simple solution: All quadtree nodes are (or have to be) within the xz-coordinates of the ground bounding box. So if a model has a position that is not within this range, then just don't render it.

Thanks! I have been working and experimenting a lot with different plugin architectures (e.g. in WeeDiffgen), so that won't give any problems. I have indeed plans to isolate rendering from networking and everything else. The possibility to install hooks would be quite useful. As you may already know, there are also quite a lot of hard-coded effects (that are not really hard to reimplement) which are too many to implement them on my own. I will, however, implement a LUA supported "effect engine" so that others can help creating those effects too. The GUI will be based on XML layouts, allowing everyone to modify whatever they want. So yes, even though I will use closed source plugins, I will indeed release interfaces so that everyone can create their own implementations or install hooks to extend the whole system itself with no restrictions. I'm not quite sure if it would make sense to provide full securing features, since they would be reversed anyway. But I will keep the possibility of creating a very simple skeleton, giving others the idea on how to implement packet encryption, grf protection, etc. on their own.

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.

I'm quite bussy with school projects right now, so there are no updates for now. However, I'm not sure if I will continue this projects, 'cause I have too many others running. I will release the complete source codes in the new few weeks so that some other can grab and continue it.

Holding the Ctrl key while doing the screenshot does not work for you?

I haven't worked with auctions yet. If you can explain what exactly has to be changed client side (would be best with screenshots), I may add such a plug-in.

Just as the map server says: This map does not exist. If you have copied this script from somewhere, than don't forget to rename the map where mvps have to spawn... E.g. - script mvp spawned -1,{ OnInit: setarray $@mvpID[0],1511,1674,1785,1039,1874,1272,1719,1046,1389,1112,1115,1658,1957, 1418,1871,1252,1786,1086,1885,1649,1651,1832,1492,1734,1251,1779,1688,1646,1373, 1147,1059,1150,1956,1087,1190,1038,1157,1159,1052,1623,1917,1650,1583,1389,1312, 1751,1685,1630,1648; for(set .i,0; .i<getarraysize($@mvpID); set .i,.i+1) {monster "prontera",0,0,""+getmonsterinfo($@mvpID[.i],0)+"",$@mvpID[.i],1;} end; OnNPCKillEvent: getmapxy(@map$,@x,@y,0); if (@map$ == "prontera") {for(set @i,0; @i<getarraysize($@mvpID); set @i,@i+1) {if (killedrid==$@mvpID) {monster "@map$",0,0,""+getmonsterinfo($@mvpID[@i],0)+"",$@mvpID[@i],1;}}} end; }

That's probably something that should be optimized anyway. It's not a good idea to hard code such information. Your approach is correct Epoque, it's just that this kind of things have been handled the wrong way from the start and there is no other way to solve this. A better idea is to add new script commands that allows to check for some status changes and behave accordingly. Here's an example (which hasn't been tested though): BUILDIN_FUNC(getscdata) { struct map_session_data *sd = NULL; int sc_type = script_getnum(st,2); if(script_hasdata(st,3)) sd = map_nick2sd(script_getstr(st,3)); else sd = script_rid2sd(st); if(sc_type >= 0 && sc_type < SC_MAX && sd && sd->sc.data[sc_type]) { struct status_change_entry *sce = sd->sc.data[sc_type]; pc_setreg(sd, reference_uid(add_str("@scdata"), 0), sc_type); pc_setreg(sd, reference_uid(add_str("@scdata"), 1), sce->timer); pc_setreg(sd, reference_uid(add_str("@scdata"), 2), sce->val1); pc_setreg(sd, reference_uid(add_str("@scdata"), 3), sce->val2); pc_setreg(sd, reference_uid(add_str("@scdata"), 4), sce->val3); pc_setreg(sd, reference_uid(add_str("@scdata"), 5), sce->val4); script_pushint(st, 1); return 0; } script_pushint(st, 0); return 0; } In combination with an exp manual, the item script would look like this: 14532,Battle_Manual25,Field Manual 25%,2,,,10,,,,,0xFFFFFFFF,7,2,,,,,,{ if(!getscdata(SC_EXPBOOST)) sc_start SC_EXPBOOST,1800000,25; },{},{} This approach does not only benefit from being more flexible. It also allows scripts to use the newly created script commands. You can check other players for status changes, how long the status will remain, etc. It will simply fill the @scdata array with those information. Or have I missed something and didn't take it into account?

Check 'battle_calc_weapon_damage' in 'battle.c' and search everything that has to do with 'flag.cri'. Besides that, what do you mean with 'instead of increasing'. As far as I remember this kind of behavior (increase damage while not ignore defense) is only available in renewal mechanics which aren't implemented in eAthena, yet. What revision are you using anyway? There are so much possibilites and the only way to find out why it behaves the way you saw it on your server, is to simply provide more information.

There are more steps involved to get core dumps that have detailed information about the crash reason. First, eAthena has to be configured to enable debugging (e.g. for gdb): ./configure --enable-debug=gdb If you don't want to edit the limits in the post above, but only for the current running shell, then use this: ulimit -c unlimited More about this here: http://compute.cnr.b...an-cgi?ulimit+2 You can run the server now. Afterwards,you will have a file named 'core' (or something similiar) within your eAthena folder as soon as the server crashes. Use this to get detailed information: gdb <server> <core>, e.g. gdb map-server_sql core You may have to install gdb first with 'apt-get install gdb', however, inside gdb enter this to get detailed information: bt full It will display a call stack where the last called function is at top. There's also a line displayed to show you where the crash happened. Go ahead and check this line to fix it.

WeeDiffGen <no image available> Info: Plug-in for my diff patcher that allows you to generate diffs on the fly without the need of a diff file. Clients 2010-08-17bRagexeRE 'till 2011-04-05aRagexeRE parsed successfully. Features: Allows input boxes Inline descriptions Has an easy to use interface to create further diffs Plug-in based (you can just delete diff plug-ins which you never use) Supports 35+ diffs so far Probably some others that I forgot for now Downloads: WeeDiffGen SVN WeeDiffGen Plugins SVN WeeDiffGen Interface SVN Quick Usage 1. Grab the Diff Patcher here: http://www.eathena.w...howtopic=268538 2. Download WeeDiffGen.dll from SVN and place it inside the plug-ins folder of the patcher. 3. Create a folder named "WeeDiffGen" inside the plug-ins folder and paste your desired plug-ins there. 4. Start the patcher and select WeeDiffGen as patch engine. 5. Select an executable. 6. Select your diffs. 7. Select output file. 8. Patch it. Alternatively: Download the whole repository from here: https://subversion.assembla.com/svn/weetool...insDiffPatcher/ Notes: This release is not the final one. It is meant for developers to test and implement new stuff without taking care of hexing newer clients. Also, it may still contain some bugs. I won't give any support on how to implement server side code to get your server working with those clients. However, the generator itself creates a log file in case a diff should break. Should a diff not been listed in the patcher, then it probably failed to parse and added an entry inside of the file "Patcher/plugins/WeeDiffGen/WeeDiffGen.log". If you never used a specific diff, then just don't place it inside the plug-ins folder of WeeDiffGen. This way you have the possibility of only using those diffs that you have always used. Don't forget that this plug-in only works with my Diff Patcher above or equal to version 1.1a. So if you still use the old version then go and update it. It will also work only on clients that were compiled with VC9. Also, you can request a diff that has been already marked as obsolete. As long as there is enough interest in a diff, I don't mind to fix/create it.

Shin's Diff Patcher Info: Supports all Windows 32 bit versions (Windows XP SP2 and higher) and probably all 64 bit versions. Features: Plug-in based Uses list view instead of two seperate list boxes for easier selection Shortcuts to simplify your work Resizable window Inline diff descriptions (as long as the plug-in supports it) Auto-save and load of diffs Includes PlainDiffPlugin which provides support for *.diff files Allows items to be sorted either by type, group or diff name Prevents diff collision when selecting diffs that reference the same group CRC file check Data missmatch check Downloads: ShinsDiffPatcher SVN (Version 1.1.3b; 198kb) WeeDiffPlain Plugin Src SVN (Version 1.0; 11kb) Quick Usage 1. Select patch engine. 2. Select client exe. 3. Select diff file (if plug-in needs it). 4. Select output exe. 5. Click on "Patch It!" 6. Done. All patches that you have selected are automatically saved and will be restored the next time you select a diff file. You can also use the following shortcuts: - Ctrl + A = Select all diffs (only one item from each group if any) - Ctrl + D = Deselect all selected diffs - Ctrl + C = Copy all selected diffs into Clipboard Notes: You may think "What? Another patcher? Man..". Yes, another one. I'm not quite satisfied with the currently available diff patchers because they either lack of features or just don't provide the freedom I would like to have. I think I have chosen this name for the patcher because it's kinda convention to use his own name in the title bar (even though the initial name is WeeDiffPatcher). This is just an alpha release since there are some optimizations I would like to complete before I release a final version. I've included the source code for the DiffPlainPlugin to show you how you can implement your own plug-ins in order to get them working with my patcher. I would still like someone else to implement a proper plain diff plug-in because I haven't focused to optimize it to it's best (even though I have removed all possible memory leaks) since I developed this patcher for another plug-in based solution. If you have any suggestions or features that your plug-in needs in the future, don't hesitate to ask.