Announcement

Collapse
No announcement yet.

GameplayAbilities questions

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

    #46
    Thanks for this detailled answer.

    I clearly understand the process behind it and can understand the "specific" case of this module.

    The only things that can prevent me from use it, is the content "change" that will happen. As long as thoses changes can be driven in the editor, I'm fine with it (just a question of time), but if we need to update the serialize content so it can be loaded, that's another story. Can you just tell us a little bit on the type of impact?

    As for the documentation, due to the current state of this module, I'm not expecting a full documentation wiki page on this, but just the starting guideline to understand how you set a "basic" implementation.
    They are a lot of classes in this module and you are also using Tags to filter interaction of abilities. If you can provide us some guidelines, we may create a Wiki page that will merge all the different information (from the 2/3 other threads) in one place so we can start using it.

    Thanks,

    Comment


      #47
      One of the upcoming changes is a pretty low level change to attributes. Right now all attributes are floats. The new change adds a struct for attributes that games can customize. As an example, in Fortnite we're working on a game specific version with clamping information built into each attribute. I won't get into the details here but there are several advantages to using a struct for attributes.

      Because of how serialization works in UE4 if you change the type of a variable it won't be able to find the information when it tries to load the old data. In our case, changing attributes to structs means that the Attribute parameter inside FGameplayAttribute won't load correctly. We've made some changes to FGameplayAttribute that store some extra information when they're saved. We've also made changes to the loading code to use the extra information so it can find the correct UProperty at load time if it wasn't able to find it normally. Before changing existing attributes from floats to structs you would need to resave all of your data that contains FGameplayAttributes to make sure this extra info is there. We've already moved completely to struct based attributes on Fortnite and gone through this whole process with our data.

      For now structs and floats can both be used for attributes. At some point in the future we may drop support for float based attributes and require all attributes to use structs.

      Comment


        #48
        Hi,

        Thanks for the insight on this. I have some topics to close before I trying to use this module, so hopefully as 4.13 is planned for July, this will be released by this time .
        I completly understand the Struct approach and see how clamping can be very useful.

        Thanks for the time your take to give us a feedback on this.

        Comment


          #49
          I have a question regarding gameplay abilities and gameplay tags... namely - how do you use them? Not technically, I know how to use the code but... what are specific use-cases to using these two systems? What problems do they solve? Could you give some examples on how they're used internally?

          Comment


            #50
            Originally posted by DamirH View Post
            I have a question regarding gameplay abilities and gameplay tags... namely - how do you use them? Not technically, I know how to use the code but... what are specific use-cases to using these two systems? What problems do they solve? Could you give some examples on how they're used internally?
            I'm not an Epic dev, but hopefully I can answer that question:

            A simple example would be an ability that adds magic immunity to a unit. The ability would apply a gameplay effect to the target that has a duration and grants a MagicImmunity tag. Other abilities can then be blocked if this tag is present on the target.

            A more advanced example would be an ability that gives a target a gameplay effect that has a duration and grants an explosion ability. This ability can then be activated when the "OnFire" tag is applied. You now have an "oil" ability that can make things explode if they come in contact with fire (which could come from any number of sources, as long as they apply the OnFire tag).

            Tags are very useful for building your game in a systems manner, where you only need to worry about conceptual ideas once and it allows interactions to occur dynamically and organically.
            Last edited by mcucuzza; 08-13-2016, 04:39 PM.

            Comment


              #51
              So essentially a bunch of shared, "floating" booleans... hmmm.... come to think of it I just recently set up an "EnvironmentInteraction" system that is an interface and uses a bit mask with which objects can define which environment effects they interact with (burning, freezing etc).

              Thanks a lot this is useful info.

              Comment


                #52
                I remember also that tag have hierarchy also. like A.B.C and you can match A or B or C or A.B.C or A.B depanding of your requirement.
                It's really powerfull once you learn and master this.
                Like this module, it's a excellent things with replication,effects, gameplay effects etc.. but you need learn & master to be proficient while using it. It also request a bit of setup.

                I think now there is also a Tag Editor available.

                Comment


                  #53
                  Are AttributeSets meant to be blueprintable? If I create a blueprint that inherits from AttributeSet, the attributes/variables (Floats or AttributeData struct) never show in the GameplayEffect lists. If I create the set in C++, it works perfectly. Is this just a 4.13 bug, not implemented yet or?

                  Also, with these attributes, their initial values are set via AttributeMetaData right? They're not meant to be set in a constructor for example, even the new AttributeData structs. Just want to be sure. Lastly, currently you can't create these variables in the UE4 editor unlike tags, it requires a CSV. That's fine, since a CSV is basically better anyway, but its something we probably be able to do anyway.

                  This system looks amazing, literally everything I've been trying to do in the past two weeks is here, and its better to an order of magnitude.

                  Comment


                    #54
                    How do I add a ActivationRequired tag to an Ability that I'm adding to a given actor? I want to give my weapons an "Equipped" ActivationRequired tag, but I don't particularly care if the same ability is given to a Character since I have the Owner and Avatar set up correctly. I can't seem to find a way to get around the non-instancedness of the activation requirements without writing a custom Ability class.

                    Comment


                      #55
                      Hello. I have a question about implementing shield effects that absorb damage. What is the current idea behind implementing shield effects?
                      We have custom UGameplayEffectExecutionCalculation for damage processing but cannot figure out how to update ongoing shield effects to properly substract absorbed damage value from shield absorbption left on ongoing shield effects, especially if we have more then one shield running on target.

                      In 4.5 version there were UGameplayEffectExtension classes and you could make effects that update ongoing effects, but we cannot figure out current way of doing it.

                      Comment


                        #56
                        Some info for 4.15:

                        1) GameplayAbilities is now a plugin. Make sure you add this to your plugin list of your .uproject.

                        2) There seems to be an issue with GameplayCueNotify_Static - if a PlaySoundAtLocation node is in the blueprint, it will hang the editor indefinitely if you try to open the cue before either pressing the play button or opening the Cue editor window.
                        There is a workaround I found to fix this for now, which is to add the following code to your module startup:

                        Code:
                        	UGameplayCueManager* CueManager = UAbilitySystemGlobals::Get().GetGameplayCueManager();
                        	CueManager->InitializeEditorObjectLibrary();

                        Comment


                          #57
                          Originally posted by FredK View Post
                          Effects with an instant duration make permanent changes to the attribute values. You can think of periodic effects as a way to repeatedly execute instant effects. The modifiers aren't outliving the effect, the actual attribute value has changed.
                          Is this still true with `FGameplayAttributeData` now being implemented? As far as I understand, the modifiers of GameplayEffects are collected within Aggregators (channels + modifiers in `FAggregator`), which are eventually applied to `FGameplayAttributeData::CurrentValue`. If modifiers are removed from the aggregator (when a GameplayEffect is removed or off), they are also removed from the CurrentValue of the attribute? So there are no modifiers which outlive the effect and permanently change the attribute value? Or do instant GameplayEffects change `FGameplayAttributeData::BaseValue` and don't use aggregators?

                          EDIT: My assumption was wrong/the last assumption was correct! Yes, some modifier are collected within Aggregators, which indeed only change `FGameplayAttributeData::CurrentValue`. However, this is true only for "temporary" GameplayEffect (DurationPolicy "HasDuration" and "Infinite" without Period). Instant and duration/infinite+period GameplayEffects change `FGameplayAttributeData::BaseValue`.
                          Last edited by Roi Danton; 10-23-2018, 05:29 PM. Reason: Corrected myself.
                          Client side prediction with GameplayAbilitySystem | GameplayAbilitySystem at stackoverflow

                          Comment


                            #58
                            Originally posted by FredK View Post
                            As an example, in Fortnite we're working on a game specific version with clamping information built into each attribute.
                            I've also added an additional baseValue, which will only be initialized, but never changed by a GameplayEffect and only used for calculations. I achieved that with a custom attribute initter and simple Getter/Setter on the AttributeSet (so the value can be accessed by custom calculations).

                            I also plan to include clamping in the attribute. When doing custom clamping for Fortnite, have you been able to do everything within AttributeSet or did you have to modify the GameplayEffect, too?
                            Client side prediction with GameplayAbilitySystem | GameplayAbilitySystem at stackoverflow

                            Comment


                              #59
                              Originally posted by FredK View Post
                              There are a few reasons why we don't want to instance gameplay effects. Gameplay effects in this system are intended to be data only. The only reason they are blueprints is for inheritance. The event graphs were never intended to be used and we have no plans to support event graphs running inside gameplay effects.

                              Instancing gameplay effects would have performance implications. One of the biggest considerations here is networking and replication. Replicating that many objects would be a bad idea.

                              If you need to use an event graph in this system you should do it at the ability level, not the effect level. Abilities can be instanced and support multiple options for how they are instanced.
                              It is a bad design, the ability level will contain much logic if there are many game effects in an ability. If game effect A trigger game effect B, then game effect B trigger game effect C ... the ability will couple with game effect A, B, C... ,it will cause a very big ability, the ability will be hard to maintain and the logic for game effect is not reusable.

                              Comment

                              Working...
                              X