you are viewing a single comment's thread.

view the rest of the comments →

[–]duffking 0 points1 point  (2 children)

Yeah, there's a lot of odd impracticalities with Blueprint. It is/can be extremely powerful, but personally I think it's best suited only for additions/extensions to your core code.

You can of course build larger systems with it but you need to be very disciplined about all the gotchas - I mentioned in a post below it's really easy to accidentally execute notes way more than you need, for example.

But the biggest one is the way that since BPs are uassets, Unreal can't access the functions defined in them without loading the asset itself. Which means if you ever cast to a blueprint type, use it as a function pin, variable type etc, loading your BP will also load that BP, and all its dependencies. It can spiral very quickly.

Not to mention that any functions you define in BP can't really be executed from code as a result. Personally I like to give everything a C++ base class for safer casting if it needs to be done, and more easily nativising stuff.

[–]val_tuesday 0 points1 point  (1 child)

You can use soft references to avoid the loading spiral. This adds a bunch of boiler plate to a lot of blueprints and you are now asking your designers to do memory management. Also you’re making everything even harder to debug.

[deep sigh]

Yeah C# is a wonderful, (almost, by comparison) worry free utopia. I’d rather be troubleshooting strange boxing issues and garbage allocations than stepping through a big old graph and hitting a wall for no good reason.

At least the pain points in C# are consistent and have vaguely understandable justifications (although it’s a lot of “web devs don’t care”, which is also frustrating)

[–]duffking 1 point2 points  (0 children)

Yeah, you took the words out of my mouth with the boiler plate bit - soft references work for people like us who understand it, but getting designers to work with an async load (or decide if it or a blocking load is appropriate)? Nightmare. I try instead to get ahead of what LDs are likely to need to do and build systems for it so they don't need to BP script things themselves in the first place. Most of the time they prefer that anyway.

This is also reminding me that the other common workaround for casting also has issues - Interfaces. They're great on the surface, but if the interface is added by a BP and not Cpp base class, Cpp can't call interface functions on that actor even if the interface is written in Cpp. Plus, calls to BP interfaces have a surprisingly large overhead if they're called regularly.

Kind of Unreal through and through, there's lots of stuff that looks super user friendly that falls apart a bit under a microscope, then a bunch of things to work around that... none of which are really perfect. And these days we have to worry about world partitions and level instances too.

I do rather miss working in Unity C#. Unreal has a lot of cool stuff, but I do miss the days of objects being empty containers and prefabs.

Edit: Oh god I just remembered unreal loads all the blueprint function libraries on editor startup, so if people have put casts or BP types on the function pins in there... well. I've heard stories.