Tokei

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.

Your files aren't in the correct folder. Clients below ~2012-07-10a use data\lua files, not data\luafiles514\lua files. If you use the "load lua before lub" patch, then you file names must end with lua, not lub. The luatolub.bat batch file will just cause you more errors (since, as the name says, it changes the names from .lua to .lub which is what you don't want). As for the shortcuts, you may want to get a more recent hotkey.lua/lub file.

I'm using Act Editor. Making transparent images is somewhat straightforward...! Photoshop > Save as png > Drag and drop the new file (semi-transparent images must be added at the end of the list). As for how I made the images... well I don't really want to go in-depth since it's somewhat complex and I don't think this is what you want to know ;].

Well, you could always... make the black semi-transparent I guess. Before I go on though, it is possible to achieve the original sprite you were looking for, but you'd be forced to use the robe slot (this is what FXFreitas's meant, I think). For more info : https://rathena.org/board/topic/72734-guide-custom-wings-at-robe-place/ You could make the sprite semi-transparent, it would look like the following (³²_kaura1) : If you use a semi-transparent gradient though, you might be satisfied with the result (³²_kaura2) : Side note, the walking frames for top right are somewhat off. Kiel Aura 2015.rar

I can use it, but how to change the size of its body, I want to make it larger How should I edit ".act" >< Editing the act files would take way too much time. Anyway, this GRF was generated with Act Editor using a script; the topic and post you'll want to see is this one. To run a script from Act Editor : Scripts > Script Runner... > paste the code found in the post and change the magnifying scale.

Alright, I've added support for larger GRF files, please update to 1.7.3.8+ ( http://www.mediafire.com/download/aflylbhblrzpz0h ). They do appear to work properly ingame, but I would still advise you to cut it in smaller parts.

Headgears always appear in front of the character; changing the front/back of the reference sprites won't change anything. This is how it looks with the black section being transparent : Kiel Aura 2015.rar

Yes, the problem comes from the 2 GB file size limit. I will increase the limit up to 4 GB in future versions, but going beyond this point is not feasible. Also, on a side note, this GRF shouldn't exist. It should have been splitted up with rdata.grf; my data.grf is 1.6 GB (1.2 GB with lzma) and it is fully updated. Edit : compiling it in 64bit wouldn't change much; it would only make it worse when saving the GRF (the GRF has a limit of 32 bits for the pointers, all you can do is make it unsigned).

Couldn't you simply edit your the job changer script? In rAthena, npc/custom/jobmaster.txt and change the line .SecondExpanded = 1; // Enable new expanded second classes: Ex. Super Novice, Kagerou/Oboro, Rebellion? (1: yes / 0: no) Or just edit the script to do what you're looking for, there's no need to modify your renewal settings to enable one class...!

Ezio is correct, the address is not valid. Maybe you're mixing up your ftp and http addresses? The ftp service is enabled on ftp://ro.ucoz.com/ro/- it requires a username and a password though. Check your setup (and watch out, in Chrome, the protocol isn't shown in the url (ftp/http))!

Does this happen with other headgears? What happens when you wear another headgear, do the two stack on top of each other? Maybe you used setlook at some point in one of your script, you could try to reset your look with the script below. prontera,157,225,4 script Style Remover 4_PORING,{ unequip EQI_HEAD_TOP; unequip EQI_HEAD_MID; unequip EQI_HEAD_LOW; unequip EQI_COSTUME_HEAD_TOP; unequip EQI_COSTUME_HEAD_MID; unequip EQI_COSTUME_HEAD_LOW; setlook 3,0; setlook 4,0; setlook 5,0; end; }

I'm confused as to what you did last. A similar bug was present when I first introduced the feature, so please update to the latest version available ( http://www.mediafire.com/download/aflylbhblrzpz0h ). If your issue persists, please send me a private message with your thor patch file and specify your Thor Patcher version. I'll have a look.

Not sure what you're trying to achieve here...! The encryption is based per file, not for the whole GRF. If you're merging non-ecnrypted files in a fully encrypted GRF, then the non-encrypted files will remain non-encrypted. If you want to encrypt your patch files, then I'd suggest you to follow this guide : http://hercules.ws/board/topic/6047-grf-editor/?p=44463

Make them yourself, just copy and change the file names...!

Download a fresh full client, the data.grf you're using appears to be outdated or missing files. When you get a sprite error it'll give you the resource missing (which... well, tells you what's missing really). You could find the mising sprites manually too... data\idnum2itemresnametable.txt (or itemInfo.lua) > Cultus > [1135] > ĿƲ·¯½º > data\sprite\¾ÆÀÌÅÛ\ĿƲ·¯½º.spr data\sprite\¾ÆÀÌÅÛ\ĿƲ·¯½º.act data\texture\À¯ÀúÀÎÅÍÆäÀ̽º\collection\ĿƲ·¯½º.bmp data\texture\À¯ÀúÀÎÅÍÆäÀ̽º\item\ĿƲ·¯½º.bmp Is your data.grf being read at all? Check your data.ini.

Hmmm, have you tried turning the fog off (with /fog)? The maps don't have issues. Try and mess with the settings in your setup, see if it makes a difference.

The church is the most problematic model because of its complexity; the tested clients I used are : 2010-07-30, 2012-04-10 and 2013-08-07. Anything above 2010-07-30 should in theory work without issues. I can cut off the church model in even more parts to allow older clients to load the model, but for that I would need the client version to test it on. Also, the link has been reuploaded around last week. If you've downloaded the GRF before that, then I'd suggest you to try it again (the file size should be around 61 MB).

You have to cut the sprite (or make it invisible, set the layer's sprite ID to -1). An alternative would be to use robe sprites instead : https://rathena.org/board/topic/72734-guide-custom-wings-at-robe-place/