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?

    • soulsource@discuss.tchncs.deOPEnglish
      1·
      1 year ago

      No news as of yet. This topic is not directly related to any of our projects and our R&D team is busy with more pressing matters, so we are currently only working on it on what we call “Lab Days”, meaning one day per month. The next Lab Day is Friday in 2 weeks, so that’s the earliest time anything noteworthy on that topic might happen.

      • the_artic_one@programming.devEnglish
        1·
        1 year ago

        I might have some ideas but I have more follow up questions if you don’t mind.

        • Would you want to support structs and/or bp structs with this or just the basic unreal types like integrals, strings etc.?
        • 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’m also curious if your team would actually be able to get decent value from this. Optional chaining can get a little tricky to comprehend, especially with map/bind/flatten. 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?

        I’m sure your engineers would appreciate optionals when working in blueprint but personally I find that any time I need to write more than trivial logic in BP, I’ll get it done faster if I just write it in C++. Not to mention the fact that blueprint vm performance can become a problem really quickly so I prefer not to let implementation live there for too long outside of minimal content-specific functionality in BlueprintImplmentableEvents.

        • soulsource@discuss.tchncs.deOPEnglish
          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.