We’re interested in providing ability parameterization in a way that doesn’t necessitate creating entirely new child assets to change the value of variables in a gameplay ability instance.
I’ve explored a nice potential solution to this in the form of following the same approach that FStateTreeReference exposes overridable parameterization from state trees.
[Image Removed]
In this case, I build a FInstancedPropertyBag from the parameters of the ability class that are exposed via CPF_ExposeOnSpawn. This allows those properties to rise up to visibility in the editor as shown above, in the ability data table we’re interested in tuning values within.
So far, this has been pretty easy, but to fully see this through, requires a couple more steps
- Replicate the overridden parameter property bag in FGameplayAbilitySpec
- Override UAbilitySystemComponent::CreateNewInstanceOfAbility, so that instances of the gameplay ability can apply the parameters to the instance from the spec property bag.
Not super complicated in theory, but it looks like maybe the property bag isn’t really set up to replicate, so that could throw a wrench into the process.
So the first question before I go much further.
- Is FInstancedPropertyBag replicatable?
- If not, how difficult would this be?
And secondly. Do you forsee any other problems with this approach?
Thanks
FInstancedPropertyBag is not currently supported in replication. There has been some work recently to investigate support. I know it was found that Seek and Find are not defined in the Serialize method currently. It was being investigated by our Networking team a few months ago, but I do not believe there has been any progress currently. One of the main concerns is that the PropertyBag could be different for client/server as there may be modules not loaded on one side that are used in the property bag.
I have seen a few CLs in review recently around serializing property bags, but I believe there are still some bugs happening in the system that caused one to be backed out. I do not think the default value serialization that was backed out has been re-submitted with needed fixes yet.
-James
With StructUtils moving to the core engine and showing up in more and more places, I imagine support will be added at some point. As for adding things to GAS, I will pass this along to their team as they will have much better answers than myself.
-James
Interesting. I hope support comes eventually. For the time being, I have something working in a temporary capacity. It’s not a full blown ‘serialize anything’ support for property bags, but more of an approach that is good enough for my use case, that takes into account the fact that I can generate the bag type definition on the client and server independently, and I can just use the GetValueSerializedString/SetValueSerializedString to push and pull the values out into a networkable string format that will suffice for the time being.
I rather like the idea of being able to parameterize abilities in this way. Is this something yall have ever considered?
Adding dynamic data support to ability activation is definitely on our to-do list. Right now, higher-priority work like bringing Blueprint functionality to attributes is taking the front seat.
As for whether dynamic data will be handled through property bags, that’s still undecided. We’re evaluating a few different approaches to figure out which one will provide the best experience for both beginners and more advanced users.