Tokei

Just wanted to point out that .@index = rand(0, getarraysize(.@item_ids) - 1); is the equivalent of .@index = rand(getarraysize(.@item_ids)); Except it's easier to read xD. Also, you should avoid using temporary char-bound variables in scripts (@item_id versus .@item_id), those are kept until the player logs out. The usage of "set" is also deprecated, you should be using 'variable = value;". prontera,137,203,4 script TEST::KST01 834,{ setarray .@item_ids, 501, 502, 503, 504, 505, 506, 507, 508, 509, 510; for (.@i = 0; .@i < 5; .@i++) { .@index = rand(getarraysize(.@item_ids)); getitem .@item_ids[.@index], 1; deletearray .@item_ids[.@index], 1; } end; }

Bgra32 images take a lot more space than indexed8 images. Indexed8 images are RLE compressed while bgra32 images are just raw data. Either way, putting them in a GRF will compress your files so there's no real need to worry too much about that.

You can simply right-click the image and convert it: I'm not sure what you're trying to do here. Edit: The script up there will break the SPR format. I should really remake that tool's interface, was a bit messy at the time.

The GRF name doesn't matter, it's the executable name that has to be the same.

You wouldn't be able to patch your GRF anymore.

This error happens if the filename doesn't match the one used for the encryption. Make sure it is exact (it is case sensitive).

I'm going to copy paste what I wrote on Hercules: I'm afraid this link will not be coming back along with several other files I uploaded. I am aware many of you probably already has the files and that's great, but I'd kindly ask you not to re-upload them. I am no longer willing to share free content due to how often my work has been stolen recently. It got up to a point where one of my GRF was publicly available on a RO website with all of its files fully decrypted (it's been removed now, at least). It is very demotivating and does not make me want to give back, not for now anyway.

Headgears cannot have more than 1 layer ingame. You can use Scripts > Generate sprite from selection. This will create a new layer with all your other layers merged into one (this will, however, increase the size of your spr file by a lot, especially if you're using semi-transparent images). What most people would do is to make a single image from all the black balls and move them with photoshop (well, I'm assuming they're moving).

Version 586: only for the final save, this version is buggy otherwise and should be avoided as much as possible. Version 620: everything else. You should not work with 586 for anything other than texture work. It has issues regarding the rotation of models (it's not rotating in the correct order). This cannot be fixed later on unless you redo all those objects manually. If you do not rotate your objects, you can use version 586 but you'll risk having a different map while using the client afterwards. The problem with 620 is that it doesn't calculate the quadtrees properly when you save it, so you have to switch back to 586 and save with an older version which was working fine for that part. (Bad quadtrees = black squares.)

Using an encoding different than 1252 or Korean will most likely cause you issues, so no these can't be converted back.

I'd recommend a script command instead for what you need. - script atcmd_mypoints -1,{ end; OnInit: bindatcmd "mypoints", strnpcinfo(3) + "::OnAtcommand", 0, 99; end; OnAtcommand: dispbottom "You have " + variable_here + " points.", 0x00ff00; end; } They are easier to manage and doesn't require a server recompile.

The GID is not supposed to be 199 (GIDs are way higher); the monster function does not return a value by default either, so I'm assuming you made a custom command? Either way, the following should work properly: monster(.@map$,359,294,"",2337,1); .@skillunit = $@mobid[0]; setunitdata .@skillunit, 9, 0; setunitdata .@skillunit, 29, 1; unitskilluseid .@skillunit,353,10,1;

It's a value set source-wise after calling menu; it gives you the latest selected option.

Well, you've never set the .map$ variable, so it defauts to an empty string. In the OnInit part, add .map$ = "prontera"; Or whatever map that you're using.

Your data folder files should be put inside your server's GRF, especially if they contain korean names (aka 'weird' symbols).

As others have already told you, you're doing it wrong. You're applying a Linux compilation guide on Windows, this won't work (well it will but it's definitely not recommended). If you want to run your server on a Windows environment, you will need to compile it with Visual Studio, not cygwin. All the information you need can be found here: https://rathena.org/wiki/Installation_on_Windows . For the SQL installation part, you can use https://rathena.org/wiki/SQL_Installation#Windows . This is usually to make a local server. If you plan on making a 'real server', you'll most likely want a host which is going to be using Linux and then you'll have to use the other appropriate guides.

You could use the following: UPDATE `debt` SET `zeny` = `zeny` - 1 WHERE `zeny` > 0

You need this: https://rathena.org/board/topic/104496-nightmareish-jitterbug-episode-143/?p=296127

Your script engine appears to be outdated, you'll have to replace those with callfunc("JitDiag", "Gelkah", ...) or you can use this link instead: http://novaragnarok.com/download/NightmarishJitterbug_oldemu.txt

The chats would be because you didn't copy the npctalk function properly. I'm having no errors on a clean rA copy, so I couldn't really tell you what the issue is here with the jitoptions variable. I'm guessing your script engine is a bit outdated, so you could try and add the following : If that doesn't help, then I'm afraid I do not have a solution for you =l.

Completely forgot about that, to avoid using hundreds of donpcevents, we customized npctalk with an optional parameter to target a specific NPC. Here: /*========================================== * npctalk (sends message to surrounding area) *------------------------------------------*/ BUILDIN_FUNC(npctalk) { const char* str; struct npc_data* nd; str = script_getstr(st,2); if (script_hasdata(st, 3)) { nd = npc_name2id(script_getstr(st, 3)); } else { nd = (struct npc_data *)map_id2bl(st->oid); } if(nd) { char name[NAME_LENGTH], message[256]; safestrncpy(name, nd->name, sizeof(name)); strtok(name, "#"); // discard extra name identifier if present safesnprintf(message, sizeof(message), "%s : %s", name, str); clif_disp_overhead(&nd->bl, message); } return SCRIPT_CMD_SUCCESS; } BUILDIN_DEF(npctalk,"s?"), // [Valaris]

You could check this > http://herc.ws/board/topic/10408-ro-installer-script-inno-setup/ It should be straightforward enough...!

@tokei Dear Tokei, please take a look about problem above. The problem in next: when i use grf encryption for grfs i can't run game client (exe 2012-04-10) if it located at any folder with russian characters (non english) How reproduce 1. Create folder: D:\какая-то папка\something\RO 2. Place your encrypted files inside 3. Run Client -> it wont run, because of russian characters in path name.... But, if you rename "какая-то папка" to "some folder", you able to run game client with encrypted grfs again... Please update to 1.7.8.6. The problem should be gone.

Your lub files are outdated : https://github.com/ROClientSide/Translation To be more specific, this would be related to missing entries in luafiles514\lua files\datainfo\NPCIdentity.lub and jobame.lub.

The most common issue for this is packet obfuscation; it is turned on by default on rAthena and your client probably has it turned off. The 'easy' solution is to disable packet obfuscation server side (from src/config/core.h - #define PACKET_OBFUSCATION). The recommended solution would be to set your packet keys in packet_db.txt with packet_keys_use and rediff your client with those packet keys that you used.