Tokei

Hmm, well this looks like a mapcache issue. Use WeeMapCache and overwrite prontera's data.

SecureGRF doesn't allow you to decrypt your files in any way. That being said, even if the GRF has been encrypted with SecureGRF, you should still be able to see the content. The fact that it crashes in an editor means the GRF header is damaged and it can be repaired if it's nothing too serious. Either way, it's also possible to recover the files by guessing their location to some extent; you'd lose their names but it's not a big deal anyway.

Hmm, well I do not know what you mean by that...! Have you done something specific to the GRF?

He means you can easily extract any encrypted file, no matter what protection was used. Then again, these things shouldn't be mentionned too much because it's 'cheating' (and no, nobody will use this method for you...!). You can assume your GRF is lost and forget about it.

Well, it's damaged then. Like I said, you'll have to upload your GRF if you really want to recover the content (which may fail if it's too badly damaged).

You can try opening it up with GRF Editor instead, but the GRF looks broken anyway. Upload it somewhere if you really want to recover it.

I'm... confused with your script to be fair. You get the warning because 91260000 * 35 = 3194100000, which is greater than 2147483648. If you want to give 0.35% exp, you could use the following instead : BaseExp += NextBaseExp / 10000 * 35;

Either one of those is correct. The item 25022 doesn't have its closing tag. Right above [25023], you're missing "},".

To add new items in your client version, you have to update the following files : data\carditemnametable.txt data\cardpostfixnametable.txt data\cardprefixnametable.txt data\num2cardillustnametable.txt data\idnum2itemdesctable.txt data\idnum2itemdisplaynametable.txt data\idnum2itemresnametable.txt data\num2itemdesctable.txt data\num2itemdisplaynametable.txt data\num2itemresnametable.txt data\itemslotcounttable.txt data\lua files\datainfo\jobname.lub or lua data\lua files\datainfo\accessoryid.lub or lua data\lua files\datainfo\accname.lub or lua data\lua files\datainfo\npcidentity.lub or lua -your other sprites and textures

You seem a bit confused about patches here. A Thor patch is simply a bunch of files, there's no distinction between an item description patch or a sprite update patch. If you modified your item description files, then yes, you need to update your item description files. Any modified or added files needs to be patched. You can make your patches with GRF Editor (it's easier) : File > New > New Thor > Set your Thor settings in the "Container options" tab : Drag and drop your new files and save.

Check if the files have all been merged properly in the player's folder first. Check the file priorities (data folder versus GRFs), maybe you didn't patch at the proper location or maybe your changes are being ignored.

Thor's maximum patch size is 2 GB, so you don't have to worry about that. Some hosts will only allow you to download files up to 10 MB though, so that might be your issue. If you modified your lua files (inside datainfo), then yes, you have to add those as well while you're making your patch. About 3rd question, even though you said you've found the answer, you should always be using the 'weird' language instead of Korean. The client can only read ANSI strings, it will ignore Korean file names. As for GRF Editor, it detects and fixes encoding issues automatically, so you'll never run into trouble while editing a GRF.

I made a tool for myself at some point which does just what you're looking for (requires .net 3.5). It's rather basic, but it does the job. Put the executable where you want your local server to start. For example, if your RootURL in Thor Patcher is "http://127.0.0.1:56561/patch/",then you will want the following : Start the executable, set your port (can be anything), press Start and you're good to go. I have to admit, I haven't tested it so much. I just needed something simple to test my patcher xD. LocalServer.rar

Hmm... well I'm not sure what to tell you now really! It's working fine over here : It loads fine ingame too.

A screenshot is more helpful then copy pasting text, as it doesn't say what encoding your text is in. That being said, at first glance, the file looks fine to me. On the windows Notepad++, it appears as if it's reading the file as "ANSI" (which is fine). Just change the encoding with Encoding > Character sets > Korean > Windows 949 and it will look the same as what you see below. Edit : maybe I misread your first post actually. Are you using Notepad++ on Windows or not? If you're not, then... you should use it! The default Notepad of Windows only handles ASCII characters as far as I know and... it's pretty bad to edit anything really. Edit2 : yep, your file isn't corrupted (that was my initial guess) and there are no issues at all with it. You just need to open it up with Notepad++ on Windows and change the encoding to your needs.

Hm, well it's somewhat troublesome to tell you what to do without the actual file (could you upload it?). Otherwise, please take a screenshot of your file, opened with Notepad++ and make sure to grab the bottom right part as well, to show your current encoding.

The 'codification', you mean the file encoding I presume? Before I go on, I'd like to mention that files do not belong to any particular encoding, that part is entirely up to the text editor you're using. In the case of Notepad++, the encoding is guessed once you open the file, and it defaults to UTF-8 if it can't identify it. The issue is most likely on your end though; you must select a compatible encoding when editing the file otherwise you'll break the character associations. Any 8-bit encodings will work without issues (such as windows-1252, "ANSI", etc). You should use the "original" encoding of the file if possible, which is 949 (windows-949). As long as you don't use UTF-8, you'll be fine.

Alright, well the aeva.dll issue is something specific to your server; you'd have to ask the person who created your server what this is. This DLL is not normally present. Do you have access to the server files? You need edit the following server-side to add new maps : conf/maps_athena.conf (not necessary since you are overwriting an existing map) db/map_index.txt (not necessary since you are overwriting an existing map) db/(pre-)re/map_cache.dat (<- most important one really, you have to restart the server afterwards too I believe)

For more info on the gat part : https://rathena.org/wiki/Custom_Maps#Db_Folder And you'll want to use WeeMapCache to edit the mapcache : https://subversion.assembla.com/svn/weetools/trunk/WeeMapCache/ , that part should help with the gat issues ingame. I can think of a few possible errors that would crash you : invalid map size in the mapcache, bad models, missing textures, corrupted map, ...! Check the console in BrowEdit for possible errors, it might be helpful! If you really can't fix it, you could always upload your map so that we can locate the issue ourselves. Edit : about the servername.dll error, can you take a screenshot of this? I've never seen that error before. You can Ctrl-C to copy the content of the error as well.

Well... that's one way of seeing it, I guess. You can't get rid of zlib (and that's a good thing!), you can't ignore it while understanding the GRF format either. Let me put that differently, maybe it'll be clearer. GRF = {grf header} {grf content} {grf table} {grf content} = {compressed_file1} {compressed_file2} {compressed_file3} ... {grf table} = {compressed table size} {uncompressed table size} {compressed table} {compressed table} = zlib_uncompress(compressed table, uncompressed table size) = filenames, no need to read the zlib header, skip or ignore bytes, or anything else like that. The 4 bytes at the end are indeed from zlib, but... you should simply uncompress the data, and read that instead. What you're doing right now is reading from the zlib stream, which happens to be already uncompressed. It's, hmm... 'dangerous'; the number of bytes at the beginning or the end can vary. But otherwise, the rest of the information is correct.

The GRF format, for version 0x200, goes pretty much as you mentionned above. Something to always keep in mind is that the byte 0x78 is generally the zlib compression header (and the byte 0x00 is the unofficial lzma compression header). If you see some bytes starting with that value, it most likely means it needs to be uncompressed (which is always the case for the GRF's content). Just as an example, if you take the entry "data\test1.txt" and read the offset, you'll get 16. The entries' offsets are relative to the data offset, so you have to add 46 (GRF header size). You'll get 62 which is the 'absolute' offset, and reading the content you'll get "78 01 01 05 00 FA FF 31 74 73 65 54 05 41 01 D2". After uncompressing this with zlib, you'll get "1tseT". {zlib header} {compressed data} {int checksum} - simplified version for zlib compressed data. The 'issue' is that... 0x78 0x01 is the zlib header for non-compressed data. That means when you made your GRF, you compressed it with the lowest compression level possible and that is the only reason why you're able to see the content in plain-text. It's definitely not something you want. In the version 0x200, the file table is compressed, which is why you get the 0x78 byte after reading the table size uncompressed property. Since you know the compressed table size is 170, you pretty much read 170 bytes after you read the table size uncompressed value, and uncompressing that will give you the actual file table data. Edit : You might want to have a look into KeyWorld's project https://github.com/vthibault/roBrowser/blob/master/src/Loaders/GameFile.js or even the OpenRagnarok project http://code.openhub.net/file?fid=D9P_ZHJdGOjvzVgQOe31Wor_U1U&cid=xmpIxx6iTvE&s=&fp=92163&projSelected=true#L0 (they'll become useful if you ever want to read versions 0x100, for the DES encryption).

Heya, If you want to change the act's color for each frame, you can use the following script : Script > Script Runner... > act.SetColor("#99F80909"); If that's not what you were looking for, could you please be more specific?

Well, for the first question... you could start with this script : function script wRand { for (.@i = 0; .@i < getarraysize(getarg(0)); .@i++) { .@cummulative[.@i] = .@total += getelementofarray(getarg(1), .@i); } .@rnd = rand(0, .@total - 1); for (.@i = 0; .@i < getarraysize(getarg(0)); .@i++) { if (.@rnd < .@cummulative[.@i]) { return getelementofarray(getarg(0), .@i); } } return -1; } prontera,137,201,4 script Random Girl 4_F_JOB_ASSASSIN,{ .@npcName$ = "[" + strnpcinfo(1) + "]"; mes .@npcName$; mes "Hello, for 100,000,000 zeny, you have a chance to obtain one of these items :"; for (.@i = 0; .@i < getarraysize(.items); .@i++) { mes "^008000~ " + getitemname(.items[.@i]) + "^000000"; } next; switch(select("Gamble!:Leave")) { case 1: if (Zeny < 100000000) { mes .@npcName$; mes "I'm afraid you don't have enough to gamble."; close; } Zeny -= 100000000; getitem callfunc("wRand", .items, .weight),1; mes .@npcName$; mes "There you go!"; break; case 2: break; } close; OnInit: setarray .items,671,676,673; setarray .weight,10,40,70; end; } You might also want to have a look into groupranditem, getrandgroupitem or getgroupitem if you're going for more... advanced uses I guess.

"Load lua before lub" and "Read lua before lub" are the same thing. Lua or lub files are the same thing too, the only difference is the file extension. As for which one is better, it depends of your client's diffs. If you set your client to read lua before lub, then you have to use lua files of course. It is generally better to use lua files wherever you can, as I've already explained above.

You should be using "Read lua before lub". If you're planning to patch your client from an official server (kRO renewal for instance) with the RSU patchers, your lub files will most likely be overwritten. This might (and probably will) end up causing errors for your players.