Download

Epic you've had enough time. Fix this.

@duke22

Concerned Epic will prioritize OP’s suggestion over more important things? It doesn’t work that way…
Max Gmpreussner gives a pretty good insight into how things work internally @ Epic here and here.

How does C++ figure here, you’re saying the OP should go into source and fix this on their own???
The thing is many game devs have to wear multiple hats, so that’s not always practical or even wise…

And Yet you titled the topic:

All I’m saying is mens men, particularly those who wear braces and hats use C++.

Go for a long wire that spans multiple widths of screen and then pan to the right. It’ll snap to anchor to the top left extents of the blueprint graph every time. Or does in my case anyway.

Wat for is wrong w/ title? I dun geddit.

OMGawd Noooo… !!!

this is absolutely horrible, we can’t let this line dancing continue!

who cares if the editor crashes or not… Who Cares!

this line dancing must stop! NOW !

lol, sorry but ‘this’ ^^^ made me laugh… lol

it looks more fun to watch than an actual problem. ya’ll sure this isn’t a feature? maybe a dev got bored? :rolleyes:

gl with this o/

I always bring out the sub-1000 weirdos. I was born with this ability.

It’s actually not the line wobbling alone…

The whole bluescript editor needs some work.

I like the basic layout and all that, but there is so much more possible, and there are lots of incosistencies, like not being able to reorder fucntions etc…

Concerning the graph drawing itself… Sure they can do much better.
I mean… they can make the engine render hyper realistic cars composited in real time… but can’t render straight edges. lol.

I can’t stand the edges not being able to be straight with some nodes.

This is a bit off topic, and a feature request, but if they gone solve this wobbling, they could as well do it right…

Been thinking a bit a bit about this… They made a few decisions early on on how to draw the graphs that can be done better.

The main thing it comes down to is actually very simple !

They align nodes…

What if the drawing is redone to align PINs instead !

So, all pins are always on the grid.

that, and a few changes to some node pin layouts, and the problem is fixed !

straight edges in all zoom levels !

In fact, yes, given how much time you spend in blueprint editor, if you use it.

I would very much like to see lines auto-tidying themselves on creation and node movement. This might be something I could work on if I ever find time.

If.
Majority does work on BP only for Design, not for serious development.

Real developers don’t think C++ is the only path to serious development. Real developers use C++ for what C++ is used for and blueprints for what blueprints are used for. Anything else is ego-based self-deception. I’ve certainly seen some developers kill their project with this “C++ is the only way” mindset. Welcome to not releasing a game or missing out on features due to a workload that is countered by using the right tool for the right job.

That argument needs to die.

On top of that there are plenty of valid scenarios to maintain a blueprint-only project, such as iOS development on Windows. Not everyone has a Mac handy for prototyping a game idea.

In fact, if you have a problem with blueprints then perhaps you have a problem with frameworks. Perhaps you have a bad case of not-invented-here thinking. Perhaps you think that developers who don’t write their own graphics presentation layer from the ground up aren’t serious developers. Because there’s guys like that and they’re massive red flags for the health of their project. I looked at a job vacancy today that read “you will be replacing a lead developer who basically created the entire framework we use” and thought haha yeah fuck no. Only bad developers think they can do a better job of reinventing the wheel.

But that’s not what this thread is about. We’re not here to argue with never-know-betters.

Because that’s what bezier curves do.

Nah he means that groups of pins don’t line up between two different nodes that share the same pins. It annoys me too, but that’d require quite a redesign to fix. For example you could make it so node vertical growth and input pin location is dynamic so that they line up, but that’d considerably change how nodes present themselves.

Not just long wires have this prob. Zoom out enough times and even short-straight wires become angled.

I wonder if Project Spline settings are a factor here too??? - Maybe…

I’d like to see the return of draggable PINS. We had it in UDK / Kismet and it really helped tidy up code.
One workaround is to use boolean operators like Not etc, but that often makes BP code less readable!

Most quality C++ coders are humble (Max@Epic etc). The ones who goad are usually DunningKruger…:stuck_out_tongue:

I did some photoshop. This is how I think it could work. Nearby attached nodes would:

  • influence their child pins
  • rearrange connected pins to the top in order of parent node vertical placement
  • grow the node vertically to automatically align
  • move unconnected pins to the bottom or to the first appropriate space

The vertical alignment feature would be optional per-node, in the same way comments are optional. It would default to off.

I’ve edited the last two nodes here to demonstrate the option turned on:

I don’t actually think that this would be all that hard to do. You guys wanna have a group effort and figure a pull request out together?

Uh, no, definitely not creating more space between pins, that just looks ugly and is hard too read.

( That is, to me… it could be an option, more choice eh)

To line them up with other nodes, you can align with reroute nodes.( who’s pin should als be on the grid), ie, i have no problem with bezier curves, but for lines that are almost straight, but just a bit off, that is irritating, like the ‘set target velocity’ node you have in your screenshot.

But better drawing, that could be default right :

Just need to think a bit more ahead of what types of data need to be able to connect, and use the largest one. i guess that would be a dropdown, color or vector input, havn’t checked.

That, and the height is also determined by the node design itself. so a header can have two lines of text, make it uniform. Why a get node has output in the middle, same for math nodes ? etc…

Get those two aspects down and you will end up with a given height that fits everything, this is the minimum grid size. Align all pins on this. so nodes getting wider will do so in pin distance steps.

Also, nodes getting wider can get wider on the side where no pin is, for nodes with only in or out. And for ather nodes, there could even be a system where the node remembers the alignment you used, and get wider to the other side.

I’ll make some mockups when i find some time.

If something like this is implemented, the old code needs to be kept around, and an option given to activate the new layout on older graphs, manualy per graph, since this would mess up existing layouts. Maybe that is why Epic isn’t touching it

Oh, and sometimes, being able to flip pins on a branch for example would be handy too

In a nutshell, better more beautifull drawing, without bugs, and more options on nodes. It’s visual after all.

Also, why nodes change proportion in zoom levels? sure you don’t need to see all information on a node, but it doesn’t have to wobble and change all the time eh

It’s even so that if you explicitly align nodes (using the keyboard shortcuts) they get out of alignment depending on the zoom level.

Oh, and sorry for hijacking the thread, didn’t meant to… should have started a new feature request.

Fix the wobbly lines !