Precastcheck function

By Exxcentric on February 2, 2011 1:26:08 AM from

Demigod Forums

Exxcentric

Join Date 07/2009

+47

Hi mithy,

i have written a new abilitytask.lua that will let you use a "precastcheck" like function to analyse all ability information before casting. Before it was limited to checking yourself (it was only for minion code) but i have modified it for eviction to allow me to analyse target buffs.

http://pastebin.com/pe34YW62

i was wondering if you had a method to make this less destructive (although it is not too bad now, i cannot make it so that the rest of the State {} function is repasted in BeginCastState{}

If you have the time can you check it out? it works as is but i just wanted to see if there was a less destructive method.

Cheers exx

I don't think you need to do that at all?

Look at this line, present in the original:

Code: c++
self.Unit.Callbacks.OnAbilityBeginCast:Call( self, self.Unit )

This runs any callback functions of this type added to the casting unit every time casting starts. Since it passes 'self' (the AbilityTask itself in this case), you should be able to access self.Target from within this callback.

So, to use this, you need to add a callback function to the unit whenever the Eviction ability is on the unit, and remove it when the Eviction ability is removed. Here's some prototype code that you should be able to get working with some testing:

Code: c++
--Add to the Eviction item's actual ability blueprint
EvictionTime = 120,
OnAbilityAdded = function(self, unit)
    unit.Callbacks.OnAbilityBeginCast:Add(self.EvictionCheck, self)
end,
OnRemoveAbility = function(self, unit)
    unit.Callbacks.OnAbilityBeginCast:Remove(self.EvictionCheck)
end,
--This function gets its first param from the above Add() (the ability def), and the second two params from its Call()
--in AbilityTask.BeginCastState.OnEnterState (which are self and self.Unit, self being the AbilityTask)
EvictionCheck = function(abilDef, abilTask, caster)
    --Make sure the ability task in question is eviction; abilDef will always be eviction's blueprint, but abilTask
    --will not always be an eviction cast (it's triggered for all ability casts while this callback is on the unit
    if abilTask.AbilityName == abilDef.Name and abilTask.Target then
        --Looks for an EvictionTime var on the target unit - set this using GetGameTimeSeconds() upon successful cast
        local targetEvicted = abilTask.Target.EvictionTime
        if targetEvicted and GetGameTimeSeconds() - targetEvicted < abilDef.EvictionTime then
            abilTask:AbortCast()
        end
    end
end,

The game's callback add/remove system is a little confusing, because if the Add() call specifies a second parameter, that becomes the first parameter to a Call() of that callback. If you want to be more/less confused, look at the Add/Remove/Call functions in /lua/system/Callback.lua.

Regardless, this should work fine, because it can get a handle to the target via the abilityTask passed to it, and then issue an AbortCast() directly to the abilityTask if the target matches conditions. I just put some dummy conditions in using GetGameTimeSeconds so it would make sense while I was writing it - just replace that with however you're already doing has-been-evicted-detection.

Successfully updated karma reason!

Nevertheless, in the future, if you want to hook a State, you do it just like you would the Class it belongs to (a State is essentially a sub-Class). FA's state system had some quirks that sometimes made hooks of them not quite work how you would expect, but I'll take a shot at translating your original code just in case they fixed that in Demigod (plus something this simple would probably work just fine):

Code: c++
local prevClass = AbilityTask
AbilityTask = Class(prevClass) {
    BeginCastState = State(prevClass.BeginCastState) {
        OnEnterState = function(self)
            if self.Ability.PreCastCheck then
                # do we have any check that may prevent this ability from launching
                if not self.Ability:PreCastCheck(self.Unit) then
                    self.KillTask = true
                    return
                end
            end
            prevClass.BeginCastState.OnEnterState(self)
        end,
    },
}

Successfully updated karma reason!

k ty mithy.

"I don't think you need to do that at all?"

i am positive that you need to do it (from the method i was using), i spent 4 hours trying to get the precast check function to recognise the target entity but it wouldnt no matter how i did it (params.Targets[1], target, self.Target etc). Each would only give me a nil value. Upon adding (self, self.Target, self.Ability) to the function it ran straight away.

Although i didnt use a callback i was trying to reference it from the precastcheck function itself.

1+ for being so awesomely helpful .

Successfully updated karma reason!

ok i took your fixed hook in abilitytask.lua and am going to use that for the moment so that i have a simple method of using a precastcheck/kill:task method

it works great:

i was missing this when i tried to do it

BeginCastState = State(prevClass.BeginCastState) {

Ty again!

Successfully updated karma reason!

Did you even try the callback method? I assure you it will work, as it has the actual AbilityTask as one of its parameters. It's also the way this kind of thing is supposed to be done, and while it's confusing at first, once you learn how callbacks work you can do a ton of stuff with them that would otherwise require re-writes of tons of base code.

The original pre-cast check function never has the AbilityTask object itself passed to it, only the casting unit and the ability blueprint. 'self' in the pre-cast check is the ability blueprint, not the AbilityTask object, which is why you couldn't get a target from it.

Successfully updated karma reason!

yere i understand that, however, if i was to use the callback strategy it would require me to rewrite all my effects code (which currently just hijacks the buff timer and is activated by the buff itself) and so at this point it is easier for me to use the altered ability task.lua. Also now that this has been changed i can use it for all the precast checks, as it does not require much extra code.

IMO the precast check should have always had access to this data (i dont really understand why you would want a precast check that only allows you to check yourself) so i figure it is kinda of a system update .

I have used callbacks before but i find that they tend to cause alot of problems (like ub code -- this uses alot of them) as if they were added as an afterthought. Nevertheless, when i get some time i might look into them and get more familiar with them.

Successfully updated karma reason!

This shouldn't cause any problems, and like I said, you could pretty much just paste your version of the pre-cast function in and change the parameter references, but w/e.

Successfully updated karma reason!

The Forums Are Now Closed!

The content will remain as a historical reference, thank you.

Precastcheck function

Exxcentric