ckx_

Thanks for the reply. I messed with langtypes but I couldn't get the results to change. Maybe it's a difference in our lua files or our clients. However, starting over with a new tipbox lub file seemed to help me, even when the file contents were nearly identical to my old one and both were set to EUC-KR encoding. Strange. While it isn't a real solution, I did figure out the condition for which the misaligned text triggers, at least for me. When a tipbox's Page content has a link in it after a line that gets automatically wrapped by the tipbox, the text becomes misaligned. For example: So the best """solution""" I've found so far is adding explicit line breaks ( \n ) before any links that would get automatically wrapped. Of course this doesn't cover cases like the one in my original post, which I think was fixed by replacing my tipbox file. These black box client issues really drive me crazy...

Question I have a problem that I simply can't figure out. Occasionally when I start up the client, the "TipBox" feature renders misaligned links. Sometimes a client restart fixes this. My client version is 2020-07-15bRagexe. Client restarts don't always fix this. Just sometimes. It's frustrating to have to restart the client sometimes 4 or 5 times to get the feature to work. It feels like a 50-50 chance but I didn't measure a precise probability. Does anyone know any workarounds for this (system configuration or otherwise), or why it occurs? Extra info The tip boxes are read from System\tipbox_EN.lub. Note that this path is configurable with a WARP client hex ("Customize Tipbox lub"). The original Korean file is at System\tipbox.lub. I've tried a client without that hex applied, just loading up that original Korean file, and it has the same problem. This leads me to believe that the official game may have the same issue too. I've tested on both Windows and Linux (proton). TipBoxes are lua tables, with each tipbox's page content being one big string: [1] = { Title = "Tutorials", Search = 1, Image = "", Imgcoord = { Position = 5, Size = 100 }, Page = { "With the Tipbox you might find answers to your questions.\n\rTips \rthat \nare not on the list can also be found by searching, and new tips are continuously updated.\n? <TIPBOX>Character<INFO>1001</INFO></TIPBOX>\n? <TIPBOX>Gameplay<INFO>1002</INFO></TIPBOX>\n? <TIPBOX>Communication<INFO>1003</INFO></TIPBOX>\n? <TIPBOX>The World of Ragnarok<INFO>4000</INFO></TIPBOX>", }, } I've tried messing with stuff like the tip formatting, line breaks, tipbox internal links, number of pages, number of tips, lua functions that populate the actual tipbox table, and a bunch of other stuff, but I can't figure this out.

Try playing with these values: The "canmove" value & and the "125" in the clif_damage call. If you mess with them a bit you might get better results. What you're describing might be less about client version and more about server tick, but I haven't tested newer clients yet. Maybe I'll get to it over the weekend. Also I just realized the multihit_diff.patch file is only has the changes from the second commit, so it won't do anything. I removed the diff from the post.

I've only tested with a 2020 client. I'll test with a late 2022 or early 2023 client soon and post back. Did you get any changed behavior at all, or was it the same as before you applied the patch?

I created a series of 2 mailbox patches (from format-patch). The mailbox patches probably work better than a diff (and gives a formal commit for the patch) The patches are titled 0001-hacky-mutlihit-auto-attack-animation-fix-sonic-blow-.patch and 0002-add-status_delay_delete-to-cleanup-mobs-when-killed-.patch. I split it into two commits because I am not entirely confident my solution to freeing memory is the best, more on that in "Freeing unit memory" below. Applying the mailbox patch From within your rA directory (stat outputs some info, check is a dry run for validation): git apply --stat 0001-hacky-mutlihit-auto-attack-animation-fix-sonic-blow-.patch git apply --check 0001-hacky-mutlihit-auto-attack-animation-fix-sonic-blow-.patch git am 0001-hacky-mutlihit-auto-attack-animation-fix-sonic-blow-.patch git am 0002-add-status_delay_delete-to-cleanup-mobs-when-killed-.patch Freeing unit memory - Not cleaining up properly? Part of this fix is to add a new function, status_delay_delete, which checks if a mob was killed by Arrow Vulcan or Sonic Blow. It delays the cleanup of a dead mob, so that they are properly cleaned up after being killed by SB or AV. Right now this delayed deletion only applies to mobs, not to players. I have not tested this fix in any PVP environment and it is possible that players and other units are not cleaned up properly in some cases. If this is the case, you will need to create a pc_timer_delete function and expand status_delay_delete to work with PCs. I am not motivated to do this right now. If someone tests this out in a pvp environment and finds that map blocks aren't being released properly, let me know, and I will probably do something about it. Animation Timings The code is commented with some info on how to change stuff like the animation timings, but to be clear, I did not do any comparison between official's classic Sonic Blow / AV and my default values. I just put what felt good to me. If someone else wants to get the official Sonic Blow timings and put them here, go for it. Adding Multihit Skills This patch has only been tested on pre-renewal with the skills Sonic Blow and Arrow Vulcan. If you want it to apply to other skills, you'll need to add them to the switch statement commented "//Display damage." in skill_attack (skill.cpp). Follow the case statements for CG_ARROWVULCAN / AS_SONICBLOW. You'll also need to add it to the conditional in status_delay_delete (status.cpp). Quick NPC test script Below is an npc script you can copy paste to test stuff out real fast: @warp new_3-1 49, 109 new_3-1,53,95,1,4 monster Phen 1158,30,3600000,1800000 new_3-1,49,107,1,4 script BLOW IT 617,{ BaseLevel += 99; jobchange(12); skill(136,10,SKILL_PERM_GRANT); statusup2(bDex,99); getitem(1250,1); equip(1250); return; } new_3-1,48,106,1,4 script VULCAN IT 617,{ BaseLevel += 99; jobchange(4020); skill(394,10,SKILL_PERM_GRANT); statusup2(bDex,99,getcharid(0)); getitem(1953,1); getitem(1750,100); equip(1953); equip(1750); return; } 0001-hacky-mutlihit-auto-attack-animation-fix-sonic-blow-.patch 0002-add-status_delay_delete-to-cleanup-mobs-when-killed-.patch

For those coming here through search, Chaos92 is right. I ran into the same issue on a small test instance. I temporarily resized from 2GB to 4GB and it compiled fine. If that's not an option for you, try making sure swap is enabled and seeing if you can squeeze by with that.

My fork of rA is heavily modified, so a diff isn't easy for me to slap together. Sometime in the next few days I will find time to implement this fix on a clean rA and make a diff from there. I'll post another message here when I get around to it.

What skill mods do you want to implement?

If you want it to reload on `@reloadstatusdb` or any other reload command of your choosing, you can just add the line `battleground_db.reload();` to the desired spot in the reload function: https://github.com/rathena/rathena/blob/master/src/map/atcommand.cpp#L4201 For status db you'd add it after line 4281.

It's possible, but usually messy. You would need to get a reference to the NPC calling the script down to the C layer, and that can be messy, especially if instances are involved. What functionality do you want? It's likely that a source mod is more straightforward. You can add a statement somewhere in skill.cpp's `skill_additional_effect` function if you want something to happen after Bash hits a target, or you can add it under the SM_BASH case label in skill.cpp's `skill_castend_damage_id` if you want to happen as soon as Bash is used.

So... you want to make it so that when you have a Katar equipped, and you swap to a Dagger, you gain a damage buff? If you give more details about your intended functionality and your level of technical ability to make code changes I can adjust my response to help you better. For now I'll just throw out some starting points for you to investigate. I would make a custom status for this by adding an entry in status_db.yml, then setup the status in source by adding it to the `sc_type` enum in status.hpp. You'll also want to export the enum in script_constants.hpp. Where you add a check for the SC to actually increase the damage is up to how you want it to stack. For starters, you can add a check for the SC in `battle_calc_cardfix` (if you want card style damage) or `battle_addmastery` (if you want it to add mastery style attack). It seems most straightforward to give the player the status somewhere in pc_equipitem (pc.cpp). You have a few options for implementation here. I'm going to say what I think is simplest to get you started then you can improve it through testing. 1) Store a reference near the top of the function to the player's current weapon type, e.g: `int oldweapon = sd->weapontype1` 2) Near the bottom of the function, sometime after sd->weapontype1 gets updated to id->subtype, do a simple check: if (oldweapon == W_KATAR && sd->weapontype1 == W_DAGGER) { sc_start(...) } I would throw this right after the assignment happens probably, so around here. Don't forget to brace the unbraced if statement, recompile, and try it out. Note that if you want this effect to happen for specific daggers as opposed to every dagger, then I would favor an approach that calls a buildin_func through the dagger's Equip Script.

In Can_Rebirth add this after line 80: if (Zeny < 1000000) { return false; } You can experiment with putting it somewhere else if you want; this is the guard that checks for the zeny value. You should probably show a message somewhere saying that the player needs 1mil, too. In Job_Change replace line 311-317 with this: That's it. You might want to add a dispbottom line or something alerting the player 1mil was taken from them. https://github.com/rathena/rathena/blob/master/doc/script_commands.txt#L4246

For questions 1 and 2, have you already read this? https://github.com/rathena/rathena/blob/master/doc/script_commands.txt#L6650 If so I can try to explain it in a different way, but do some testing and try to figure it out for a bit. For an instance with multiple levels all you need is to define your extra levels as "AdditionalMaps" in the instance_db.yml: https://github.com/rathena/rathena/blob/master/db/pre-re/instance_db.yml#L37 Then there are a number of ways to warp to your next map, the most conventional being simply defining a warp on the base map that goes to a defined AdditionalMap. If you let me know how you want your level flow to look, I can give some more specific pointers here.

For item descriptions, it's purely clientside. That data is set up in ItemInfo.lua—Item descriptions never get any information from the server. If you edit the ATK of an item on the server, you must make a corresponding edit to the client description. The entire tbl{ } in ItemInfo.lua is loaded into memory at launch time. In your initial post, you show properties for Random Options, which are separate from the item descriptions. If you _really_ want dynamic item descriptions from the server, you could try to find a way to call AddItemIdentifiedDesc which is a function referenced in main() at the bottom of ItemInfo.lua. But as this doesn't appear to be a global function, and the item descriptions are set in memory at launch time, it will require you figuring out a clever injection point that has access to this function to see if you can overwrite the runtime value. I propose a few alternatives; If you are making a server where item stats can "grow", e.g. you get a Club and its ATK can be evolved, then I think you're best off making separate Item IDs for each Club iteration and making npc script to copy overall the properties. If you are making a server where the ATK of an item can change dynamically, frequently, then I think you're best off making an item that checks the stat of your items via npcscript, e.g. a usable called "Stat Sheet" that calls a mes window, and that shows you the dynamic properties on your items in an item function that uses getitemdata. If you are doing one-off edits then I think editing ItemInfo.lua is best, you could write a quick script that crawls your yaml item db and inserts the correct values into the lua file for you. Otherwise you might consider enchant or ropt slots for this data, which do read from the server.

I hackily solved this on the source side. A side effect of my solution is that it shows extra damage numbers (but the multihit total is still correct, and the extra damage numbers are visual only). My solution: In the "display damage" switch block in skill_attack: case CG_ARROWVULCAN: case AS_SONICBLOW: { dmg.dmotion = clif_skill_damage(dsrc, bl, tick, dmg.amotion, dmg.dmotion, damage, dmg.div_, skill_id, flag & SD_LEVEL ? -1 : skill_lv, dmg_type, dmg.crit); struct unit_data* ud = unit_bl2ud(dsrc); if (ud) { ud->dmg = dmg; ud->sb_animation = 0; ud->sb_target = bl->id; ud->sb_timer = add_timer(gettick()+20, skill_sonicblow_animation, dsrc->id, 0); } break; } ↑ This plays the default SB animation, sets up some data, then adds a new timer function. Here's the code for the timer_func it adds: TIMER_FUNC(skill_sonicblow_animation){ struct block_list *target, *src; struct unit_data *ud; struct status_change *sc = NULL; int flag = 0; src = map_id2bl(id); if(src == NULL) { return 0; } ud = unit_bl2ud(src); if(ud == NULL) { return 0; } target = map_id2bl(ud->sb_target); if (!target || ud->sb_animation >= ud->dmg.div_ || ud->sb_timer == INVALID_TIMER) { ud->sb_animation = 0; ud->sb_timer = INVALID_TIMER; return 0; } int div_ = ud->dmg.div_; if (div_ < 1) { div_ = 1; } t_tick canmove = tick_diff(ud->canmove_tick, tick); canmove /= (div_-ud->sb_animation); if (canmove > 175) { canmove = 175; } clif_damage(src, target, tick, 125, ud->dmg.dmotion/div_, ud->dmg.damage/div_, div_, DMG_NORMAL, ud->dmg.damage2/div_, ud->dmg.isspdamage); ud->sb_animation++; ud->sb_timer = add_timer(tick+canmove, skill_sonicblow_animation, id, data); return 1; } ↑ This just sets up some damage then calls clif_damage, and sets up another timer func to keep it going until sb_animation reaches skill's div count. To be clear this will work for any multiattack that you want to have spam auto attacks, not just SB. Sorry for the naming scheme. The extra damage numbers are customizable by changing what you pass to the clif_damage call. You can set it to all 1s, or all misses, or anything else. Unfortunately I never found a way to implement this without the extra numbers—I'm not sure how to force the client to arbitrarily play an auto attack animation with no corresponding damage numbers. If someone knows, I'd be interested. and in the unit_data struct: int sb_animation, sb_target, sb_timer; // hacky sb animation fix ↑ just some state data, ud seemed like the best place to put it so that it works on both mobs and players. This produces a sonic blow like in the attached file. also viewable here: https://mikomiko.org/files/Screencast_20240512_005716.webm It's not perfect but I'm happy enough with it for now. Screencast_20240512_005716.webm