Alternatives for making non-transient wrapped Python types

Development Pipeline & Plugins
, ,
1

`import unreal

@unreal.ustruct()
class MyPyStruct(unreal.StructBase):
number = unreal.uproperty(int)

the BPFL way not being supported offically

@unreal.uclass()
class MyPyClass(unreal.BlueprintFunctionLibrary):
[Content removed] params = [MyPyStruct])
def MyTestFunc(s: MyPyStruct):
return 1.0`Hi,

There were already many questions regarding this, but if possible, I would like to update my information about the transient properties of Python types.

Like many developers, we hope to expose Python-defined functions as blueprint nodes, with a fast iteration utility while extending the Unreal Editor.

Although this extending method isn’t supported officially in the Python scripting documentation, with the feature’s expected usability, we’re still investigating whether alternatives are possible.

The main trouble is that all type instances like UClass defined in Python scripts, and the outer package are marked as transient. Therefore, an exposed Python function cannot be serialized into the asset and is broken when restarting the editor.

For this issue, I have questions:

1) I wonder if these transient flags cannot be safely removed even by modifying the script execution order and re-instancing types.

2) When looking at the history in Perforce, all transient flags are added through the CL 4885914.

The message said that the fixes were for handling the type generation error correctly, but I wonder if the transient flags are still related to the problem.

Additionally, is it related to the UE-69409 issue the changelist is pointing to?

3) Are there recommendations or tips for making the wrapped Python types non-transient?

It would be appreciated if any helpful information could be provided.

Thanks,

Hyeongcheol

2

Hi,

As you discovered, this is not supported. As the code owner often says: ‘We have been telling people it wasn’t supported, but they likes it and keep doing it, shooting themselves in the foot, so it’s on them’. But I’ll try to answers your questions:

1) I wonder if these transient flags cannot be safely removed even by modifying the script execution order and re-instancing types.

  • By design, all Python generated types are transient, mainly as the asset can load before the type has been re-generated by Python. When the Unreal asset loader sees that an asset is referencing some Python generated code, it can’t resolve that dependency if the script hasn’t run and so the reference is nulled. Basically everyone who has tried to do this has ended up with it eventually breaking due to some subtle change in asset or script order, which ends up taking time to support/diagnose/fix (as it’s not supposed to work at all). The “Execute Python Script” solution is safe because it executes literal Python script from BP, including importing any dependencies that are required by that Python script. That means it’s not reliant on the script having run before the BP loads, as it’s the BP that runs the script.
  • In theory, if you can guarantee that the Python code is run before BP, it might work… but we don’t test that and UE as so many subtle workflows and implementation details that it will probably break in some conditions. Also, we constantly optimize/parallelize the loading code, so you may rely in some initialization order that will eventually change.

2) When looking at the history in Perforce, all transient flags are added through the CL 4885914.

  • This was in UE 4.22... early support of Python. Transient flag could still be related to this issue, it is hard to tell without experimenting.

3) Are there recommendations or tips for making the wrapped Python types non-transient?

  • 1- Don’t do it!
  • 2- Don’t do it! Find a way to use ‘Execute Python Script’ node instead.
  • 3- If you persist and do it, ensure you can debug and fix the bugs and the side effects because this not supported and the developer will just say: Sorry, it’s not supported.

Regards,

Patrick

3

Hi Patrick,

Sorry for the late reply. Consequently, we decided to find an alternative following the safe and recommended method as mentioned.

Thank you for the detailed explanation and recommendations, which helped us consider how to balance cost and usability.

Regards,

Hyeongcheol