Hi Tegleg
There’s an old name I recognise from the UDK days 
In regards to Blueprints, you’re best to put all the logic into functions/macro’s. Then just use the event graph to just fire off the functions so you end up with very little on the event graph itself. The youtube blueprint tutorials don’t really explain this very well they just gumph everything into the event graph and like you’re finding they quickly become an absolute mess.
Even go as far to put functions within functions if need be just like normal programming, I find that if a piece of logic is becoming to large even within a function I’ll create a new function or macro to cut down on the amount of space it takes up on the screen.
I’d highly recommend NOT using the collapse nodes function, only because when you’re watching the blueprint whilst the game is running, normally you can see the flow of logic, problem with collapsed nodes is the flow stops at these collapsed nodes and it doesn’t visually look like its flowing through the node which is very confusing as you think something has broken. Unless of course that’s considered a bug and is fixed in 4.5. Either way it’s only doing the same thing as a function or macro would do anyway so you might aswell put it into a function/macro then you can always use this function/macro elsewhere in your blueprint if need be.
EDIT: collapse to function as mentioned by Zeustiak is fine and doesn’t suffer from the same problems as the ‘collapse nodes’ and I’d recommend using this aswell.
Also function and macro libraries are good when you want some general logic that could go in various blueprints.
Might be worth looking at this link below:
I put up a quick tutorial regarding casting to help someone on the forum and I explain and show an example of cutting down the mess in the event graph.
Here’s a simple example:
So here’s a function called ‘Find Enemy’. It basically fires a sphere cast and returns the actor hit. Not overly complicated but if you added this to the event graph even once straight away the event graph is becoming cluttered.
So now it’s in a function you just add 1 single node to the event graph instead and it keeps everything alot neater. Obviously ignore the fact I’ve then added two extra nodes to print a string, I wouldn’t normally put that in there it was just for debug purposes
So basically, event graph, don’t clutter it, put the logic in functions/macro’s. Your event graph should be as simple and readable as possible and really should be an overview of the whole logic.
Give me a shout if you need any further help, any particular bits of logic that you want to run by me and I’ll try advise how best to split it up to be more readable.
I leeched enough knowledge off your good self back in the UDK days 
EDIT: just had another thought…local variables. You can use these in functions to cut down on pins that have multiple wires coming off it going all over the place, just set the local variable once then you can use the ‘get’ on the local variable instead of sending an output pin to multiple input pins spread out all over the place.
Basically think of it like real programming, which I know you’re adept at Tegleg most of the methods to keep your written code clean and readable apply to blueprints.
Custom events are nice too.
). I am pretty sure using the category on functions didn’t work when I tried it months ago, but it looks like it was since patched and I didn’t notice.