Blueprints could be stronger by reflecting on what worked in Kismet

#1. Kismet vs Blueprints:
Straight line wires on any axis let you create more logical layouts, like in electronic circuits etc.
When used with collapsed Switches as ReRoute nodes, it was a neater layout using less space.
Whereas curved BP wires means more screen space to avoid so many crossed wires & overlap.

#2. Kismet vs Blueprints:
Kismet let users drag PINS and re-order them on nodes, which also meant less crossed wires.
This had been requested before and was promised. So what happened, its an easy mod, no?

#3. Kismet vs Blueprints - UDK Shortcuts:
Minimize Sequence nodes. They take up too much space and add nothing to overall workflow.
Why not simplify them like how it was in Kismet, just connecting wires dragged off other nodes?
Delay option on every node (Exec pin) & Log/PrintString with multiple inputs, badly missed too!
Kismet also let users hide Node PINS not being used on a per-Node-basis not a global setting!

#4. Kismet vs Blueprints:
Kismet offered right-click deactivation of node branches. Afterwards ‘Exec’ wires turned red.
This had been requested before and was promised. So what happened, its an easy mod, no?

#5. Blueprint User Customization:
Anyone looking for user control of wire-color and layout styles along with node-style Vote here.
It would be helpful for example to have invoked Custom-Nodes look different from built-in Nodes.

                   [MENTION=8]Alexander Paschall[/MENTION]                        [MENTION=160394]Sean Flint[/MENTION]

Feedback related to this thread…

I’d love to see #1 and #4 implemented. Thanks for bringing this up :slight_smile:

All this wire management is lot easier and faster in Houdini 16.
Please check videos in User Experience section:

IMHO other proposals aren’t that important or shouldn’t even be considered.

“Delay option on every node (Exec pin)” - it would make every node and entire graph latent. And that’s just opening door to hell. Worse performance and easy way to introduce mysterious bugs. You can’t use delay in functions/macros and that’s usually very good thing. Any system script shouldn’t use delay nodes, it would make it difficult to understand and maintain. Make use of updates on Tick.
Delays are useful for debugging purposes. Also for directing custom scenes (mix of action and cutscene, series of gameplay events), although… currently I find it’s lot better to use Sequencer for that (Timelines aren’t that handy).

Also I’m against “Kismet let users drag PINS and re-order them on nodes, which also meant less crossed wires.”
It makes system heavier, more data to store and process on every node. Also it’s easy to make graph less readable. And that’s great there’s no such feature in Blueprint. Every call of function should look the same.

No worries… Regarding the Delay we don’t know how this would be implemented in Blueprints yet etc.
In UDK the Delay was a Right-Click Option, not an automatic double node situation hurting execution.
But it’d also be interesting to re-consider after BP nativization is considered, as maybe this is all moot…
Overall UDK wires could be an INI file setting: UDK_BP_Style=true… To not affect default BP behavior.
As regards draggable PINS, if we had #1 straight lines / wires then dragging pins may be unnecessary.

[MENTION=8]Alexander Paschall[/MENTION],

Any chance you’d give us a link to ‘Vote on’ for #1 and #4 at least anyway?
To be clear, I’m not asking to change default behaviour, just add an option…

Despite being active with UDK in 2013 I wasn’t part of UE4’s beta program.
But I was always surprised that no one raised this in the feedback reviews…

This would be amazing

These are already possible today in Editor Settings (the color settings have been since before the first public release of 4.0; don’t remember when the spline settings were added, but it was still years ago):

I’m not sure what you mean by promised for (2) and (4); neither of these are planned, much less scheduled. There is an experimental feature to disable entire impure nodes, but it is on hold until we have better support for conditional compilation (which is turn on hold until some new cooker functionality is implemented).

We explicitly removed the many outputs on execution wires going from Kismet to Blueprints as it was a common and confusing source of ordering bugs; designers would end up breaking and recreating all of the links out of a node to ensure a particular order as it wasn’t visible or readable. Sequence nodes make the ordering very explicit, and in the cases where order is unimportant (e.g., SetLightBrightness or other similar methods) you can drag multiple Target pins onto a single impure execution node to call this function on all connected items in an undefined order.

Delay on every pin is also not something that will ever come back. Kismet and Blueprints operate fundamentally differently under the hood, and latent actions don’t make sense in a wide variety of contexts where execution wires can occur. Latent actions are special and relatively rare, they should be highly visible as it affects your comprehension of the program flow (to this end we added the latent icon to macros that contain latent actions in 4.16 and will possibly add it to individual execution output pins that are latent in the future to help clarify the ‘runs immediately’ pin versus the latent pins on async action nodes). However, there is a useful quick shortcut to create new delay nodes (D+click) and other common useful nodes (S+Click for sequence, F+click for ForEach, B+Click for Branch, etc…).

Michael Noland

Sorry, missed the note about print string nodes with multiple inputs, some of the bullet points had several notes in them. We’re mulling the idea of a new logging node that works a bit like the Text Format node does, accepting nearly any type of input with nice naming, probably a selectable log category and verbosity, etc… No promises about when it might be implemented, but it’s definitely on our radar.

Michael Noland

That would be nice, I often end up creating my own function to log things in every large project.

Cool, nothing against splines, but this looks super clean!
Even though this isn’t aligned at all when the lines are straight it looks kind of cool anyway. I also didn’t know you could disable the grid, with a flat color it’s a lot less busy visually. The only thing I don’t like is that the lines sometimes jump around when you haven’t “visited” the area when using long wires, this happens to me in materials.

Totally agree, looks great cyaoeu!
4.15 seems to have brought ‘Grid Snap Size’ too and when dialed down helps line up parallel / vertical wires.

That’s relatively new maybe 4.14 or close I think, but what a difference especially for posting screenshots!

Do you mean zoomed out? That’s when wires especially vertical ones still get skewed, but hey no worries!

What a mess :smiley:

[MENTION=2289]Michael Noland[/MENTION]

This is huge, thank you so much! Don’t know if your heritage is linked to Guinness, but if it is I definitely owe you some pints…
Before I was constantly fighting with the ‘backflip’ effect of adding a Reroute node in the middle of two vertically aligned nodes.
It was impossible to get right! Whereas now, just dialing down the X-values to a fraction gets you back close to how UDK was.

Fully understand about Delay. I mentioned it because it offered fast shortcuts for INSERTING delays without breaking any links.
Good to know Print-String node is coming, it’ll be popular. Any chance you’d fix this old annoyance too, it’d help a lot of devs!!!

If you’re still following: Any plans to let users color code Nodes, to make Custom-Nodes look different from Built-in nodes etc?
Related to that any plans to offer the ability to customize line-style of the actual wires beyond coloring (dashed / dotted etc)?

Reducing node space: [COLOR="#0000CD"]Back to #3 could you add Padding options to reduce the size of nodes like Delay / Sequence / Branch[/COLOR] etc?
Or offer a Collapse option that keeps same inputs / outputs but shrinks overall size + ‘hides unused pins’ option on per node basis?
Or provide an option to hide the title of the most commonly used nodes as you do right now with impure converter & math nodes?

Cheers again!

I set it to the minimum value of 1. Maybe others think it looks bad but it just feels way better when the node moves along with the mouse cursor when dragging stuff around.

To me it just looks better, with a flat background the nodes stand out more and it’s easier to see what’s happening overall.

No, it happens when zoomed in. With wires going across the screen it seems like the wire guesses where it needs to go, but when you follow the wire along it snaps into place when you see where it ends.

That was a function I created in a few minutes and never opened again until now. It looks bad I guess with the normal splines but it looks better with straight lines. The reason you wanted to align stuff with the default splines is that they would actually be straight lines, because if you didn’t align stuff you could get crossed wires and it just got harder to read. But when the lines are always completely straight it’s easier to read because it’s so clear where wires start and end up. Maybe not for everyone but I prefer it.

I see now. I believe its the way the engine specifically renders the Graph in Slate…
If so, there’s nothing we can do about it unless it gets logged / accepted as a bug…