Tokei

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/

From my own tests, the selection screen window as well as the equipment window cause issues with sprites depending on their location and their size. Images with more than 65536 pixels (which is around 256 by 256 pixels) have a high risk of crashing the client, especially Bgra32 images. If they're too high or too low, you can definitely expect a crash too. There are no problems when actually wearing these sprites and moving around ingame, the bugs only start when you open up these two windows. I wasn't able to confirm the actual value limits though - they are "half guessed". On a side note, monster sprites do not appear to suffer from these limitations. As for the second question, there are no limits for the amount of frames, as long as the amount is divisible by 3 for the animations 0 and 2 (Idle and Sit). This is because the client reads these two animations differently. If you have 15 frames, the first 5 will be used for the animation when the head is looking down, the next 5 are used when looking right (bottom left) and last 5 ones are for looking left (bottom right). Headgear sprites therefore have a minimum amount of 3 frames for these animations. When you said "8", I'm assuming it is actually 9 frames total, which is 3 for each head position and it should work out fine. If you want to add one more frame, you'll need 12 frames and etc.

You can try upgrading to 1.7.2.5 ( http://www.mediafire.com/download/aflylbhblrzpz0h ); there hasn't been many changes added regarding the merging process other than a file position condition check. I have retested various merges on my end and I haven't encountered any issues. You can look for corrupted entries from Tools > Grf validation > Validate content > Validate. If you are able to reproduce the issue, using the latest version, please send me the two corresponding GRFs (here or via a private message). You should also be getting an error of some sort when you click on the file; use the "Copy exception" button and paste the result somewhere. It might be helpful.

You could but in the end, the GRF can only be read by your client and that specific dll (or using GRF Editor and the password).

For the client to read the encrypted GRF, you need the custom DLL generated by GRF Editor when you set up your client files (from Tools > GRF Encryption). Your friend will not be able to read or see any of the files in the GRF, he will only be able to see the file names. You can use the following guide for more info : http://hercules.ws/board/topic/6047-grf-editor/?p=44463

I've investigated it a little further; the problematic model is Catholic_01_h.rsm, it crashes the 2012-04-10 client because the nodes Catholic_01_h and churchstatue_s_003 have too many polygon faces. I've cut the model in 4 different parts and updated the link ( http://www.mediafire.com/download/7hcz6u9vl4vjhb4/newprontera.grf ). I have successfully loaded the prontera map on clients 2010-07-30 and 2012-04-10. It should work now @@!

This is the official behavior of the client, you simply disabled the feature when diffing it. If you're using NEMO, uncheck "Disable 1rag1 type parameters". In your patcher's configuration file, set the client's arguments to "-1rag1" and that's all. This is not a perfect protection; players can still skip your patcher if they really want to (it's good enough for most cases though).

This option has nothing to do with the number of patches; it's about the GRF's degree of fragmentation. Everytime you patch files in a GRF, patchers will erase content and replace it with new items if possible. This operation creates wasted space in a GRF; for example, if you replace an image which had a size of 1000 bytes by a new one of 800 bytes, you'll be left with 200 unused bytes. This has the advantage of being efficient (in speed) most of the time and it's great for quick patching. The disavantage is that if you do this often, you'll get multiple 'holes' in your GRF - a fragment. When the GRF reaches 50 fragments, it will be repacked/defragmented, which is rather quick anyway. This whole process is almost exactly the same as what happens to your hard drive.

You could start with the following : - script ANY_MAP_SPAWNER -1,{ OnInit: .mobId = 1002; setarray .maps$,"prontera","izlude"; donpcevent "ANY_MAP_SPAWNER::OnAddMob"; end; OnAddMob: monster .maps$[rand(0,getarraysize(.maps$) - 1)],0,0,"--ja--",.mobId,1,"ANY_MAP_SPAWNER::OnMyMobDead"; announce "A new mob has spawned!",0; end; OnMyMobDead: initnpctimer; announce "The mob has been killed by "+strcharinfo(0)+", wait a hour for the respawn.",0; end; OnTimer3600000: stopnpctimer; donpcevent "ANY_MAP_SPAWNER::OnAddMob"; end; }