Catching the Unsummon "Event"

[Legacy_henesua]

                Has anyone come up with a solution that catches an unsummon event for an Animal Compaion or Familiar?

This would not have to be an actual event. I do not believe their is such a thing. But is there a reasonable way to determine when a companion or familiar is unsummoned?
               
               

               
            

[Legacy_Shadooow]

               heartbeat, either default.nss (not recommended), pseudo-hb or module hb
               
               

               
            

[Legacy_henesua]

               hmmm... I could use the companion's heartbeat, and have it notify its master on every heartbeat that it is still there.... The notification would be a timestamp.

Then I'd check for the timestamp in the PC loop in the module HB. That is possible.

If I can't come up a clever way to avoid knowing when a familiar is unsummoned, I'll consider this a fallback option.
               
               

               
            

[Legacy_Shadooow]

               why not pseudohb on a PC with associate in question as a parameter?

void CheckAssociateExist(object oAssociate)
{
 if(GetIsObjectValid(oAssociate))
  {
  DelayCommand(6.0,CheckAssociateExists(oAssociate));
  }
  else
  {
  //unsummoned, dispelled, dead
  }
}

               
               

               

                     Modifié par ShaDoOoW, 06 février 2012 - 05:58 .
                     
                  

            

[Legacy_henesua]

               A pseudo heartbeat is approximately 5 times less efficient than a regular heartbeat.

The creature's heartbeat runs only when it is summoned. And the module's heartbeat always runs.

So I figure the way I described above is nearly 5 more efficient in terms of processing.
               
               

               
            

[Legacy_Rolo Kipp]

               <scratching his head...>

I seem to remember something about unsummoning triggering an onExit event (trigger->area->module?).

If so, put a CheckIsSummoned() hook in there.

<...which is how he flips through the files>
               
               

               

                     Modifié par Rolo Kipp, 06 février 2012 - 08:32 .
                     
                  

            

[Legacy_henesua]

               Thanks, Rolo that makes sense, and would be more efficient than using a heartbeat. The trick is isolating the cause of AreaExit.
               
               

               
            

[Legacy_FunkySwerve]

               @henesua
You're absolutely right about the load (that's my guestimate of pseudo efficiency you're quoting). However, I'd still be tempted to do it as a pseudo as Shad suggests, only because you'd have to create a lot less redundant code - kind of a personal call, depending on how you weigh efficiency vs other considerations like duplicative code, modularity, and so on. Pseudoheartbeats are generally more reliable timing-wise than heartbeats, but that is a non-issue for creature heartbeats, as far as I've been able to tell.

That said, I wound up having to hook into every single onspawn (there are quite a few if you're talking about all the default bioware summons), instead of going from our central summoning include, when I wanted to trigger summon modifications, because you can't GetMaster during onspawn - you must have at least a 0.0 delay. So, either way is viable, depending on how you've set up your summoning scripts, and how many you're using.

@ R Kipp
It likely triggers the area onexit. If you have modulewide area onexits, you should be able to check if the exiting critter has a master, and if that masters GetAssociateType (fam, an comp, sum) == exiting object. Of course, that would require the creature to still be valid while it's exiting, but my suspicion is that it is.

Funky
               
               

               
            

[Legacy_henesua]

               Funky, yes, you and I have had that discussion before, and I did lean to the side of easier to manage code over that of efficiency. I've already got the framework setup to make it easy to use those heartbeats. I'd just be adding an if statement to the module heartbeat PC loop, and a Set timestamp statement in the creature heartbeat. The code running from those would be from an include.

So I think it is modular, and easy to manage. The code shouldn't be redundant beyond function calls, but the functions will be in an include and thus centrally located for bug testing etc...

Nevertheless I am still looking for a way to avoid this whole mess anyway. Perhaps I can limit some of the functionality that I am working on. Thats my first task: figuring out what I dont really need.

These are problems that I am attempting to solve:
Problem #1 is that I have enabled some familiars to carry one item (in their mouth or talons) BUT this item could be removed from the game if it is not dropped at their feet when they are unsummoned.
Problem #2 is that I am modifying the game behavior for the summoning of familiars and animal companions BUT it becomes a half-assed solution if I can't track them from summoning to unsummoning.
               
               

               

                     Modifié par henesua, 06 février 2012 - 10:08 .
                     
                  

            

[Legacy_the.gray.fox]

               

// This goes into an Area OnExit script.
// (did you know that this is also triggered by DestroyObject() ?)
void main ()
{
    object oExiting = GetExitingObject ();
    if (!GetHitDice (oExiting))
    {
        // No HD to query -> Could have been a Summoned Associate.
        // Edit: or any other Creature that has been removed from game.

        // (do stuff with oExiting here...)
    }
}

Actually none of the former creature traits are available for query once you get to GetExitingObject().
You only have its former OID to go by. If you held a register of summoned creatures, you could now compare this OID against the ones in the list, and from there retrieve the data you diligently saved when the associate was summoned. Otherwise this crude oExiting OID is not going to help you any.

This is trivial to do. Just keep a list of Creature properties you care about, and associate each set to a specific OID (the creature). No rocket science. But if you want ideas, you can look at my Multi-Summon system in Fox Spells. Start reading inside [fox_inc_summon], and from there the comments will point you to the other places of interest.


-fox
               
               

               

                     Modifié par the.gray.fox, 09 février 2012 - 03:48 .
                     
                  

            

[Legacy_henesua]

               I should check out your script.

But so far I've only been checking for the Summoned vs Unsummoned state. I'd prefer to catch this in a single event, but adding it to the PC loop in the mod HB appears to be lightweight so far.

This means that summoned familiars can provide skill bonuses to their masters. So far so good.