Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Shinryo last won the day on September 11 2018

Shinryo had the most liked content!

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Shinryo's Achievements


Poring (1/15)

  • Innovator Rare

Recent Badges



  1. Nope. Still ongoing. Made some heavy cleanups and will release some binary prototypes soon.
  2. What kind of a bug is it? Maybe it got fixed in recent webkit versions. Qt 5 also allows to embedd a webview based on webkit, which basically would give the same benefits as Awesomium or Berkelium.
  3. Still ongoing. Abandoning this project in its current state would be a crime to myself. I was just very busy in the last few months with my new job and playing Tera Online, lol. However, I have stopped playing MMORPGs in general and like to spend my free time with the development of the client to improve my virtual reality knowledge. I have reviewed some scripting engines like LUA, AngleScript, Python, etc. As far as I remember, V8 is the rendering engine behind Chromium? Might take a look at it. I've spent the last few days to also review some GUIs which would not be a performance bottleneck. CEGUI is indeed easy to use through it's XML structure, but it also introduces some limitations for transitions or animations. Awesomium (used in Fimbulwinter Client) and Berkelium allow to render Chromium inside an offscreen buffer and therefore allow to create animations and transitions based on CSS3 and HTML5. But the performance of blitting the rendered offscreen back to a texture might slow down the client too much, especially in high resolutions (like 1920x1080). Another approach would be to use QML with Qt5 for GUI rendering which includes animations and transitions. It renders directly to a framebuffer object and is therefore pretty fast. But this works only with OpenGL. I don't plan to insert such limits. Quite the opposite, I plan to add further 3D file formats to not only support Granny3D objects. Yep. I have yet to decide from what version upward. Nope. ------------------- Some notes: As already mentioned, I have not yet decided which scripting engine to use. I also struggle whetever I shall drop DirectX support and continue GUI development with Qt 5 and QML, based on OpenGL and Ogre3D. It seems like Qt 5 has also support for V8. On the other side, I cannot depend on V8 from Qt, since the current codebase is split into core, rendering, networking, scripting, etc. So the scripting part will be gone if someone decides to replace the Ogre3D and Qt 5 rendering with a custom rendering engine. Mhm... My best bet would probably be: - Rendering: Ogre3D, OpenGL only, Qt 5 and QML - Scripting: AngleScript - Networking: Boost.Asio Oh, and as a side note: I have forked the core module into an editor module yesterday, which uses the same rendering and scripting modules. The main purpose is to allow easier debugging of visual artifacts. It might become a full fledged map editor though.
  4. No, the project is far away from being dead. I've got a new job more than a month ago and this caused the project to slow down quite a bit. I've spent a lot (and I mean a lot) time with investigating a good way to allow scriptable effects (since I'm too lazy to implement all of them myself) that can be created easily even by non-developers. I think this is one of the most crucial steps to make this project a success. Everything else (besides rendering itself) is just some easy stuff. Also, there was a major cleanup which allows everyone to customize almost everything they want easily. I've splitted the code base into two seperate projects, which consist of the rendering part (world, gui, ...) and the content creation (networking, data storage, ...). These can be used like frameworks or be completely replaced without breaking the other part. For example, someone could inherit the content creation and add advanced control that allows to interact with a modified rendering part which displays 3D characters that move around like inside a first person shooter. Both parts are combined inside a core library, which represents the controller. So yes, the project now uses the MVC pattern and everyone of you should know yourself what benefits this has. Here are two small screenies. But don't expect too many visual improvements, since I have worked more on the code instead of the rendering. And don't worry, I will still make sure to release the source code as soon as I have either no interest anymore or when the project is in a usable (for others to develop with) state. Thanks for everyone who is supporting this project! PS: I don't have a cool project name, any ideas? I thought of WeeRagnarokClient or WeeClient, but dunno. Or maybe rMinerva Client, because of Athene and Minerva, lol.
  5. Shinryooooooooooooooooo tell us your status :D

  6. I am very happy to see that this project is going to be continued. I will try to create a list of changes that happened after r25.
  7. The screenshot that was posted before showed the part where the function "GrannyVersionsMatch" was called by the client. The conditional check was replaced with NOP instructions in order let the client always accept the version, regardless of the result returned by "GrannyVersionsMatch". I think you might know yourself that this is not a good solution, unless new Granny3D versions really support those files from version (I don't know much about Granny3D). Basically, you have to find out to which virtual address the function "GrannyVersionsMatch" is gonna be relocated upon client startup. E.g. 0084D860 (for RagexeRE 2012-05-08). Somewhere within the client, there must be a call to this address. So you have to search with a hex editor for "FF 15 60 D8 84 00". The first two bytes are the call, the last 4 the address (reversed order). If you have found the correct position, skip 8 bytes and replace the next coming byte with EB. This should be sufficient. You can also replace the whole call (FF 15 60 D8 84 00) with B0 01 90 90 90 90. GrannyVerionsMatch fills the lower part of the AX register with 1, when the version is correct. The previous edit will force it to be always 1. It's pretty hard to get the correct virtual offset of the "GrannyVersionsMatch" function on your own, if you are not experienced with import tables and dll files. Therefore, you should first read some notes on google (import tables rva dll, etc.). E.g. http://www.sunshine2...s/tut_rvait.htm. You could also get your hands on IDA (The Interactibe Disassembler) and let it calculated all needed offsets for you (search for the function afterwards and jump to the position where it is being called). Edit: Here are also some screens that might help you: This is how it looks like in IDA: This is how it looks like if you replace the conditional jump: And this is how it looks like when you replace the call itself:
  8. You want to be able to use custom 3D models. You also showed a video where custom 3D models are used. You even have a screenshot with a hexedit to bypass the version check of the dll. So.. what's exactly the problem now?
  9. Hair sprites don't need a table. Everything else looks like this: PcIdTable = { ... JT_KNIGHT_H = 4008, ... } PcNameTable = { ... [PcIdTable.JT_KNIGHT_H] = "Lord Knight", ... } PcSpriteNameTable = { ... [PcIdTable.JT_KNIGHT_H] = "·Îµå³ªÀÌÆ®_", ... }
  10. It's up to you if you want this behaviour.
  11. I have implemented a lua state class which acts as the interface you have mentioned. The custom client will read all lua related stuff (*.lua > *.lub) from a folder called "scripts" which resides at the root folder of the client. This folder is split into "tables" and "functions" which again contain lua files that are related to either pc, map, accessory, etc. Here's an example of a function I am currently using to get the hair sprite path: GetPcHairSpritePath = function(hair_id, male) local prefix = "" local postfix = "" if hair_id < 1 then hair_id = 1 elseif hair_id > 27 then hair_id = 27 end if male == false then prefix = "Àΰ£Á·/¸Ó¸®Åë/¿©/" postfix = "¿©.spr" else prefix = "Àΰ£Á·/¸Ó¸®Åë/³²/" postfix = "³².spr" end return prefix..hair_id.."_"..postfix end Right now, it is even possible to create custom classes with ease. XML and LUA help a lot in creating customization which is something that I try to achieve. I also plan to export whole classes so that those can be accessed through lua (e.g. network handler, window manager, etc). Therefore an SQL like database would be only good for storing configuration stuff or paths.
  12. @Maki: Yes. The text can also be changed within XML files and thus allows easier translation without the need to modify hundrets of textures, since they are split apart. This means you can have different language files using the same skin. @Rest: Thx! @Project: I'm currently adding LUA support. The idea of using lua files was a great step by Gravity, the only pitfall is that those files are messed up and it's pretty hard to keep compatibility with old and new client versions. For example: Take a look into "lua files/admin" and "lua files/datainfo". I haven't tracked down if the original client dropped "lua files/admin" and uses "lua files/datainfo" instead (especially for the function ReqJobName). Those in the admin folder have wrong display names and have probably been used when the data was placed in msgstringtable, while the jobnames in the datainfo folder are split into man and woman tables, using translations for spain? The probably best solution would be to recreate custom lua files that are clean and structured. This would, indeed, create the need of merging information from official lua files into the custom files. But this doesn't really matter since the official files have to be reversed anyway. Any thoughts?
  13. @KeyWorld: The original client does not seem to support the operations (scaling and rotation) inside the act format when the sprite is being projected onto a window. So if he scales the sprite images up and reduces the size inside the act format, all sprite images in the login interface (which might not be important) and others (equip window, skill window, etc.) will have huge sizes. @curiosity: I had implemented a shader quite some time ago that allowed me to change the colors of sprites based on a 1D texture lookup. This forced me to also implement a bilinear texture filtering shader which worked fine. It had some glitches when moving around, though. I just recently understood the half texel problem which might have been the cause, but it's basically possible to implement such scaling filters without big issues. @Project: I have improved the networking part and added some little features like mouse freedom. The login interface is almost complete. I have created an interface to create cegui windows with animated sprites and investigated the correct usage of actors. The probably most important part: I have cleaned up the project configuration for visual studio. There is now a dependencies folder containing all necessary 3rd party libraries (boost, ogre, cegui, lua, luabind, etc) that you can download seperately (16.6 MB as compressed zip file). As soon as the source gets released, you can just checkout the repository and it will compile just fine without the need for downloading any libraries. However, I provide only precompiled windows libraries for now, since I don't have enough time to focus on creating linux and mac libraries. This will follow when I have more free time. Here's also a screenie showing some progress. I will make a video soon:
  14. It's pretty easy to create custom windows in my current implementation. For example: If you want to send a packet from server to client and the client shall pop up a window (not important what kind of window), you just have to create a static or a member function wherever you like, register the new packet through the network handler and bind the packet to your function. In this function you can load the window either from an xml layout or create the window in code.
  • Create New...

Important Information

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