Additional Effect via Scripting

[Davenge]

Okay, here it is. We discussed a few ways to attack this. It would be super dynamic if every weapon called additional effect every time but due to potential drains on the server, this is what I came up with.

Here's a bit of an explanation: I created a modifier for if an item has an additional effect or not. That mod is 411 and its value is its % chance to proc. So add the 411, along with its chance to proc to an item_mod for the item you want to have an additional effect in the item_mod.sql will make it "work." Next, on autoattacks, the code runs a rand and against your % chance to proc and if successful runs a lua call onAdditionalEffect for the item in scripts/global/items/item_name.lua. (Also, onEffectGains and onEffectLose are handled in this same .lua)

What works:
- As this is sort of testing, I didn't incorporate this into ammo yet, but could easily be done. It is called after enspells and if there are no enspells or drain sambas(which I believe is retail) it checks for additional effects.
- Animations should all work but only tested defense down
- The effects should be going on the mobs, no problem. I'm getting successful wear-off mobs and debug messages

What doesn't work:
- Ammo? Already mentioned that though.
- Obviously for damage stuff, damage math functions will need to be added somewhere especially for ammo as they follow a specific damage logic

Here's an example script.

Code: Select all

-----------------------------------------
-- ID: 17605
-- Item: Acid Dagger
-- Additional Effect: Weakens Defense
-----------------------------------------
-- Lowers Target Defense by 12%
-----------------------------------------
package.loaded["scripts/globals/status"] = nil;
require("scripts/globals/status");

-- return subeffect animation(status.lua), message id(documention/message.log), param(number for damage or effect from status.lua)

-----------------------------------
-- onAdditionalEffect Action
-----------------------------------
function onAdditionalEffect(player,target)
   if( target:hasStatusEffect(EFFECT_DEFENSE_DOWN) == true ) then -- for testing purposes so we don't get spammed with repeating data and animations
      return 0,0,0;
   else
      target:addStatusEffect(EFFECT_DEFENSE_DOWN,12,0,60,17605);
      return SUBEFFECT_DEFENSE_DOWN,160,EFFECT_DEFENSE_DOWN;
   end
end;

-----------------------------------
-- onEffectGain Action
-----------------------------------

function onEffectGain(target,effect)
        target:addMod(MOD_DEFP, -12);
end;

-----------------------------------------
-- onEffectLose Action
-----------------------------------------

function onEffectLose(target,effect)
        target:delMod(MOD_DEFP, -12);
end;

Again, I ran into the problem of putting files in my patch that aren't part of the svn...

http://wiki.ffxiclopedia.org/wiki/Additional_Effect -- List of Items that will need .lua scripts for onAdditionalEffect

[kjLotus]

It is called after enspells and if there are no enspells or drain sambas(which I believe is retail)

the retail order is enspells > add. effect proc > sambas, but other than that, i'll try to get whasf to put it on one of the servers


(wrote this post and forgot to submit it before leaving all day)

[Davenge]

ah, well, nothing a quick fix can't resolve on the finished product. Once the load testing is out of the way. I will put together a real polished version with calls for ranged attacks as well.

[whasf]

Compiler doesn't like this:

Code: Select all

Action->additionalEffect = (SUBEFFECT)lua_tonumber(LuaHandle,-3);

Error 1 error C2440: 'type cast' : cannot convert from 'lua_Number' to 'SUBEFFECT' f:\vsprojects\onetimexi\src\map\lua\luautils.cpp 1490

[Davenge]

huh... I'll take a look, compiles on mine.

[Davenge]

It's a bit janky but that should fix it...

[kjLotus]

finally had some time to work on this between exams, taking what you've done and extending it to enspells and sambas as well so once that's done we're golden (and i can find minions to script everything)

[link]

This looks excellent. Hopefully we can unclutter the core in the near future.

[maxtherabbit]

wouldn't keeping the additional effects in the core reduce server side load?

I'm not opposed to scripting them I just don't completely understand the motivation

[kjLotus]

wouldn't keeping the additional effects in the core reduce server side load?

unlikely that it'll really make much of a difference

think the only bottlenecks that are really noticeable are sending packets to clients in populated areas (dynamis)