curiosity

Thanks. I've updated the repository again after doing some major reorganization. From now on I'll stop doing "mega-commits", which I realize are cumbersome. If anyone wants to contribute to this project let me know, and I'll give repository access.

I guess you found out there wasn't very much network functionality implemented, huh? By now I've revamped the whole packet system with support for "any" packet version. I would like to eventually support AEGIS, but it probably requires much extra work depending on the version. I've based my packet builder on Athena's packet_db. Lots of packets are only slightly changed from one packet version to another, so as you may know Athena will just define a length and optionally indices of the fields it cares about. I only have the major packet structures available (not unique structures for every little change in the different packet versions), so I just base the outgoing packet on the most recent structure, then if I detect if the structure is modified in the current packet version I use packet_db's field indices to set only the data Athena cares about. This works great with Athena, but I imagine AEGIS wouldn't like it very much at all. Project status: Lots of work done! Client in screenshot below is connected to rAthena using TCP and packet version 30. You can now walk, talk, see other players, monsters, NPCs and their movement.

File Name: ERODS unfinished web template File Submitter: curiosity File Submitted: 17 Sep 2013 File Category: Web Resources Content Author: curiosity This was supposed to be the new design for my online Ragnarok database, ERODS, but I never finished it. I think it's an okay layout and some parts look OK, so I decided it's better to share than to keep it dusting on my disk. It needs a little work, but maybe someone wants to refit it to their page? Image is of the (unfinished) HTML coded design. Download also contains PSD source files. Click here to download this file

The patch to disable packet encryption didn't work. The client is still encrypting packet identifiers.

At present there isn't really a correct packet version, just a collection of structures with the IDs they were initially assigned when they first appeared. As you can image this doesn't work terribly well, so I'm re-planning and reworking everything related to packets. This will feature the ability to use a packet version of your own choice, but unfortunately Athena's packet_db only gives structural information for client-to-server packets so there are still problems. In reality I'll probably target version 30, or something close to that depending on how many packet structures I'm currently missing. It appears Athena has at best spotty support for older packet versions anyway. From what I can tell it will for instance ignore sending monster/NPC/actor packets if your version is too old.

I've been testing running it as a desktop application. I might just make that my main focus, because then I could use native code to do the most heavy processing. This would also allow for reading GRFs without essentially having to load the entire thing into memory and use TCP without WebSocket which simplifies things. Notable changes since last time include... fixed sprite positioning when walking over uneven terrain improved accuracy of tile picking tile pointer now shapes itself after the underlying tile centralized input events added mini-map window and chat window to the map loader added RSW table for indoor maps and implemented rotation range @Andre How bad is it? I didn't notice, but my computer is only 2-3 years old. Unfortunately the 3D library I use has poor support for sprites. Adding shadows under players/monsters effectively makes drawing them twice as heavy, so that might be one reason your performance has gone down. Also picking sprites is a little CPU intensive (I've adjusted down the frequency by 50% now). I think sprites are culled when out of view, but they will still be updated. When I implement network the server will tell when they out of range of the player. Shift-click teleportation is intended, yeah. @nobigdeal Fixed the mentioned issues. How is graphics hardware support in Linux these days? Last time I checked I got horrible performance with Chromium, even though it was supposedly hardware accelerated.

Yeah, my bad. I must have forgotten to push some of the changes. And standAlone should be false. I've updated GitHub again. Also cleaned things up a bit and fixed various issues.

File Name: HTML Ragnarok Sprite Tag File Submitter: curiosity File Submitted: 03 Sep 2013 File Category: Web Resources Content Author: curiosity About This is a Javascript file which extends your browser so that it can display SPR/ACT files as if they were interactive images. You can use it for anything you'd like - no need to credit me. Requires a fairly recent browser. Confirmed to work in Chrome 29, Firefox 23 and Opera 12.16. Usage Simply add it to the your HTML head like this: <head> ... <script src="HTMLRagnarokSpriteElement.js"></script></head> You can now add Ragnarok SPR/ACT files as if they were regular elements: <ragnarok-sprite src="alice.act"></ragnarok-sprite> Note that for the above example to work, both alice.spr and alice.act needs to be hosted. The ragnarok-sprite tag supports the following attributes: (URI string) src - URI to the SPR/ACT files. You don't need the .act extension. (number) speed - animation speed (boolean) animated - whether to display animation (number) width - absolute width of the element (number) height - absolute height of the element The src attribute is the only one which is required. Note that if width AND height are not specified, the element will automatically be as large as it needs to display every action in the ACT file. If your browser has support for custom elements (see below) you can also create new instances of the element from JavaScript. var alice = new HTMLRagnarokSpriteElement();alice.src = "alice.act";document.body.appendChild(alice); Should I use this? Go ahead if you find some purpose for it - but not if you need it to work smooth for everyone. Many people are still on old browsers. It's also relatively resource heavy, and SPR/ACT files are not suitable as web formats. While it will run in most recent browsers it's bad practice to use non-standard features such as adding a new pseudo-tag. However, in the near future adding tags will be a feature, as defined by W3. This script already uses these features where available, which at present seems to be in Chrome 31 and Firefox 23 with experimental web platform support turned on. Click here to download this file

Hi curiosity, Why not host a demo so that we can all test? If you need a VPS, feel free to let us know; we'd be more than happy to sponsor another cool project. Thanks for your kind offer. Maki has also offered access to a VPS, so it looks like I'm good for now. I'll make sure to upload something everyone can try out soon. GitHub is also updated, for those who are interested.

Some more updates. Mainly: Fixed a problem which made camera movement appear a bit jagged. Adapted projection & look-and-feel from Gravity's client. From what I found the correct field of view is 15 degrees, resulting in a flatter view which fits the 2.5D style much better than what I had before. Fixed the file loading routine to better accommodate sharing of processed resources. Notably sprite textures are now shared between actor instances, which gives various performance benefits. Added support for all top and mid headgear as well as the shadow sprite. Next up are weapons and shields for when I start doing interactions between actors, though I'll likely want to rework my sprite attachment system a bit. Implemented mouse picking for actors (the game knows which player you are clicking on). First attempt on in-game text. Name and chat labels for now. Added fog to the map. Will update GitHub soon!

Thanks for the report. Connecting to a server doesn't really work yet. That is, the packets aren't implemented, so NPCs will not appear at this time. Glad to hear you're getting a good frame rate. I hope other people will also try the map loader so I can get a clue on what their performance is like at this point. I think most computers should run pretty smooth, even with lots of monsters on the screen. Though at the moment it doesn't share the processed data between actors with identical sprites, so memory consumption and loading speed can still be reduced by far. This is especially important for bigger monsters which take a relatively long time to ready for drawing.

Oh, it shouldn't be needed. I've removed the dependency from the repository now. You can use WebSockify on Windows. Binary download here: https://github.com/downloads/kanaka/websockify/websockify.zip

Okay, here's a repo with the current code base along with a some words on how to run it continued development. I'm kept busy with real work, and it can go months between updates on my part. As such I've decided to release what I have so far in hopes that someone will find it useful. As with my other work you can regard my code as public domain, though I encourage sharing if you decide to improve it. https://github.com/curio-r/rangarok-js Hopefully I managed to get all the necessary files up. If not, let me know. As I stated from the beginning, this is a personal project I've worked on a little now and then, so it's not up to any standard. This goes for coding style, application architecture, error handling etc. I haven't run it in more than a couple environments, so it's not unlikely you will need to fix something to get it running. Please understand that game play is not ready yet. Most notably I haven't implemented an entity system, and due to various circumstances I haven't really begun working on the zone server packets. How to set it up: Open settings.js and change the data folder path. This is the path exposing the data folder on your WEB SERVER. Setting a local URI (e.g. "C:\Ragnarok\data\") will NOT work because of security policies in your web browser. This is all you should need to do in order to use the map loader. (Optional) Put the Ragnarok BGM folder into the ragnarok-js folder for music. If you want to connect to an Athena server you will also need to setup a WebSocket-TCP bridge. I use a program called WebSockify and by default the web client will try to connect to [$real_port - 1]. So you need to e. g. set up WebSockify on port 6899 to connect to the login server at port 6900. Same goes for char and map. Because this approach effectively hides the client IP from the server there are certain issues with connecting to remote servers which I haven't bothered dealing with yet. I recommend you use Chrome or an equivalent. I've tested on Firefox as well, but it's slow, though this might be due to my setup. It should be able to run on fairly weak computers, but your graphics card needs to have support for WebGL (i. e. not too old OpenGL version). If things don't work out for you remember that you can open the web inspector to see error messages (ctrl-shift-i in Chrome). Running: http://path-to-ragnarok/MapLoader.html will open the map loader. It should load gl_knt02 by default (change in MapLoader.html) and allow you to walk around. From the web inspector's JavaScript console you can spawn monsters (ex. "spawn('raydric')"), change class (ex. "setclass(7)" to change into knight) or head gear (ex. "settop(AccessoryIdTable.ACCESSORY_BUNNYBAND)"). Example: http://i.imgur.com/bDXe84D.jpg http://path-to-ragnarok/Ragnarok.html will open the client. If everything goes well you should be able to get into the game. After that it's not much more you can do.

I've investigated networking a bit, but honestly I haven't really done that much more. It's going a bit slow again since I'm away from home this summer and don't have my development computer. Well, I'll see if I can't get something done in the next couple of weeks anyway. Also if people are interested I might put the code up on GitHub or something, though I'm a little hesitant because it's in a pretty bad shape.

Oh, no network code there I can assure you! The messages are from an mouse event handler which passes the move request on to the game instance, which in turn calls the network manager. I haven't gotten around to implementing a central input handler yet, so currently the mouse events are handled in the same class which holds the 3D scene because mouse picking is done there at the moment. MapLoader is growing into a beast though (over 1600 LOC now ), and it needs to be split into an actual loader and a class for the 3D world. @project: In addition to a lot of changes to the core, the main things I've done since last time are: Added RSM atlas texture caching using the FileSystem API (available in Chrome only for now), which reduces the loading time to about 5-7 seconds for all maps, given that other map resources are loaded from a local web server. Fixed (hopefully) the last bugs in the RSM matrix calculation. Fixed some errors with drawing order of sprites. Added shadow on sprites based on the GND file's shadow map, which comes with a funny bug which is also present in Gravity's client: When you walk to the beginning of e.g. bridges you character goes dark because of shadow mapping on the cliffs, but you can't see the shadow on the ground because the bridges are RSM models which don't use the ground shadow map. Started working on the basic in-game interface.

Development have been at a standstill for a while for various reasons, but for the last few days I've worked hard to put all the pieces together. I ended up (re)writing a couple of thousand lines of code, so I'm happy to finally have map rendering, sprite rendering and networking working together. If everything goes according to plan I'll implement some network packets in the following days, and hopefully some very basic game-play isn't too far off!

Does the client even support IPv6? Even if it's network stack does, in the packets the server addresses are sent as unsigned 32bit integers, which aren't big enough to hold an IPv6 address (which is 128 bit).

Maybe your rAthena setup is compiled with a different packet version than what your client is using? If this is the case the client may not understand the information the server is sending, which can lead to crashes. Different packet versions overlap a lot, so many times only a few select features are affected. Of course, it may be that it's some error on the client side, for instance bad client modifications.

Ah, not so good. I hope you will finish your project soon so I don't have to have to finish mine. I have too much work at university these days to do spend any time on private projects. Also I get easily distracted. The last thing I've done was to create a command-line based GRF reader for the purpose of hashing and categorizing all the files from all the patches into a database. Yes, I'm aware of how insane that sounds. I'm hoping to use it to easily generate small GRFs with just the files I want. At the very least it'll make a cool version history of all of Gravity's files. Working out the old Westpak/GRF 0x12 format from the alpha days was interesting Although I spent a few hours and managed to submit a JS1K entry myself. It's called "Tree Ninja" and is one of the latest entries. Check it out if you have time!

He he, I found that packet list handy for generating definitions too. Only difference from your approach is that I just pass objects and later fetch a builder based on packet ID. The idea was doing something like this: send({ PacketType: version > xxx ? 0x1dd : 0x64, /* CA_LOGIN2/CA_LOGIN */ Version: version, ID: user, Passwd: passwd, PasswdMD5: md5(passwd) clienttype: clienttype }) But I guess the lack of proper grouping and having to switch values based on packet version kinda defeats the purpose. I though you were done with the network though. Reimplementing everything? Also stumbled upon your js1k submission while checking the latest entries. Pretty cool!

I have something called Aegis2AthenaConverter made by Tsuyuki. (I think he was head developer of the Freya and Aurora projects?) It's a script file for a program called UltraEdit. Never used it, and I'm not really sure what it's supposed to convert either. Also it's about 5 years old. Let me know if you want it.

Sorry, I don't know anything about those patch generator plugins, so I'll leave that to someone else. Though I did find the byte sequences I posted in other clients. I haven't actually tested, but I think it should go like this: 2011-03-10a patch can also be used for 2010-11-24aRagexeRE (and probably earlier) to 2011-12-14cRagexeRE. 2012-04-10a patch can also be used for 2011-12-20bRagexeRE to 2012-07-16aRagexeRE. 2012-08-08dRagexeRE and later clients are obfuscated...

The one I already posted goes for both the 2011 and 2012 client. It's just a simple check I found in the Granny model loader, so I don't know if that's all it takes. Find: 3D 10 27 00 00 Replace: 3D 20 4E 00 00 Here the 0x2710 (10,000) limit is just replaced with a higher number. In this case 0x4E20 (20,000). If that works I think we're all done here.