At work we are currently investigating how we could add a reasonably sane optional type for blueprint.

We have modified the native TOptional type heavily, to make it more convenient, by adding Map()/Bind()/Flatten() methods.

Now we would like to add a similarly convenient optional type for Blueprint use.

We have already started working on a UBlueprintCompilerExtension to detect invalid pin connections, but we haven’t started on the actual data type itself.

Does anyone know about a plugin that offers this functionality?

Or, alternatively some good resources on how one can write custom Blueprint graph nodes with wildcard pins?

  • soulsourceOPEnglish
    1·
    1 year ago

    Sorry for the late reply.

    Would you want to support structs and/or bp structs with this or just the basic unreal types like integrals, strings etc.?

    Ideally it should be optionals of any USTRUCT. (I know, it’s a bit half-baked, given that all USTRUCTs need some way to construct them out of thin air.)

    Do you see this as using execution pin branching like the branching IsValid node? Execution passthrough like BlueprintCosemetic/BlueprintAuthorityOnly functions? Or some kind of setup with pure nodes that no-op if the optional isn’t set?

    I’d say it depends? For Bind/Map probably some form of passthrough would be more ergonomic, but for Flatten branching feels more natural to me…

    Do you have enough people working in blueprint who would be able to make good use of these? Would your less technical designers be able to understand and modify graphs built with optionals?

    This is a question that we have been discussing for quite some time too. Our end-goal would be to have at least some classes for which we want to lock down Blueprint logic, such that calculations are still possible, but interaction with the game world is not. For those I think we might gain something. We are not sure yet how we can convince designers of the benefits of locking down those blueprints. The arguments on the table are that coders are going to have the same restrictions on those classes, and that we have a long history of bugs caused by blueprint logic that was supposed to be pure not being pure. We are currently also discussing a 2-step approach, where designers have complete freedom for prototype blueprints, but those blueprints get excluded from shipping builds. In order to get them packaged, the additional safety features would need to be enabled, what may or may not require some refactoring, depending on the quality of the prototypes.

    Nothing of this has been decided upon, by the way. That’s also one reason why the whole Blueprint Optional topic is currently only being worked on once every couple of weeks. It’s currently mostly about finding out what works, how it can be done, and ultimately also how happy design/art/tech-art are with those changes.

    I fully agree on your last paragraph. That’s also an argument for the potential 2-step approach. The second step can very well be a proper and (hopefully) clean C++ implementation of a prototype blueprint.