curiosity

I'd love to port it to iOS as well, but I don't have a recent device. I think iPhone 5 and anything later would run it pretty well. Maybe I can pick one up for cheap sometime in the future.

Improvements continue. Most notably I finally added NPC shops. I had completely forgotten there was a little window above the purchase window. Has that actually ever worked on any client? It's supposed to show how much your stats will be raised by buying a piece of equipment (by pulling attack and defense from itemparamtable.txt), but it seems completely broken.

Resolution is no problem with OpenGL rendering. Haven't decided yet. It's still not finished.

Not sure if it's the most recent version. ROMAPCONV.part1.rar ROMAPCONV.part2.rar

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.

The actual limit is 3000 vertices per RSM node. You can go past it, but memory will start to get corrupted. Can you try using BMP instead of TGA? Just transparent parts with magenta (#FF00FF).

No problem here with Windows 8 and Visual Studio 2013 Professional. Have you tried doing this? http://stackoverflow.com/a/28902854/1421750

Can't test at the moment, but you can try this patch: Find: 66 66 C2 41 66 66 C2 C1 Replace: 66 66 C2 C1 66 66 C2 41

Okay. GND rendering looking good so far, but you should tell him that he doesn't need to start from scratch. Just getting map rendering right will take some time, and there are already lots of projects that are already more or less able to render complete maps. In multiple programming languages even. The most recent that comes to mind are: FimbulwinterClient in C# - Pretty complete map rendering if I recall correctly FimbulClient in C++ - Basic rendering I think OpenRagnarok in C++ - Working map rendering, also able to connect to a server and walk around roBrowser in JavaScript - Working client with lots of features (can also be ran as a desktop application) There's also source code available for a handful of other (older) client projects and map viewers in C and C++. Just a suggestion

GRF doesn't really have any encoding, it just checks strings byte by byte (with case insensitivity for alphabetic characters). Gravity uses strings encoded with EUC-KR. The garbled strings you see in data folders are the direct representation of these EUC-KR encoded strings in ASCII or similar. Repacking with the garbled names works because it's binary equivalent. If you convert the Korean names to unicode when extracting you must convert back to get the expected file names in the GRF. For names limited to latin characters it doesn't actually matter since that's the same in literally every character encoding.

There has never been a source leak. However PDB files have been released on at least two occasions for older clients.

roBrowser is your best bet.

Each version is specific to one client build only.

There isn't really a packet description in the client, just machine code compiled to fit a certain data structure. To achieve what you request you would need to figure out multiple issues. The easiest part is making the client accept a packet with an extended structure. The second challenge would be parsing and storing the extended data for later use. The hardest part is making the client actually use the new data by modifying the procedure that initializes the name balloon text. It's a relatively big modification anyway. Maybe you can pay someone to do it for you, but it's probably not worth it. I know I wouldn't do a job like this for less than a few hundred $$$s. A better solution for you is probably to replace the guild rank text with the other stuff you want to include.

This happens because of the limited precision of the graphics card. All 3D applications will have similar issues, though it's not always so apparent and depends on how attentive the programmer has been to the issue. If you have a 3D graphics control panel you can try to set the profile to quality mode, this might make some difference.

I added a binary release to the GitHub repo. https://github.com/curio-r/rag-cps-dll/releases/tag/1.0 Use the Tokei's GRF editor to recompress your GRF with the DLL.

Wow, I just realized it's been six years or so since I first heard about roBrowser. It's been a while, but by now the project has matured so much. I'm not so active around here anymore, but I stop by every once in a while to catch up with the progress. I think the earliest attempt at Ragnarok clone was with RO Linux Client in 2003. After that it's been at least two OpenRO projects, JAROC, Pantheon Online, RagnaXNA, Fimbulwinter, Shinryo's client and many more. Congratulations on being the only one persistent (or insane??) enough to actually recreate a game that's been in development for almost 15 years.

I could upload the source if you really want it, but it's better to just use Tokei's GRF editor with the custom DLL. https://github.com/curio-r/rag-cps-dll/

https://github.com/curio-r/rag-dll/releases

No, only it only works with the 2012 client.

Try to check which character encoding the text files are using. Your text editor displays it in the lower right corner, in the part you cropped away from the pictures.

I think you're reading too much into it. Isn't it simply the case that no one cares? Some work is interesting, other is not. And to look at it a little cynically -- there's hardly anything to gain from having an administration that actively promotes spoon-feeding the lowest denominator. So instead we get these basic plug-and-play guides that, while possibly inadvertently promoting lax security to the uninformed, keeps everyone content.

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?