Additional Effect on Items

[Davenge]

This may be the wrong place to do this but I have a question.

Given that hard-coded items for additional effects makes me CRINGE. I'm looking to rewrite the additional effect system on weapons|items to make it more modular. I've already reworked a lot of the logic but I got to thinking, would it be better to script the logic instead of hardcoding? For example, like a lua call to onAdditionalEffect call for the item.lua in scripts/globals/items for each individual item or just having a mod flag like EFFECT_DEFENSE_DOWN, that runs logic for defense down on additional hit. Hardcoded leaves less flexibility... I also know there is already an additional effect in the item_weapon object but its not used. I dunno, like most code, there are ten different ways to write the same thing. Scripts, however, would be the most modular and flexible. Hardcoded item mods would be second best. And the options degrade there into hard-coding the very items themselves, which as I said, makes me feel sick. What would the project prefer in terms of submission?

Let me know, I'll write it.

[kjLotus]

i've had some ideas for additional effect stuff for a while, but i've never had time to do it

the project would prefer not hard coded things, because i hate them too

anyways, what i wanted to do was get in something that would a) fix the interactions between enspells, sambas and additional effects (ie. priority), b) allow those effects to work on all entities with an easy script call (say, mob:addAdditionalEffect(blahblah, ...)) and c) get something to easily add additional effects to items (which is what you're talking about)

i started to outline what my original idea was, and then halfway through i realized it sucked and deleted it. basically, if you're going to be doing (c), then it might be worth spending a bit of extra time doing (a) and (b). there's definitely a good argument though for script vs core - a script will be more versatile, but probably more taxing on the server. perhaps having the proc rate (and proc conditions) in the core (via some new db table, item_additional_effects or something) could be used to only load the script if it procs (as opposed to every attack)

the other option is a new class for additional effects, then we can do things like have a member for effect type (damage, status effect, drain), a member for proc chance (and another for proc type maybe, for those stupid goddamn battery/fan/pump weapons), a member for param (damage or status effect ID, depending on the type), then we can get rid of all those awful switch statements on enspell type at the same time. this way, you can add effects to anything through a simple call and things like sky gods/elementals additional effect could work

rambling done, here's what i'm thinking: item_additional_effects table - column itemid, effectType, procChance, (procType too maybe), param. itemid joined to item_weapon (or item_basic, whatever), effectType would be an enum of whatever order (would split the elemental damage types though, and make them easily decompose into the elemental numbers) , procchance just an int (maybe 0-1000, chance would be val/10), procType also an enum, and param is damage/status effect. then, item_weapon would have a struct (which is just all the members of the table i just mentioned), and populates that struct when items are loaded.

since the additional effects for enspells and sambas are character based and not weapon based, i'm not sure where i feel comfortable storing them - putting them on the weapon leaves oddities like unequipping weapons with an enspell active, i'll leave that one up to you (or myself if you don't feel like doing it i guess)

edit: also, not really the wrong place to ask - i love talking about implementation specifics (mostly because i have many ideas and no time)

[demolish]

throw in a group for gear set bonuses while you're at it :p

[Davenge]

This is where I'm at. If I go heavy core, faster and a bit less modularity/flexibility I'd add a new sql table or sorts like item_modifiers for item_affects. I would also create a new object(class) and have the item_weapon object's m_effect be a pointer to that class instead of an integer like it is now.

If I go heavier on the script side, I would just add an item_mod "additional_affect" and then if it say that and didn't already have an additional affect(ie drainsamba/enspell) it would fire a script related to that item and return proper damage values if needed. The actual mod value would be its chance to proc, so you wouldn't be calling a script every auto-attack with that weapon unless it proc'd which would take the load a decent amount of load off the server.

I'm leaning towards option two, why? It's lighter in the sense that I will have to add "less" to the core. It's more flexible, so if people wanted a specific item to have two additional effects(while only one animation/message can be shown, unless someone can show me how to send an action with no animation(0 is right-hand attack, 1 is left-hand attack, 2 is right-foot, etc)) they could. It allows for easier upgrades/tweaking/testing.

What are your thoughts? Again, the debate really is, as kjLotus said, script vs. core, will the load be significant on the server to do most of the logic via script?

[kjLotus]

will the load be significant on the server to do most of the logic via script?

can't say for sure, but i know what we can do: if you whip up a quick .patch that will have Mamushito (stun katana) call a script (to items/mamushito.lua) and we'll have whasf throw that on old school, and have every NIN on the server (including GMs) do dynamis with mamushitos equipped (and compare to not having it equipped)

up to you whether you want to have it call the script on proc or every auto attack (or both, and we can test both)

it's both educational and fun!

i'm leaning towards it being not too bad, especially since i cleaned up the lua stack shit a few months ago

[Davenge]

I'll whip something up this weekend. No spare time to code at the moment.

[kjLotus]

I'll whip something up this weekend. No spare time to code at the moment.

sweet

[Davenge]

Let the stress testing begin?
viewtopic.php?f=20&t=1643