DeterminesOutputType cant determine type from soft bases

Development Pipeline & Plugins
, ,
1

When attempting to use a load asset blocking type node I observed that the type of the output pin seems to always be UObject. I traced the code down to this test in `FDynamicOutputHelper::GetPinClass`

```

bool const bIsClassOrObjectPin = (Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_Class || Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_Object);

```

https://github.com/EpicGames/UnrealEngine/blob/0ff6ecf5c809aaf24a7812ab1997c01e90027ee5/Engine/Source/Editor/BlueprintGraph/Private/K2Node\_CallFunction.cpp\#L310

Simply adding the soft variants like so

bool const bIsClassOrObjectPin = (
    Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_Class 
    || Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_SoftClass
    || Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_Object 
    || Pin->PinType.PinCategory == UEdGraphSchema_K2::PC_SoftObject);

Seems to correctly infer the type when connected to another pin

for example:

image.png.png
image.png.png940×202 34.6 KB

Is there a reason this shouldn’t be done?

Thanks,

Brian

2

Hey there, I’ve looked at this area before - there is a similar GitHub PR that regrettably I’ve let linger.

After implementing a change similar to the one you’re suggesting, we ran into problems in existing projects where the typed pin caused a load order problem. If I recall correctly, the typed pin resulted in a dependency that along with existing assets, resulted in a cyclical dependency. After encountering that in our internal projects, we at the time decided the possible fallout for other existing projects wasn’t worth the engine change.

Note that, I understand that most of the time you’ll put a Cast node right after there anyway. Feel free to make that engine change locally. This is a situation where we just chose to avoid risk of fallout in user projects.

3

Hey again!

I believe you’re right. The drop-down reference introducing a hard reference is the problematic part, while using a variable’s type doesn’t introduce a hard reference to the value, just the base class.

I think your change, which is identical to the PR, is safe to apply locally. Thanks for bringing this to light again. I’ll do more tests soon to try to get that PR in.

4

Thanks for the details.

5

Assuming this is the PR: https://github.com/EpicGames/UnrealEngine/pull/9602

I also ran into issues when trying to have it support the pinless version; here’s the internal writeup I did on why I chose to only support the attached pin flow:

> By implicitly casting the output pin for the sync and async loads I would be pinning the asset type in memory. This can result in accidentally having hard references to large object chains which aren’t expected.

> To work around that, I adjusted the logic to only implicitly cast if supplied with a value from a pin.

> The idea is that the type can the be controlled by setting the variable type, and that pins existence in the graph would already have a hard reference to the underlying type.