INREM

Not sure whether this is ultimately more of a "source" question or a "script" question, but here we go... The documentation for OnPCMapLoadEvent implies that it's restricted to triggering only on "flagged" maps because otherwise it would have a terrible impact on the performance of well-trafficked servers: The fact that this label requires a mapflag for it to work is because, otherwise, it'd be server-wide and trigger every time a player would change maps. Imagine the server load with 1,000 players (oh the pain...) Notably, there's no similar warning for OnNPCKIllEvent, which when set seems apt to trigger hundreds or thousands of times more often than OnPCMapLoadEvent would. Why is OnPCMapLoadEvent singled out like this? Is there a special concern about it bottlenecking a particular execution thread? The crux of my interest is that I would ideally like to check for the presence or absence of a particular custom SC status when players change maps. I could do without, but it will make the implementation of a certain bonus feature a little more janky. I'm willing to drill down into the source code to patch this in directly if it would help, but I would like to understand the basis of the concern about overusing OnPCMapLoadEvent - assuming it's well-founded. Thanks!

For anyone looking into this in the future: I ended up modding the source - extending the BUILDIN_FUNC for the makeitem family of script routines with my own optional variable and then modding map_addflooritem in map.cpp/.hpp, which applies the grace period on floor drops.

Normally, when an item drops on the ground after a monster is killed, a "grace period" for the player who did the most damage (and then the second, and third) goes into effect. This duration is set with the constant item_first_get_time in drops.conf. Is there a way to achieve a grace period effect when creating items on the ground with makeitem? I didn't see anything in the documentation about a parameter to limit pickup on the item to a particular player for a period of time.

Hi all, I'm trying to get a better understanding of how drop rate bonuses applied with SC_ITEMBOOST work. Apologies for the waterfall of questions - I'll try to keep this clear. If I wanted to apply a 100% drop rate bonus with SC_ITEMBOOST, without any duration limitation, I believe I could use this script command: sc_start SC_ITEMBOOST, INFINITE_TICK, 100; I could end this bonus - and I assume all SC_ITEMBOOST bonuses (assuming more than one can be applied...) - by using this script command: sc_end SC_ITEMBOOST; Digging a little deeper: Question 1: How persistent is SC_ITEMBOOST's bonus? For instance: Does it survive logouts? How about map changes? Player death? Or PC stat calc events? Question 2: What happens if my scripts use sc_start SC_ITEMBOOST multiple times? Do these values add? Overwrite with the latest/highest value? Is it possible to have multiple SC_ITEMBOOSTs in effect with the same duration, or with different durations? Question 3: Is it possible to read the current total SC_ITEMBOOST bonus applied to a character? Not simply whether the bonus is in effect, but how much? It wasn't clear to me from the docs whether this could be done with getstatus. Question 4: If I'm understanding correctly, I can end all of the SC_ITEMBOOST applied to a character by using sc_end SC_ITEMBOOST. Is there are more fine-grained way to modify SC_ITEMBOOSTs that are currently in effect? Or can I only flush the whole stack of SC_ITEMBOOST bonuses (well, assuming there can be more than one in effect at a time...) and reapply a new SC_ITEMBOOST at some value? To make this more concrete, let's say I want to have a special drop rate bonus (call it "MySpecialBonus") applied with SC_ITEMBOOST that will persist until a particular event occurs (so its duration is effectively unlimited). I would like to be able to remove MySpecialBonus without nuking any other SC_ITEMBOOSTs in effect now (say, from Bubble Gum). Is that possible? Much thanks in advance for any insights.

Much thanks. Haven't had time to look into the hair style issue, but the suggested fix for Izlude worked. To unpack that a bit for anyone who encounters this issue in the future... This was a conflict with some pre-renewal assets that had also been included in my custom GRF (probably unnecessarily, since this is a renewal server). I opened myserver.grf with GRF editor and renamed data\izlude.gat, *.gnd, and *.rsw to "izlude_disabled.gat" (and so on). This caused the default data.grf's versions of those files to be loaded instead of the ROtransation pre-renewal assets. The translation guide I was originally following had recommended including both renewal and pre-renewal translation patch assets, added to the custom GRF in a certain order, but I'm going to try rebuilding the client without that pre-renewal stuff in the mix at all since I suspect that other issues along these lines are going to crop up.

Hi all: I'm currently working on setting up a Renewal server. On the client side, I started with the kRO 20210406 client with Ragexe version 2020-04-01b patched with ROEnglish. Generally this seems to work, but there are some... errata.... Most pointedly, Izlude's map data is pretty off kilter. When a character makes it out of the "remote island" starting map, he ends up in the water outside of Izlude's marina. Based on iRO's maps, at least, I'd expect to find myself on top of a ship here - which seems to be missing entirely! Additionally, various cells in the map are unwalkable. So, I'm assuming there is some kind of mismatch between map data going on, maybe with respect to versions? Some googling suggested that it might be necessary to refresh the "map cache", though I'm not sure if that's really at the root of this problem and figured I should ask around before possibly going after a red herring. Not sure if this is in any way relevant, but I also noticed that during character creation, clicking on a hair style sometimes selects the wrong style. It sounds like that may require a NEMO patch for extended hair styles? So perhaps that's a different issue, but I figured I'd throw it out there. Much thanks for any advice.

Much thanks. Will look into that.

Hi all: I'm trying to figure out the least disruptive way to add a totally new attribute, one just like "name", "weight", and so on, to items. This would potentially apply to many of the items in the database, both equipment, usable and generic items, and have one of several values. A string-type variable would be ideal. I would like to be able to access this value from within scripts, and without disrupting anything else. It seems like one way to do this without much violence to the server code itself would be to create a pseudo bonus (i.e., there's no real status effect, it just acts as a label), enter that in as part of the item script, and check for the presence or absence of the bonus (https://github.com/rathena/rathena/wiki/Adding-New-Bonuses), maybe just the substring itself. But at the same time, that seems pretty hacky and not especially intuitive and could come with other disadvantages (and might not work for generic items?). Alternatively, is there any chance that this could be as simple as adding another nested key-value pair ("INREMsSpecialAttribute") to the YML entry for each item I want to modify? Would there be a supported way to retrieve that value through scripts, or would I need to add my own accessor function? Assuming it's a relevant concern, would doing this risk screwing up code that accesses item properties through arrays instead of by a dictionary and expects to find any values in a certain order? - Id: 1101 AegisName: Sword Name: Sword Type: Weapon SubType: 1hSword Buy: 100 Weight: 500 Attack: 25 Range: 1 Slots: 3 INREMsSpecialAttribute: Whatever Jobs: Alchemist: true Assassin: true Blacksmith: true Crusader: true Knight: true Merchant: true Novice: true Rogue: true SuperNovice: true Swordman: true Thief: true Locations: Right_Hand: true WeaponLevel: 1 EquipLevelMin: 2 Refineable: true Any advice would be appreciated. Thanks. Not sure if this is more of a "database support" question, a scripting question or a "source" question, but I figured I'll toss it out here first - if different subforum would be more appropriate, please let me know.

Really helpful info. Thanks.

Hi all: Reading through the documentation, I saw that rA (relatively) recently converted much of its db (notably item and monster skills) to YML format, with SQL as apparently a semi-legacy option for certain data. However, it seems like SQL may still be required for storing certain other info. What SQL files are minimally required to be imported at this point? If I'm interpreting the README in the sql-files folder correctly, it seems like you could get by with just the following: * main.sql - Contains tables for normal server usage. * roulette_default_data.sql - Contains data for the client's roulette game. * logs.sql - Contains tables for logging of server events. Also, how about the item_cash sql file? Assuming you want to implement the cash shop, is that a required import well? I see that the "import-tmpl" folder in the yml db folder has an associated cash shop file, but I wasn't sure if that is just meant to work with the sql file or can effectively replace it. Or to put it more generally: what SQL files are required to be imported if you want a fully-featured server? Also, if not strictly required, are there any SQL other files that are highly advisable to import due to performance issues? YML seems much more mod-friendly than SQL, so I would like to use it as far as is practical. Any advice would be appreciated. Thanks!