Change default behavior of "break struct" for custom structs

General Feedback & Requests
, , ,
1

Short:
Change “break struct” so that as you add more entries to your custom struct, it does not grow in height. You should be explicitly required to enable which struct items you would like to be visible, not the other way around.

Long:
When you add a “break struct” to your blueprint, by default it tries to add every item from that custom struct (although I have noticed that it only shows the first 2 items and has an arrow below it that allows you to uncollapse all of the visible structs". So, for the sake of this hypothetical situation, let’s say that you explicitly enable 3 entries and disable the rest. Your break struct will now show 3 entries (and that silly arrow at the bottom of the break struct becomes permanently unusable, which I would say should probably a bug for a separate ticket).

This is all fine and dandy, until you open your struct (from the content browser) and begin adding additional entries to it. Lets say that you add 3 entries (vector, float, bool). Doesn’t matter what you add, so just pretend you added 3. Now, let’s assume you have added 150 break structs to 10 different blueprints for this particular struct.

You now have those 3 new entries in 10 different blueprints, totaling 150 break structs. The consequence is, if you want tidy blueprints, you must go to each of those break structs and tell them to hide unconnected pins manually for each and every single break struct, and in this hypothetical situation, there are 150 of them. That’s simply unreasonable default behavior.

To make matters worse, because we explicitly chose 3 struct entries in our hypothetical situation, that “arrow” button that is now unusable, doesn’t hide newly added entries by default. So your struct will begin overlapping other nodes in the blueprint. If this is beginning to make sense, then you should hopefully agree that this is unreasonable default behavior.

It would be better if the default behavior was to just have no pins enabled by default and require the end user to explicitly enable the pins they would like to use. This will prevent custom structs from having boat loads of unnecessary pins active the longer a project remains in development.

Thanks!

2

I upvote every entry about structs by default. What you’re suggesting would be cool to have but in the light of other struct-related issues, I’d consider it almost purely cosmetic.

If you decide to go pure c++, structs just work. Expose it to blueprints and you’re already asking for trouble.

Using structs in blueprints for something like passing data from one place to the other, kind of works OK at a glance. But try doing something procedural or recursive, have a bunch of (non circular) references and update the struct with extra variables. Oh boy, you’ll be greeted with a wall of red text upon next launch.

The introduction of pin orphaning helped a bit and 4.20 structs have Hide Unconnected Pins button - so quality of life improvements are being made but I’d rather Epic focused on structs not rendering projects unrecoverable once you alter a struct that has been referenced in several other places. Just saying.

On the other hand, consider positing a Feature Request here, you’ll get more visibility.

3

I empathize with your pain! Thanks for letting me know about the feature request forum.