Announcement

Collapse

The Infinity Blade Forums Have Moved

We've launched brand new Infinity Blade forums with improved features and revamped layout. We've also included a complete archive of the previous posts. Come check out the new Infinity Blade forums.
See more
See less

Accessing Kill event (Killer, weapon) from a mutator standpoint?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Accessing Kill event (Killer, weapon) from a mutator standpoint?

    Is there anyway to access the killer and killer's weapon from a mutator, without going and creating a new gametype to subclass the Killed() method?

    I think I'll have to create a new gametype in the end anyway, so it's not a big deal if it's not possible without doing so.

    Essentially, all I need is in the chat log, so it seems like the mutator should have access to the information, but I'm not very familiar with the code, and a few hours of poring over it hasn't been enough to find this tidbit.

    Thanks!

  • #2
    I needed to do the same thing but I had already created a gametype for other reasons so thats where I did it. I needed to make my own PlayerController class as well so that I could restore the translocator/TransDisc "camera view" - I couldn't find any other way to do it (elegantly, at least - I needed "ToggleTranslocator()" to do other things).

    Seems you may have to make a gametype as well.

    Depending on what you want to in your own Killed() - there may be another way to accomplish your goal. You may be able to use NetDamage() in a Mutator -- You could create your own Pawn or Controller classes (NotifyKilled(), KilledBy(), etc...)

    If you are overriding a Pawn or PlayerController classes, then I think you can build a Mutator to replace the game's class with your own class (CheckReplacement()) - I think...

    Good Luck!

    Comment


    • #3
      Use your mutator to add a GameRules. Unfortunately the ScoreKill function doesn't give the DamageType, but you can work it out by recording the previous call to PreventDeath.

      Comment


      • #4
        The plan is to keep a secondary counter based on a player's kill with a specific weapon.

        Thanks for the tip about GameRules.

        ScoreKill in combination with PreventDeath looks very promising, but it seems like there's a race condition in simply recording the previous iteration in a global.

        Code:
        bool PreventDeath(...Controller Killer, class<DamageType> damageType...)
        PreventDeath contains both of the tidbits I need, but of course there's always the possibility of another mutator returning 'true' for some reason, resulting in an incorrect count as I increment my counter for a death that never happens.

        A possible solution is forcing my mut to go last...

        Code:
        while(/*GameRules linked list isn't at the end*/)
        {
            if(next.PreventDeath() == true)
                return true;
            advance iterator
        }
        // logic
        But then of course, conflicts spring up between other muts who might want to do the same thing, and these semantics don't really guarantee anything, considering that.



        I guess my question is this:

        Is simply recording the last value of PreventDeath enough? I see no guarantees that the flow of execution will always look like:


        Code:
        PreventDeath(x);
        ScoreKill(x);
        PreventDeath(y);
        ScoreKill(y);
        rather than:

        Code:
        PreventDeath(x);
        PreventDeath(y);
        ScoreKill(x)
        ScoreKill(y);
        It may be a minor rare bug, depending on the delay between PreventDeath's execution being finished and ScoreKill's call, and not occur often, or even at all, but it seems a tad dodgy.

        Comment


        • #5
          If the functions are called in the order :

          PreventDeath(x)
          PreventDeath(x)
          ScoreKill(x)
          ScoreKill(x)

          You could still work by storing the data to be processed in an array, and then processing the array data in ScoreKill(x).

          Pseudo code:

          Code:
          struct DeathInfo {
             var Controller Killer,
             var class<DamageType> damageType
          };
          
          var array<DeathInfo> deathInfoArray;
          
          bool PreventDeath(Controller Killer, class<DamageType> damageType) {
              local var DeathInfo di;
          
              di.Killer = Killer;
              di.damageType = damageType;
          
              // Add new DeathInfo to end of array.
              deathInfoArray.add(di);
          }
          
          function ScoreKill(x) {
              local var DeathInfo di;
          
              if (deathInfoArray.size() > 0) {
                  // Get the first element in the array - maintains correct order of processing.
                  di = deathInfoArray.get(0);
          
                  // Process the DeathInfo here....
          
                  // Remove the info we just processed.
                  deathInfoArray.remove(0);
              }
          }
          Not sure at all about the syntax, but you get the idea.

          Using that method, it doesn't matter when you get ScoreKill() method calls, as long as they are always paired with a matching PreventDeath() call.

          Comment


          • #6
            It's at times like this I wish there were a hashtable construct, since we should probably only keep the most recent prevent death for any one given actor, as any other mutators can 'cancel' the death. I suppose I'll implement that too.

            Another thing for me to be wary of is the case where:

            Code:
            PreventDeath(x);
            PreventDeath(y);
            ScoreKill(y)
            ScoreKill(x);
            which wouldn't like that psuedocode, if I understand it correctly. Still, thanks for pointing out that I can use an array here. I feel a little foolish for not seeing it.

            I think I actually have to look through the array to find the corresponding DeathInfo for that particular actor's death.

            Sometime in the near future, I'll actually go buy the game, so I can cook the code I'm writing and give it a whirl. Sadly, my current computer can't play the game, but that doesn't mean I can't have a good time coding for it.

            Comment


            • #7
              There will be no other PreventDeath calls between a PreventDeath and its corresponding ScoreKill call. (That is, unless you for some reason kill a player while processing another player's death, which for recursion limit reasons is not recommended at all. For a case like this you only need a stack-like list, though.)
              There just may be a chance for the corresponding ScoreKill to not be called at all.

              Comment


              • #8
                Thanks Wormbo, that makes it a whole lot simpler.

                Comment

                Working...
                X