curiosity

Hi Pascal. If number that have "0x" in front means they are in hexadecimal format. Look it up if you haven't heard of it before. The implication is that 0x1 + 0x2 + 0x4 + 0x8 = 0xF, not 0x15 as you've calculated. You can set the Windows calculator to use hexadecimal number if you select View -> Programmer from the top menu, then select "Hex". As for your problem: instead of summing everything up you can just use 0xFFFFFFFF (all enabled) - 0x01000000 (gunslinger enabled) = 0xFEFFFFFF (all classes except gunslinger enabled).

Well, perfectly fine might be an overstatement, but I see that it returns Z_OK in spite of the 7 last bytes becoming corrupted. Just to make sure I actually extracted worm_tail_damage.wav from the alpha client data (old GRF/PAK format with LZSS) since I figured it would not be the same damaged compression that's been in the kRO GRF forever. Indeed, the last seven bytes should be "ge 4.5 " + 0x00. Don't use this knowledge for evil

@Ai4Rei My version of cps.dll is already able to handle both ZLIB and LZMA because I use a simple mechanism to detect the format when uncompressing. So it's no problem to mix LZMA and ZLIB encoded entries in the same GRF. What I was talking about in my previous post was cps.dll's compress function. It will only encode to ZLIB because there's no obtrusive way to know if the caller is repacking the GRF or encoding a guild emblem to be sent to the server. However by now I've added a second compression function which GRF editors can use to encode LZMA. Or maybe I misunderstood what you meant?

Sorry, not going to happen on my part. I took a look at the 2014-02-05b exe and see that things are switched around a bit again and it's become an even bigger mess. I don't even have an updated server/client, so I can't test anyway. If anyone else wants to try here's a start on the virtual addresses: g_Weather = 0x00C949F0, g_UseEffect = 0x00CCDF64, g_Renderer = 0x00A63918, CWeather::LaunchSnow = 0x00771AE0, CWeather::LaunchCloud = 0x00771CD0 and entry point in CGameMode::Initialize should be at around 0x007EECFD.

@Tokei Hey, that's great! I hadn't seen your GRF tool before, but it looks really good. Unfortunately the compressor function must encode ZLIB to stay compatible with the server. The client will use the compress function to encode guild emblems before they're sent to the server, and naturally Athena isn't able to decode LZMA. However I compiled a new DLL which also exports a function called compress2 that encodes LZMA (untested, but hopefully it works). @NeoMind Cheerful as always, eh? I uploaded the code for the DLL at github. To compile you'll need to download the ZLIB SDK and fix the include/lib directories in the solution properties. I didn't upload the compressor tool code since it isn't really needed anymore if Tokei's editor can do it. It wasn't very good anyway, so not a big loss there to be honest... @Aeomin Yes, I think that's an idea worth exploring as well. Though there would be some manual effort required, which is a little boring. What really takes up space (while compressed) are textures and map files (particularly GNDs). I think most map files are in use, but selecting based on a map config would be simple. However I think a lot of textures aren't referenced by GNDs or RSMs, but hardcoded into the client, so these would have to be manually included.

You probably just don't have the newest version of the Microsoft Visual C++ runtime distributable. However it's not really necessary, so I made a version which will hopefully work without you having to install anything.

Thanks for all the kind words. I didn't really expect it to get much attention. No options so far. I considered adding an option for compression level, but decided to go for always max. It can not revert an archive at the moment, but I that could be implemented with ease if there's demand for it. Welcome to rAthena Yeah, I got those too. Actually I was certain that both are junk entries, but taking a second glance I see that worm_tail_damage.wav is not. Looks like the compressed data is malformed at the very end, which makes the decoder complain even though it manages to decompress the whole thing. I don't know if this is due to my DES decryption or not, but I've noticed in the client that they don't bother to check if decompression fails, so it wouldn't really care either way. You hit the nail on the head in regards to memory allocations and threads. The converter is very quick and dirty, so it's not been optimized in any way and there are plenty of wasteful allocation and memory copying going on. Current it will actually use two threads while encoding, but since the files are so small this likely introduces a large overhead. It could definitely be improved. Tell me if you're interesting in the source code. That's understandable. However to be clear, let me reinstate that very likely the only thing that won't work with current tools is extraction. Adding new files, merging archives, rebuilding etc. should all work with current tools.

LessGRF What? LessGRF (LGRF) is an extension to the GRF format which adds a new algorithm for file compression. Normally the GRF will compress files using the DEFLATE algorithm which is the compression method typically used in ZIP files, but LessGRF adds the LZMA algorithm as an option. Why? Ragnarok's GRF files can get quite big. Back in the days the game data used to take up a few hundred megabytes, but today the GRF archives are about 2GB and contain tens of thousands of files. Since the data is starting to get pretty big it's possible to save quite a bit of space simply by re-compressing the game files with a more efficient algorithm. In my test on a full data.grf the file was reduced to about 60% of its former size. Maybe someone will find it useful if they want to make a mini client or something? Honestly, this was just a little experiment I did out of curiosity. How? Two simple steps are all that's necessary to use the LGRF format. First, download this file. 1. Installation To upgrade your client, replace the cps.dll in your Ragnarok folder with the one from the download. (Make a backup of the old DLL file first.) 2. Recompression Extract GRFCrush.exe somewhere. Run it from command line or just drag and drop your GRF file onto it. It will generate a new GRF file which you can use instead of the old one. The recompression process will likely take about 20 minutes on a moderately powerful computer. Q&A Q: Since the compression rate is better, will files load slower? A: I've not notice any different in map load times. LZMA is more expensive to decompress, but modern processors are so fast the load time might just as well be reduced since less data has to be read from the hard disk. Q: Can I use both GRF files and LGRF files at the same time? A: Yes. The new cps.dll supports the old GRF compression as well. You can mix LGRF and GRF Q: Can patchers or GRF tools update LGRF archives? A: Very likely, but only if they don't attempt to decode the data in the process. Q: Can current GRF tools extract files from LGRF archives? A: No. Q: ...Does that mean it can also be used for GRF protection? A: I wouldn't recommend it. (That being said I guess this is no less "secure" than GRF protectors like SecureGRF.) Q: Are there any penalties involved with using this format? A: Incompatibility with GRF extractors is currently the only thing I've been able to think of. Let me know if you notice something else.

I played with the demo and I have to say I'm very impressed with your progress, KeyWorld. It's very fast and smooth. I guess the development gets a little more tedious at this point when you have got most of the basics done? For the sake of your sanity I hope you're not planning to implement all the 3D effects... One thing I noticed is that the perspective seems a little off. From the source code it looks like you use a field of view of 20 degrees. The official client actually uses 15 degrees. (I looked into the client executable.)

http://pastebin.com/Ftq9tpN9 Just for you! Take this script and save it as mapcache.html Open it in Chrome or Firefox and drag-and-drop map_cache.dat into the browser window. It will list all the map entries with their size.

I don't know about "to many vertical lines"... Do you mean the error message "too many vertex granny model!"? If so this happens if your model has more than 10,000 vertices. And yeah it's just a warning and can easily be disabled.

Got the code up for you. https://github.com/curio-r/rag-dll Not very pretty though! Yeah, I was a bit surprised at this discovery myself. However I wonder if it would be possible to add the cloud effect (or other CWeather based effects) by including an effect object in the RSW. Though if it is possible Gravity should have have that in the first place instead of hard coding it in the map initialization routine.

Oh, forgot that it was debug. Download release mode here. Changes since last time: The rest of the weather effects (maple leaves, sakura, fireworks, night) are now available Should no longer attempt to load with incompatible clients Now listens to /effect option Added some info on the different cloud modes in the config It's about the same issue as with client patching. Making it work with one other client is easy, but to work with all clients it'll require a little framework to detect code/offsets automatically. If you are interested in looking into it I can upload the code for you.

I've not investigated how cloud altitude is affected by map height (KeyWorld could probably tell you), but I know there is no option in the RSW format to set cloud height. However there are actually many cloud effects, and I suspect this has something to do with your problem. If you use @clouds it will spawn the effect with ID 233, and @clouds2 spawns the effect with ID 516. These effects are only 2 of the 9 different cloud effects present in the 2012-04-10 client. If you look in mapeffecttable.txt in my release you can see a field I call PARAM. This switches which cloud effect the map will use. For instance if this value is set to 3 it will display "misty" clouds at ground level, while PARAM=0 is used for mjolnir_01.rsw where the clouds appear only on the highest point of the map. Parameter reference: [table] ParameterEffect IDExample map 0229mjolnir_01.rsw 1230gon_dun02.rsw 2233valkyrie.rsw 3515einbroch.rsw 4516airplane.rsw 5592moc_fild22.rsw 6N/AN/A [email protected] [email protected] 9945bif_fild01.rsw[/table] So I think the cloud altitude is affected by which cloud effect you use. With this plugin you can use all of them, so hopefully that solves your problem.

Hi all. After reading about Ai4rei's little discovery I decided to try and make a client plugin. This plugin gives you a new config file, mapeffecttable.txt, which allows you to set weather effects and modify 3D renderer clear color ("sky color") for maps. Now you can add clouds and blue sky (like in Juno and Kunlun) to any map without modifying the client or having to replace the effect from an old map. I just made this today and haven't tested very much, so there will likely be bugs. Also I've only tested on Windows XP running as administrator user, so YMMV. This release only works for 2012-04-10 client, it will crash all other clients!! Update: Now available for 2013-08-07 in addition to 2012-04-10 Weather effect overview: [table] EffectDescription mapleFalling maple leaves nightNight mode pokjukFireworks sakuraFalling cherry tree petals skyCloud effects (many different) snowFalling snowflakes[/table] Example: to add snow weather to Prontera you simply add an entry in the config like this: prontera.rsw 0x00000000 snow 0 More interesting Yuno: To install, put rdll2.asi in your client folder and put mapeffecttable.txt in your data folder. Also note it will not work if you have sound disabled. Download

OK, worth a check I guess. Comment out includes in npc/*.conf to disable NPCs.

I'm not really intimate with this, but maybe it runs out of memory during the loading progress? I see the original RP model has 256 megabytes of RAM, which is pretty abysmal even for an ARM device. Either way you could disable all NPC entries and see if it will finish.

Najara's reply is a bit off the mark. The alpha and beta clients didn't use the format known as GRF today. Instead they used a modified version of an archive format from one of Gravity's older games. This format has a different structure and also uses a different compression algorithm, so it can't be extracted by tools aimed at the current format. GrfExtractor by Wdb is one of the few public tools which can handle the old format. If you were hoping to just extract and use the old files without any hassle you'll be disappointed for too many reasons to list in this post. On the flip side you won't be able to actually use the alpha/beta clients either, because their packet versions are too old and the alpha/beta based Athena versions never got into a playable state. Bottom line is that unless you know what you're doing you won't be able to do much with the old clients. However some people have already put work into converting the maps. iRO alpha client can still be found here, or just the maps here. I still have the (open) beta iRO. If you really want it I suppose I can share with it you, but if you just want the maps Kiar over at eAthena already took the beta maps and updated the file formats to more recent versions. You can find this map pack here.

There isn't an definitive one. First of all it will vary from server to server. Secondly not all servers have implemented the updates in the same order as kRO. Also remember kRO isn't always the first server to get updates. In the beginning the updates weren't called episodes either. The episode concept didn't appear before a few years down the road, and not definitively before episode 10. For instance, on iRO the updates were just titled "Juno update", "Turtle Island update" etc. Amatsu was called "Global Project 1". For episode 10 and after it's pretty easy to find the kRO episode numbers. Here's an attempt at dividing the most important early content updates into episode numbers: Alpha: Prontera village, Morocc village, alpha culvert and some other dungeons. Novice + basic classes, except magician which was never implemented. All maps from alpha were scrapped. Beta 1: Prontera, Alberta, old Payon + Archer's village, Izlude + Byalan dungeon, Geffen + Geffen dungeon, Prontera Maze/Hidden temple, Mt. Mjolnir and Coal Mine dungeon, Orc Dungeon, Morocc + Pyramid and Sphinx dungeons. Magician class added. Beta 2: Aldebaran and Clock Tower, Glast Heim, Ant Hell, Novice Grounds. Lutie was added for the Christmas event at the end of the beta. Obviously also a lot of game play changes, for instance cards were implemented in this version as well as 2-1 classes and PvP rooms. Episode 3: Comodo update. This was a large game play update with new stuff like first class quest skills and cute pet system added. Episode 4: Turtle Island; guild update with WoE and guild dungeons. I think monster skills were first added here. Episode 5: Juno update with 2-2 classes and Magma dungeon. Episode 6: Amatsu (global project 1), Kunlun/Gonryun (global project 2), marriage system, Super Novice class. Episode 7: Umbala, Niflheim, Jawaii update, Louyang (global project 3); Geffenia. Episode 8: Ayothaya (global project 4). Adoption system. God seal quests. Payon remodeled. Episode 9: Transcendence update and Izlude Battle Arena. Episode 10: Schwarzwald update and LOTS of changes. I'll stop here... Episode 6 to 9 are kinda vague here.

Turns out I was a little too hasty when I typed the repository name. I guess it's as good as any temporary name. I wonder if Mozilla is ignoring MP3 support in the name of open standards, or if they just don't want to open their wallet to MPEG. Anyhow, file extension for music should rather be a setting, I think. I'll merge in your pull request once I have time. (And figure out how GIT works, he he.) As for that particular transparency issue I though I'd already addressed it, but as it happens clearing background colour is presently done in two different places. Some refactoring is apparently in order. It's safe to clear anything with red and blue > 0xf0 and green < 0x10. This issue is a minor display of the fine competence of Gravity's development team. Though you can't really blame them considering the history of the company. They aren't exactly an AAA studio, much less in 2001 when this all started. On an unrelated note, some time ago I got maps from Arcturus (the game which Ragnarok was originally based on) loaded into this project and started to understand where a lot of the weird design decisions came from. From what I've heard the decision to re-use the engine from Arcturus was one of the factors which led Gravity's first CEO to resign and subsequently quit, citing amongst other things dislike for the technical limitations of the game. He quit right after they tried to push 3D actors in Ragnarok. The GR2 model system apparently never satisfied them very much, and the later CEO went on to form a new company and develop another MMORPG called Granado Espada. In my opinion Arcturus seems to be a pretty solid game. It's a shame it never got a western release, though there is an English demo they showed off at E3 2001 still up for download with hilarious translations. There are about 300 Arcturus maps, ranging in style from medieval to modern and even futuristic. It's a pretty solid number considering there are about 700 maps in Ragnarok after a decade of development. The sound track has it's moments as well. I think some of the guys who went on to form SoundTeMP were involved. </gravity-history>

Yeah, that looks pretty bad. Unless the converter botched them my bet is that there are some underlying problems with WebGL support. Char creation is not implemented yet because the interface is not done yet, and I've stopped working on the GUI because GodLesZ has said himself willing to do so. Also changing maps has some problems. By some problems I mean it's a miracle it doesn't crash, so until do some more work on it you will to look like missingno.

I can login just fine now using the client you uploaded. Loading textures for the map take some time, but BMP aren't exactly the ideal format for web. (I think converting all images to transparent PNG would be better) The relevant errors you get are these: Unable to get image data from canvas because the canvas has been tainted by cross-origin data. MapLoader.js:184 Uncaught SecurityError: An attempt was made to break through the security policy of the user agent. MapLoader.js:184 This is caused by conflicting content origins. By default JavaScript isn't allowed to get content from other origins than the one hosting the web page. (More info here.) By looking at the network activity I see that some requests are still redirected. This seems to be the case for some textures that have upper case names in the RSM files, but lowercase names in the GRF. I think that must be what violates your browser's content policy. The version of Chrome (29) on my PC doesn't have a problem with it. Maybe you can configure your web server to ignore spelling case so it doesn't redirect? Otherwise it's also possible to relax the same-origin policy, but I haven't looked into how this is done. Bottom-line is that this is an unfortunate side effect of security feature of modern browsers and requires server configuration to resolve.

Asura, there's a problem with your data folder. Some of the file requests are redirected to another web server at port 8080, but this server does not appear to be online. It doesn't start because it's waiting for all the textures to download. (I haven't added graceful error handling yet.)

If you've set socketType to 1 then you won't be able to connect to a server from Chrome, because TCP sockets are not a feature available in web browsers. For playing in web browsers you must use the WebSocket protocol, which is enabled by setting socketType to 0. Please note that this requires connecting through a WebSocket to TCP proxy such as websockify. As for the error message, it is generally a sign that your computer doesn't support WebGL, but there can be a number of different reasons. Try visiting http://get.webgl.org/, or run any other WebGL app, from Chrome. If WebGL is supported in Chrome then one thing you can try is copying libegl.dll and libglesv2.dll from Chrome's application data folder into your node-webkit folder (replacing the ones bundled with node-webkit).

Desktop version is the same code as the web version. To run as desktop application you must download node-webkit and run nw.exe using the client's root directory as the argument. Make sure to enable the desktop option in settings.js to enable reading files locally. Also remember to configure TCP in the settings if that's what you want to use.