Tokei

That's a different issue though; rand(0, 0) doesn't make sense. You could edit the BUILDIN function to ignore such a case, since one could argue that rand(0, 0) should return 0. In the original script posted by InfectedX, it was impossible to have such a scenario so the error didn't make sense. That's why I suggested him to use an entirely different method instead.

Hmm, I'm not entirely sure. My first guess would be the lack of a 1-pixel border around the image. But perhaps there's something else going on with the image itself (maybe it's a transparency image?), but I'd need to have a look at the act/spr files first.

Ah no, the script I posted isn't meant to just copy paste and run. It's just if you have doubts with a mechanic or something; it's way too custom to be used and I'm too lazy to convert it to rAthena's standards.

There is no issue with the code sample you've provided. It's a bit hard to read, but besides that, it works fine for me. To make your life easier though, may I suggest using a command like shufflearray instead? Like so: BUILDIN_DEF(shufflearray,"r?"), BUILDIN_FUNC(shufflearray) { map_session_data* sd = NULL; int i, j; int array_size = script_hasdata(st, 3) ? script_getnum(st, 3) : -1; struct script_data* data = script_getdata(st, 2); if (!data_isreference(data)) { ShowError("buildin_shufflearray: not a variable\n"); script_reportdata(data); script_pushnil(st); st->state = END; return SCRIPT_CMD_FAILURE; } const char* name = reference_getname(data); int32 id = reference_getid(data); if (not_server_variable(*name)) { sd = map_id2sd(st->rid); if (sd == NULL) return SCRIPT_CMD_SUCCESS; } if (array_size < 0) { array_size = script_array_highest_key(st, sd, reference_getname(data), reference_getref(data)); } // Start shuffling the array if (is_string_variable(name)) { for (i = array_size - 1; i > 0; i--) { j = rnd() % (i + 1); const char* temp_val = get_val2_str(st, reference_uid(id, i), reference_getref(data)); set_reg_str(st, sd, reference_uid(id, i), name, get_val2_str(st, reference_uid(id, j), reference_getref(data)), reference_getref(data)); set_reg_str(st, sd, reference_uid(id, j), name, temp_val, reference_getref(data)); script_removetop(st, -1, 0); script_removetop(st, -1, 0); } } else { for (i = array_size - 1; i > 0; i--) { j = rnd() % (i + 1); int64 temp_val = get_val2_num(st, reference_uid(id, i), reference_getref(data)); set_reg_num(st, sd, reference_uid(id, i), name, get_val2_num(st, reference_uid(id, j), reference_getref(data)), reference_getref(data)); set_reg_num(st, sd, reference_uid(id, j), name, temp_val, reference_getref(data)); script_removetop(st, -1, 0); script_removetop(st, -1, 0); } } return SCRIPT_CMD_SUCCESS; } Then you can simply code it like this: 1@thts,0,0,0 script #thanatos_main -1,{ OnInit: setarray .@rng_floors, 3, 4, 5, 6; shufflearray .@rng_floors; setarray 'floors, 1, 2, .@rng_floors[0], .@rng_floors[1], .@rng_floors[2], .@rng_floors[3], 7, 8; setarray 'maps$, instance_mapname("1@thts"), instance_mapname("2@thts"), instance_mapname("3@thts"), instance_mapname("4@thts"), instance_mapname("5@thts"), instance_mapname("6@thts"), instance_mapname("7@thts"), instance_mapname("8@thts"); setarray 'coords_coords, 0, 0, 0, 0, 27, 44, // 3rd floor 18, 97, 155, 100, 50, 18, 50, 18, 50, 18; // other stuff here... end; } 1@thts,32,166,0 script #setp02 45,2,2,{ end; OnTouch: .@next_floor = 3; warp 'maps$[.@next_floor], 'coords_coords[2 * .@next_floor + 0], 'coords_coords[2 * .@next_floor + 1]; end; } As you're clearly implementing Thanatos Tower, you might find some inspiration from when I wrote the script (though it uses quite a few custom script functions and it also has a custom hard mode, but it can probably still be of use). It's from kRO replay files, so the NPC coordinates should be very accurate. thanatos.txt

It appears I reached the maximum messages amount (300), sorry about that. I've cleaned up my inbox, so it should be fine now.

You can also use roBrowser: https://github.com/vthibault/roBrowser/blob/e4b5b53aa1f8b7e429bfa987ab321c96502ba1da/src/Loaders/Action.js Or GRF Editor: https://github.com/Tokeiburu/GRFEditor/blob/main/GRF/FileFormats/ActFormat/ActConverter.cs

I would suggest to not speak nonsense on a development forum, it doesn't make you look good at all. This has absolutely nothing to do with sources being public. For that matter, the sources have been public for more than 10+ years on rAthena. Not only that, but C# is not a compiled language, it can be "decompiled" with little to no effort to begin with using tools like JetBrains. What's worse in what you said is that the encryption is applied via cps.dll, compiled in C++, which isn't released in the source at all. Even if someone didn't know the sources were public on rAthena, Act Editor has all the libraries in plain sight outside of the executable to begin with. For reference (because I've heard that comment many times already):

I am aware. However this isn't a high priority for me at the moment. If someone wants to spend time on this, feel free to contact me. I'll get to this eventually, but it won't be anytime soon.

Heya, I've been receiving messages about people selling NovaRO's decrypted GRFs and honestly... that's beyond stupid. The server is already closed down, anyone buying this is getting straight up scammed. You could have just asked. I put the key attached down there. I'm too lazy to upload the GRFs though, you'll have to find that yourself (or if someone want to host it and link it below, go ahead). Plus, we released installers without the files encrypted on accident multiple times, so it's not like these files weren't already accessible to begin with. nova.grfkey

That's a wrong thread if I've ever seen one. That being said, csc.exe is the .net compiler. If you get that error, you have to install the ".net 3.5 framework".

That's not possible, the client doesn't support that feature. You'd have to make a custom system for it, and it would still not display properly. A lapine box might work better? Not sure. You'll probably have to end up doing it with a boring script though, since it's hard to handle two refines otherwise.

Heya, GRF Editor has undergone some big updates in the background in its new release (1.8.5.7) : The .net framework has changed from 3.5 to 4.0. It has been compiled as x64 instead of x86. The cps/lzma libraries have also been recompiled to x64. Another VC++ library is now required: Microsoft Visual Studio C++ 2022 (x64), which can be downloaded here https://aka.ms/vs/17/release/vc_redist.x64.exe A warning will be given if the VC++ library is missing, so it shouldn't be a problem. The preview for RSM/RSM2/RSW files have been remade from scratch based on BrowEdit 3. It now uses OpenGL instead of WPF 3D. While WPF 3D had good performance, it was way too limited in its options, so this change was a must (shaders weren't even possible...). Though, the performance now is somewhat unknown. If it causes too many issues, I'll add an option to revert back to WPF 3D. The new map renderer should be much more accurate to what is shown ingame: Lightmap/shadowmap is now supported. Lub effects are visible. RSM1 animations can be previewed. Maps are animated by default. Fixed a lot of transparency issues (still not perfect, but it's a huge improvement). Many new features were added for rendering. A skymap option was added but that one is still in its early stage. While the preview is focussed, F11 can bring the renderer to fullscreen. Water is now rendered I usually don't write an update post, but I did this time because I'm wary of potential issues. I'll leave here some previews:

Heya, You're right, this is definitely the wrong thread ;P. There are many ways of doing this, so here goes. for (int aid = 0; aid <= 7; aid++) { var action = act[aid]; for (int fid = 0; fid < action.Frames.Count; fid++) { var frame = action[fid]; for (int lid = 0; lid < frame.Layers.Count; lid++) { var layer = frame[lid]; layer.OffsetX = 2; layer.OffsetY = -82; } } }

Well, first thing first, you should download the latest version. As for lzma.dll: Microsoft Visual Studio C++ 2005 (x86), https://www.microsoft.com/en-us/download/details.aspx?id=26347

The script engine was never finished. It does work, but there is no documentation for it so it's not like anyone can use it. It was meant for myself for some testing. Though, you can use this: var scale = 0.5f; var centerOffset = new GRF.Graphics.Point(319f, 291f); for (int i = 1; i < str.Layers.Count; i++) { var layer = str.Layers[i]; for (int k = 0; k < layer.KeyFrames.Count; k++) { var keyFrame = layer.KeyFrames[k]; keyFrame.Scale(scale); // The offset shown is not the real XY value. The center is rebased by the centerOffset, so some math is needed var center = keyFrame.Offset - centerOffset; center = scale * center; keyFrame.Offset = center + centerOffset; } }

You have many ways of doing it. You could use a loop with an array, but this one is pretty straightfoward: if (countitem(A)) { .@itemid = A; } else if (countitem(B)) { .@itemid = B; } else if (countitem(C)) { .@itemid = C; } if (!.@itemid) { mes "Hello, Good day huh?"; close; } mes "Oh you want this juice?": mes "let me have a look that " + getitemname(.@itemid); next; mes "Nice!, thanks for showing me,"; mes "you can have this juice !"; getitem 7709, 1; close;

A bit of a random reply, but for future reference, you can simply use Scripts > Merge layers (new sprites). That will create a single layer for all your frames.

Heya, This topic is actually very complex and it has tons of exceptions. It also depends of the client version since they do have different behaviors. When the clif_damage packet is sent, the important value is "sdelay", "amotion", "animation motion" or "attack motion". This is the duration of the attack animation shown by the monster. This value is defined in your mob db file under AttackMotion. The AttackMotion is the speed at which the mob displays its attack animation and it can go between 0 and 500. It works as you think it does (ish): An AttackMotion motion of 100 would be 100 * AttackMotion / 500 = 1/5th of the normal duration. Meanwhile 600 AttackMotion would be capped to 500, giving you the full attack animation duration. Now you would think the animation duration is given by the AttackMotion, but that's just bullshit. That's not the case at all. The damage number shown isn't related to that. The real animation duration that the client reads is given by the Act file itself by the action index 16. If you take Willow as an example, it has 7 frames at 100 ms each, so it has a total duration of 700 ms. Now there's another special "feature" going on here. The damage number will be shown at "frames count - 1". So in the case of Condor, the damage animation will be shown at frame 7. So while the animation duration is indeed 9 x 75 = 675 ms, the damage number will be shown at 7 x 75 = 525 ms. To be clear, it is shown the moment the frame appears and not when it ends, so that's why it's not 8 x 75 but 7 x 75. As for Condor, there is yet again another special "feature" going on. The damage number will be shown earlier if the "atk" sound is triggered. In the case of Willow, the attack sound is at frame 3, so while the animation duration is 700 ms, the damage will actually be shown at 3 x 100 = 300 ms. Now that's why the attack isn't displayed at the end of the animation as you'd expect it to be. The character stops moving on the client once the damage number is shown. More on the server-side of things: The damage will be inflicted after the AttackMotion timer server-side. Once AttackMotion runs out, the player movement will be stopped, that position will be saved and then a clif_updatestatus will be sent for the new HP value. So as you can imagine, there is absolutely no way that the position in the client and the position on the server would be the same considering all this. The server can't know the Act file true damage animation duration vs attack animation duration. Overall, quite the blunder Gravity made, yet again. And that's just what I've found out through the years. I'm sure there is plenty more weirdness going on there, like how player ranged melee attacks are 4/3 of the AttackMotion on some clients, creating even more position lag issues. Anyway, to fix your issue, change the "atk" sound and it will work out, but fixing that for all mobs doesn't seem very realistic to me. Edit: Please keep in mind most of the above is only related to monsters; players have different behavior in regards to AttackMotion.

Thor files are a bit different because you can have files outside of the "data" folder, so the pathing needs to be fixed. Therefore, when adding a file to a thor file, you need to add the "root" as the base folder: add "root\data\" "C:\whatever.txt" There are some conversions behind the scene to make a thor file compatible with a grf file, otherwise it's troublesome to display it properly in the editor. There are also no issues ignoring that warning, the "root" folder is more or less ignored when saving either way.

Added the options in 1.8.5.3 : help options options /UseGrfMerging=true /TargetGrf=test.grf Drag and drop is a Windows problem. Windows Explorer must have the same privilege as the program you're using for drag and drop to work. I'm assuming your Windows Explorer is running with user privileges, so that means you're running GRF Editor with admin privileges. So to fix the issue, stop running GRF Editor with admin privileges.

This should be fixed now, sorry about that: 1.8.5.3

I added the encryption commands (setKey, encrypt, decrypt) to it in 1.8.5.1. Here's an example: -open test.thor -setKey mykey.grfkey -encrypt -save Where the mykey.grfkey is the file version of your password. You can generate this file via Tool > GRF Encryption:

Well, it seems there's a problem with the custom decompression library you're using...? Not sure what's up there, but you'll probably want to change it to the default compression library. If you have issues loading the default compression library, you'll need to install some VC++ libraries: For Gravity Official Zlib Library (cps.dll), you'll have to install VC++ 2010 (x86). For LZMA Library (by Curiosity, lzma.dll), you'll have to install VC++ 2005 (x86). Same issue as above (most likely). lzma.dll requires VC++ 2005 (x86). You only appear to have x64, which is not compatible.

Functions don't get unloaded when you reload a script. So the script engine thinks that Class_Mastery is a function since it was previously defined here: function script Class_Mastery { But you're using it as a constant variable... everywhere. Either change the names around, like F_Class_Mastery, or remove the function altogether. It feels like you're using this function on an item script, so changing it to F_Class_Mastery would be enough. (Also, you might want to use proper formatting, it's very hard to read.)

If they aren't in your data.grf, then your data.grf isn't the latest. You have a few options available. The easiest option is to download one of the "latest" kRO full client on rAthena, this thread appears to be the most active one: Then use Ragnarok.exe to patch your game afterwards. If your "latest" kRO full client above didn't bother to add the official Gravity patcher (Ragnarok.exe), then you can use the one from Ai4rei here: http://nn.ai4rei.net/dev/rsu/#download (use kRO RAG) and patch the data.grf directly with it. By the looks of it though, the thread above provided the rsu patcher directly so might as well use that. The harder option is to go on https://ro.gnjoy.com and download the official RO game (though I think you have to register first, which may be a problem? Not sure, haven't done that in a while).