Why the heck is IGameplayTagAssetInterface NOT exposed to Blueprints...

General Feedback & Requests
1

So, call me crazy. But I have these three awesome nodes:

Yet, I can’t use them…because…

Yo… CannotImplementInterfaceInBlueprint

Obviously, I can just create my own actor parent class and use the darn interface and expose that to Blueprints… But… what is the reasoning behind NOT allowing us to do it from BP? Why even have the other nodes available then.

Unless there’s something I am missing completely from the Gameplay Tags workflow. Yes, I know there are other ways to query Gameplay Tags. But, I want Gameplay Tags in EVERY actor I use basically. So I want my parent actor class to get the interface so that I can make this system work like it should.

Actually, this is sort of bugging me that not every Actor Class has a Gameplay Tag or Container by default either. I mean we have Actor Tags/Component Tags (which I don’t see the purpose behind those anymore with this)

Anyway… last pic:


← nani ???

2

I would badly want to have the interface in my blueprint Project too. Tryed making same name interface with same functions, but EQS gameplay cant still communicate with the actors to check values. Would make EQS nicely more handy to use. But will need to try adding task after eqs to do that same check for all returned locations.

https://answers.unrealengine.com/questions/750036/does-blueprints-support-gameplay-tags-yet.html

3

You need to have your BP Actor inherit from a C++ Actor with:


#include "GameplayTagAssetInterface.h"
class AFooCharacter : public ACharacter, public IGameplayTagAssetInterface

and add


UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "GameplayTags")
FGameplayTagContainer GameplayTags;

virtual void GetOwnedGameplayTags(FGameplayTagContainer& TagContainer) const override { TagContainer = GameplayTags; return; }

also extend your build.cs:


PublicDependencyModuleNames.AddRange(new string]{ "Core", ....,  "**GameplayTags**" });
4 Likes
4

It’s probably not exposed because it’s faster and allows you to make assumptions in code - the same way the Gameplay Abilities Interface isn’t exposed to BP either.

You can cast directly to an interface so long as it is implemented in C++, but you can’t if it’s implemented in Blueprint - instead you have to follow a much slower path. You can also do more with non-blueprintable interfaces than blueprintable ones.

It could be an oversight, but sometimes you have to sacrifice a little flexibility with Blueprint for the best implementation.

5

TheJamsh, it still doesn’t make sense to provide a blueprint node which is not working, does it?

6

Well seeing how we’re able to expose it ourselves…it makes no sense to just not have it exposed by default is what I was getting at in the first place with all this.

7

Yeah that is like hanging the cookie jar from the ceiling and watching the little kid hopelessly jump around trying to reach it.

8

The nodes work just fine. The interface that they work with just has to be implemented in a C++ class rather than a Blueprint class.

As I mentioned above, exposing it means you can’t do native Casts in C++ to the interface, and have to follow a slower path. Obviously in this case, it was deemed to be too costly to follow the slower path where this interface is used. If it’s C++ only, you can do this:



IGameplayTagAssetInterface* AsInterface = Cast<IGameplayTagAssetInterface>(SomeObject);
AsInterface->InterfaceFunction();

If the interface can be implemented in Blueprint, C++ code needs to be adapted for that. It’s extremely clunky and slow to access blueprint interfaces in code - so most of the time they aren’t exposed.

You can expose it - but any code that relies on a native cast will also break when the interface is implemented in Blueprint, because the cast will fail.

TL;DR, Blueprint-Implementable Interfaces are slow.

9

Necro, but they should have also supplied a node to get the container from an actor so you can call add and remove tags from outside that actor. Instead I have to extend the interface or make a new one just for that one dumb thing.