Leaderboard

I am looking to make, and to continue working on, a redefined version of Ragnarok's graphics. Here's an example of what the changes will look like. The project will take much time to complete since there are well over 100,000 images to change. This is going to be released in the future. Mostly free to the public. This is going to be processed with all textures and items as well to match the sprites of the players. The goal? -Finish all Textures for the world before 2024 -Finish all Sprites before mid 2024 : On the left you have the before sprites : : On the right you have the after sprites : : TEXTURE PROGRESS : 86,628/ 86,628 Demo Release: https://drive.google.com/file/d/17RZm9ZIB3vlrOiDEa5Dl7liodwqhTKSh/view?usp=sharing : SPRITE PROGRESS : 0/0 Demo Release: Demo releases exlcude several key textures for many popular areas. Get the premium version added to your Custom GRF to unlock all features. This pack must be loaded before both data.grf and rdata.grf. All premium users must have an encrypted GRF for their server. No purchases available for unencrypted GRFs.

Need the latest kRO Install folder for your private server? Look no further! ----> Download <---- Latest: 2023-04-04 Installation: Official kRO Updated: 04/04/2023 Download Link: https://mega.nz/folder/jUsDgRxQ#ttLmLjPY9p9cfU5_ShWVCw Package contains RSU RO Patcher Lite for kRO and kRO RE by [Ai4rei] This package is maintained by [Akkarin] Note: Due to continued abuse of my webservers, the files have been moved to MEGA. You can download an extractable .zip of an installed kRO directory, or you can download the official installer from kRO's website. Note: If you require older maps that are compatible with 2021 and older clients, download the 2021 .zip. A fan of this topic? Hit the rep button

You can never not do it

For the modification of Ragnarok itself, you will only need C++ and rAthena Script (the language NPCs are written in). For C++ you could get some books or look online for tutorials. As resources for rAthena Script, you have the documents I linked you in my previous post. Personally I think, the best way to learn a programming language is by reading how the language works and then using that basis to do own small projects and to read and modify other peoples programs to steady your knowledge. The headgear list is a list of existing headgear sprites in the game. It only shows a picture representation of the sprite from the front. A Client is a software that connects to another software to request things from it. The Server is a software that accepts connections and handles requests from Clients. (The Server >serves< the Clients.) It processes requests and sends back the answers to the Clients. An emulator is a software that tries to exactly reproduce the behavior of another software. In the Client Server sense it would be like this: If the Server isn't the original software, but behaves like the original in that it serves the same results to the Clients the original would, it is an emulation. The essentials are rAthena Full Client Unpacked and patched exe Translation Patch GRF Editor You go into your client's folder, search for the data.grf and open it. Then you will see a list of folders. From there, you can search for the files you are interested in. Sprite files end with .spr and are most of the time paired with an .act file. They base sprites are stored in data/sprite. Model files end with .rsm or rsm2. You can find them at data/model. Here you can see what most of the folders in the grf mean to help you navigate through it a bit better: https://github.com/rathena/rathena/wiki/Data-Folder

that was my account but I can no longer access it because some complication. you can try check if the *.@mob_id[N]* is exist to debug it why it doesn't work. or change code on part. or change the src code mod into src\custom\script.inc BUILDIN_FUNC(specialeffect3) { int id = script_getnum(st, 2); int type = script_getnum(st, 3); enum send_target target = script_hasdata(st, 4) ? (send_target)script_getnum(st, 4) : AREA; struct block_list *bl = map_id2bl(id); if (bl == nullptr) { ShowError("buildin_specialeffect: unknown game object with id %d.\n", type); return SCRIPT_CMD_FAILURE; } if (type <= EF_NONE || type >= EF_MAX) { ShowError("buildin_specialeffect: unsupported effect id %d.\n", type); return SCRIPT_CMD_FAILURE; } if (target == SELF) { map_session_data* sd; if (!script_rid2sd(sd)) return SCRIPT_CMD_FAILURE; clif_specialeffect_single(bl, type, sd->fd); } else clif_specialeffect(bl, type, target); return SCRIPT_CMD_SUCCESS; } src\custom\script_def.inc BUILDIN_DEF(specialeffect3,"ii?"), and in your script OnKill1: specialeffect3 .@mob_id[1], 68, AREA; callsub OnSetWinner, .mob_id_2, "WALA"; OnKill2: specialeffect3 .@mob_id[1], 68, AREA; callsub OnSetWinner, .mob_id_1, "MERON";

It's not the greatest implementation ever but I can show you the gist of it. In the struct mob.hpp, there is a new field in the struct mob_db: unsigned int pity; In mob.cpp, this value is initialized to 0 in mob_parse_dbrow, near the bottom (its exact position doesn't really matter) entry.pity = 0; Also in mob.cpp, in the method mob_dead under "player specific drop rate adjustments", we add bonus drop rate based on the pity value, if the item is a card. This is the part that is kind lackluster. // Increase the drop rate based on pity if it's a card if (it->type == IT_CARD) drop_rate = drop_rate * (50 + md->db->pity) / 50; The way this formula works is that the value "50" here is the number of kills required to double the drop rate of the card. On my server, cards drop at a rate of 1/200, so this feels kinda reasonable, but if you rate was, say, 1/1000, this would be way too high and you'd probably want to set this value to like 200 instead (make sure both numbers are set to the same value). For an optimal implementation this value should probably derive from the server's card drop rate in some way but I kinda hastily coded this one in. Also in Mob_dead, we need to make a slight change later on to increase or reset the pity based on if the card drops or not. // attempt to drop the item if (rnd() % 10000 >= drop_rate) { if (it->type == IT_CARD) { md->db->pity++; } continue; } // Reset the pity if the card drops if (it->type == IT_CARD) { md->db->pity = 0; } And that's really all there is to it, recompile the code and you have the pity system. Note that, as I mentioned when I first brought it up, the pity is shared among all players, and it also gets reset every time you reset the server. But for midrate servers, it does help make hunting for cards feel more tolerable. I haven't had to kill 1000 Santa Porings with no card drop since I implemented it.

try link https://drive.google.com/drive/folders/1NKzHYH4o2KUMxR5yFeVxV6iKkD11MLSr from Checkmate, above your post.