Search in
Sort by:

Question Status:

Search help

  • Simple searches use one or more words. Separate the words with spaces (cat dog) to search cat,dog or both. Separate the words with plus signs (cat +dog) to search for items that may contain cat but must contain dog.
  • You can further refine your search on the search results page, where you can search by keywords, author, topic. These can be combined with each other. Examples
    • cat dog --matches anything with cat,dog or both
    • cat +dog --searches for cat +dog where dog is a mandatory term
    • cat -dog -- searches for cat excluding any result containing dog
    • [cats] —will restrict your search to results with topic named "cats"
    • [cats] [dogs] —will restrict your search to results with both topics, "cats", and "dogs"

Change default behavior of "break struct" for custom structs.

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! -Neil

Product Version: UE 4.20
more ▼

asked Aug 24 '18 at 06:40 AM in Blueprint Scripting

avatar image

366 11 24 34

avatar image Everynone Aug 24 '18 at 09:26 AM

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.

[1]: https://issues.unrealengine.com/issue/UE-21554

avatar image Neilz0r Aug 27 '18 at 11:24 AM

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

(comments are locked)
10|2000 characters needed characters left
Viewable by all users

0 answers: sort voted first
Be the first one to answer this question
toggle preview:

Up to 5 attachments (including images) can be used with a maximum of 5.2 MB each and 5.2 MB total.

Follow this question

Once you sign in you will be able to subscribe for any updates here

Answers to this question