Announcement

Collapse
No announcement yet.

FScopedGameplayCueSendContext GameplayCueManager

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

    FScopedGameplayCueSendContext GameplayCueManager

    So digging through ways to reduce the number of multicasts for weapon shots, i came across FScopedGameplayCueSendContext. Now the issue i see with this, is it doesn't actually reduce the nuumber of rpc's, just sends all the rpc's in a single frame. I wouldn't really call this batching as its still around 5 multicast rpc's per shot!

    I know from my other post, Dave Ratti mentioned they batch the gameplay cues for weapons, but i am really struggling on how that is possible, cause this doesn't seem to do any batching. If i do need to override some stuff to handle batching, what would be the way to do it to ensure the paths are correct?

    Thanks
    Kaos.
    Game Programmer - Working for a Indie Studio.

    Visit my blog: TheGamesDev

    InterKaos Games

    PC Specs:

    #2
    Slight bump, anyone have an ideas?
    Game Programmer - Working for a Indie Studio.

    Visit my blog: TheGamesDev

    InterKaos Games

    PC Specs:

    Comment


      #3
      The idea behind FScopedGameplayCueSendContext is that you override UGameplayCueManager::FlushPendingCues in a subclass. FlushPendingCUes will be supressed until after the batch scope and then you can merge whatever is in your LocalPendingExecuteCues list into a smaller set of cues or call custom made RPCs to effeciently replicate your bad cases.

      A simple example would be like a shotgun. If you implemented a shotgun where it did 5 distinct traces and impacts, you could merge those into one gameplay cue event. Maybe you effeciently encode the hit locations or maybe you give it a random seed number to recreate/approximate the impact locations on the receiving side. Kind of up to you there.

      Fortnite's implementation gets a little trickier where we batch both the source and target GCs into one RPC call. For example the source GCs are the weapon firing (muzzle flash, trace) and the target GCs are like the impact effect, damage numbers, crit indicator, etc. It gets more complicated here because we are essentially replicating these two sets in one call through the shooter, and unpacking them on the receiving side, turning them back into two sets of GCs (the set that is called on the shooter, the set that is called on the target) and then invoking them on the ASC's like normal. A bit more work but its roughly the same idea.

      This is all non generic. Basically, looking for specific tags and being like "we can merge these together into some smaller data set". Kind of stinks, I wish the system generically merged things in but its just not really setup in a great way to do that.

      Comment


        #4
        Thanks dave, makes sense now
        Game Programmer - Working for a Indie Studio.

        Visit my blog: TheGamesDev

        InterKaos Games

        PC Specs:

        Comment

        Working...
        X