- I say this mainly with regards to writing new nodes. it's as simple as dragging your mouse out of a pin, and a window will pop up giving you suggestions on what could be connected there
% id = "01H8Y0CKD1P9SNK3TV967M705C"
- then you select from the list and it creates the node, autoconnecting stuff as necessary
% id = "01H8Y0CKD1PQS2J2WB22ASZY17"
- one of the nicer autoconnections it can do is when you want to call a function on an actor component
% id = "01H8Y0CKD16PFNWJ6EAARHA7BD"
- instance functions require you to pass in a `self` to call the function on
% id = "01H8Y0CKD1FVPCA5NBY5KK1F5X"
- so what it does is it suggests functions to call on all the _concrete components
you already have in your actor_, and when you select something like `Destroy Component (DefaultSceneRoot)`,
it'll not only create a function call node, but also hook up `DefaultSceneRoot` as its `self` parameter
- Blueprint is strongly typed so you can't just pass in a `Float` where a `String` is expected
% id = "01H8Y0CKD1VVMB8RVECVGZP0V2"
- but instead of having you explicitly type out "o dear Blueprint I would like to convert this `Float` to a `String`", you can just join the two pins together and it'll insert a
conversion node for you automatically
% id = "01H8Y0CKD10GQBNNP0RBJEWKW4"
- I do have a gripe with this though and it's where it places the node. it tries very hard to center it but unfortunately never succeeds. perhaps a bug I could fix one day?
+ except when it isn't because Blueprint is still an imperative language and has a concept similar to statements (`Exec` pins), which breaks the entire idea of pure data flow and
- this split is called _pure_ and _impure_ nodes, where impure nodes are those that perform control flow (ie. those with `Exec` pins)
% id = "01H8Y0CKD1P5JQCGHEY405KKPH"
- this results in weird edge cases like needing two separate node types to handle branching (one that can have side effects - `Branch`, and another that can't - `Select`)
% id = "01H8Y0CKD1EGWTQYHT2WYQSZY5"
- `Branch` is used to shuttle control flow between two `Exec` lines, based on a `Bool`. you get a `True` branch and a `False` branch
% id = "01H8Y0CKD1WFEWNYPZWGCH3N7X"
- and `Select` is used to choose a value based on another value, kind of like a ternary in C++
% id = "01H8Y0CKD156C0ZAXK7JS9W81D"
- however it is quite annoying because you can only switch on enums (and other stuff that has a finite set of values,) whereas with `Branch` you can use any `Bool` condition you want
% id = "01H8Y0CKD1YP7Q3HVJJZNJAJKG"
- this would be fine if not for the existence of Gameplay Tags, which precisely _do not_ have a finite set of values
% id = "01H8Y0CKD1P7D9QMPVQYWSDFT5"
- there is a `Switch on Gameplay Tag` node, but that is for control flow and not data flow!
% id = "01H8Y0CKD126918N282MNBXD2C"
- this isn't an unsolvable problem but it illustrates the pure vs impure issue pretty well - you'd have to duplicate the implementation of `Switch on Gameplay Tag` to have
+ except where it usually applies to the `async` concept found in most modern programming languages, here it applies to the concept of control flow vs data flow
% id = "01H8Y0CKD1Q8RXXK3KE4F4XAFF"
- and speaking of `async`, [Blueprint handles the classic `async` problem very gracefully][branch:01H8Y0CKD106HXQAJK87XV0H93]!
- since control flow is based on those `Exec` pins, you can easily map your classic concept of callbacks to simply firing off the appropriate `Exec` pin
% id = "01H8Y427B05AER1R4XK1GZ6A0M"
- for example the node for playing animations (`Play AnimMontage`) has a few pins coming out of it that signal playback events like `On Ended`, `On Blend Out`, `On Interrupted`
% id = "01H8Y427B01SE52ZYA410QKWDQ"
- and you wouldn't even know these are implemented as delegates in C++landia. it just feels like a first-class feature
% id = "01H8Y427B0V2Y76JJ3Z229PD15"
- the only gripe I have is that you can only have latent nodes in the main event graph (you cannot have them within functions)
% id = "01H8Y427B0SPJ3NJCFS7S4YGR9"
- which is annoying but not terrible, since most of that latent, high level gameplay logic happens inside the main event graph anyways
- which means that when you first load a Blueprint, some of the wires will be bent in weird ways, and will fall into place as you zoom out and explore the graph more
% id = "01H8Y96DGDCEF6FEQWGX2BQ6AH"
- the effect looks quite janky and really upsets my inner perfectionist
- there's a `Straighten Connection` feature, which you can use to make your graphs look more aesthetically pleasing, but it only straightens the nodes such that they look good on the current zoom level
- so what'll happen with it sometimes is you'll straighten a connection, then zoom in, and the connection won't be quite straight because of the aforementioned layout shift
- thus you can add a Mesh Component to your Blueprint and it'll load *the entire mesh with all the textures and skeleton and everything* when you wanna tweak a variable or some logic in the event graph
- the VM isn't implemented in the most optimal way
% id = "01H8Y427B1JJD3EK24DCG76GR0"
- I've analyzed this in my [`dispatchers` repository][def:dispatchers/repo] if you wanna have a read
% id = "01H8Y427B1T148Y0T8E48DKJ3N"
- and that hard reference thing can make gameplay stutter when you're loading in new assets, but that's a more widespread issue than just with Blueprints
% id = "01H8Y427B15BD0HJWM2Y3EZBSZ"
- but in reality most of the logic you're implementing in Blueprints (high-level gameplay stuff) shouldn't be that performance sensitive
% id = "01H8Y427B1G7ZYE3S8RRHG5WRQ"
- and it's not hard to extract the performance sensitive parts to C++ because Blueprint offers tools for refactoring your code
