Just to clarify, it’s DefaultEngine.ini that you need to add the information to. As well, I think someone else mentioned this, make sure you don’t include the quotes around the name.
So I’ve got the abilities system up and running (woot!). I do have one question though.
In the properties for the “ability system component”, you can specifiy the attribute set and data table to use. After setting this up, I noticed my attributes weren’t actually being initialized with the values from the table.
Upon investigation, it looks like the UAttributeSet::InitFromMetaDataTable() function is the culprit. When requesting a row from the table it is passing in a fully qualified name like “MyCharacterAttributeSet.MaxHealth”, rather than just “MaxHealth”.
It’s easy enough for me to change the code to fix this, but I wanted to check if this is actually the intended behavior. i.e. Should each row in the table actually have a fully qualified name?
I can’t think of a good reason for this, but I might be missing something. 
Thanks for any info you can provide!
Shawn
Been a while since this thread has been active, but I have a new question that I’m sure others would find useful as well.
- How would you approach something like a temporary buff that gives immunity to all types of damage except for one? Can this be done purely with simple modifiers and tags, or is this an area that would require custom execution classes?
- Would it be possible for you guys to post a sample custom execution class, to familiarize us with the general how-to for these.
@,
Litlle bump on this as 4.12 just went out and nothing have changed in source code since 6 months. Is it stable and ready to use? Any starting doc planned?
Thanks,
This post is a bit long so feel free to skip to the last two paragraphs if you just want the answers to Elvince’s questions.
The ability system is in a fairly unique situation in UE4. Most features in the engine are actively developed by the engine team. The ability system was created as a shared project between two of our game teams. It’s currently still owned by the game teams so development is heavily driven by their needs and schedules. The upside to this is that any changes we do make are to address real issues that we’ve run into while we use the system. The downside is that we have to prioritize making these changes with other game work. This has a few consequences for how changes make it into engine releases. First, there may be things that we want to change but haven’t been able to because of competing priorities. This means that development on the ability system happens in fits and starts. This is a general game development problem and not specific to the ability system. There are always things to work on and not everything can be top priority. Second, when we make changes they are made directly in our game branches. At first, the only people affected by the change are the game team that needed the change. Once a change has been made and we’ve dealt with any initial fallout the change will get merged back into the engine branch were it will be available to all of our internal teams and get put into a future engine release. This does add some lag between making changes and releasing them but it also means that we’re more confident about the changes when they are released.
That’s my long-winded way of saying that even though nothing has changed in the engine in 6 months it doesn’t mean that changes aren’t coming. I know of a couple changes that are in progress and may make it into the engine in a release or two. I don’t want to give a timeline on these because they may need to be modified. One of them is still pretty experimental and may not pan out. There’s also a proposed future change that would require some work from users of the ability system to keep things running smoothly. We try to avoid making changes that break existing functionality or content when we can. Our own games are probably the heaviest users of the ability system at this point so when we do make that kind of change there has to be a really good reason for it.
Any starting doc planned? I don’t know what our documentation team’s priorities are so I can’t say when we’ll have a starting doc or other learning resources.
Is it ready to use? We’ve been using it internally on multiple projects for a while now. I also know of a few external developers currently using it. I’d say it’s still in a “use at your own risk” state. Given the lack of documentation and possibility of future changes I wouldn’t recommend it for inexperienced developers. Very small teams should also think carefully before deciding to use it. We do try to avoid changes that break existing code and content but we may run into issues that force us to do it to fix them. Like I mentioned, there is a proposed change that would require some work by teams using the system. We really do try to minimize these because they also impact us but it is a risk. Having one person spend time updating code or content has more impact on very small teams than it does on larger teams.
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,
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.
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.
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.
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.
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.
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.
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.
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.
Some info for 4.15:
-
GameplayAbilities is now a plugin. Make sure you add this to your plugin list of your .uproject.
-
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:
UGameplayCueManager* CueManager = UAbilitySystemGlobals::Get().GetGameplayCueManager();
CueManager->InitializeEditorObjectLibrary();
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.
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?
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.