It's not Unreal-specific. My point was that "visual scripting" has no defined base data format. You use XML - someone else uses JSON - and then there's all the binary formats.
While that is true, in a way this is not different to regular scripts/code - every language has its own syntax, in the case of visual scripting this is defined partially defined via the file format. It might be a semantic issue, but I don't see that much of a difference - you cannot just write tools to operate on all available textual languages, due to different syntax (C-derivates using {}, python using intendation and Ruby using XXX - end for every block). Sure, you can always just view textual languages in a notepad, and I get that it limits the use of visual scripts to a certain range of language-intern tools. I personally don't see that as much of an issue (after all thats why its called VISUAL programming 
), but I give you that if visual programming ever where to take over in large scale, there would have to be some sort of standard to be set in order to be more widely usable.
Yeah, that's what I do for the time being. But its bad. Why would I want to disconnect wires and then have to reconnect them later? What if I forget where those wires connect to after having them disconnected for a few days/weeks/months? In visual studio, you can comment out a huge section of code by using "Ctrl+k + Ctrl+c" and its instantly commented or uncommented. In the blueprints, there should be some sort of way to just disable a bunch of blueprints and the wires should be greyed out and the flow of execution should somehow skip past the gray wires without executing anything. I'm not going to hold my breath waiting for that to happen though.
I don't see it as that bad - sure, I havn't had a situation where I had wired disconnected for a period of months, but usually if I do this blocks are already positioned in a fashion that makes it stick in the eye where the wire originally had been. But again, having such a feature would be a nice addition. I'll certainly put it on my own feature-list because I like it. Since I don't use Unreal anymore ATM, I won't bring it up to them, but if you are using it regularely, why not bring it up to Epic Games attention? Maybe if enough users like the idea they will implement it based on that.
If you have several projects, there may be a time when you want to take the generalized functionality of one project and insert it into another. It's a pain in the ass to copy/paste blueprints and nodes because a lot of the stuff contains project specific stuff.
Ok, I can't comment on that, such until now I always ever had one project to work on at the same time, and didn't have to carry code over to the other. Unless I'm mistaken the problem is that copy/pasting will remove all nodes that are not known at this time in the other project, am I right? Which would mean that this could again be solved if the editor would simply not remove those nodes but keep them (and simply issue a compile error as it is already capable off).
Another use case is where you create a specific type of object (in my case, a wooden door). It works. It's great. Now I want an iron door. Oh wait, both of those are doors! So I should create a generic "door" object and have both wooden and iron doors inherit from it. Now, can I just copy/paste all of my wooden door code into the parent class? Nope! You have to go through and manually recreate every. single. function, variable, event, and delegate. In code, it would be a simple class rename and creating two new classes for each door type and implementing their unique behaviors. A 5 minute job gets stretched to 5 hours, depending on your node complexity.
Again, I might not have the full picture of this example, but can't you just rename the WoodenDoor-class to BaseDoor, and create two classes the inherit from that? Or copy the WoodenDoor-blueprint, and then rename it? We certainly had to do this kind of stuff both on C++ and Blueprint level a few times, and I can't recall we had that amount of problems. But I remember that reparenting in blueprints can be a pain in the ass, so I do agree that there is also room for improvements.
Yeah, this is rather trivial to demonstrate. Here is a few lines of code from one of my base creature classes:
Ok, I agree that this is something you would not want to make in blueprints. As I though, its math & multiple return values which tend to be really asinine in blueprints. I'd still take you exaggerated with the one line vs 2 minutes blueprints analogy - because even though it sucks, I certainly wouldn't take 2 minutes to create ie. the last return statement. But again, I agree that it will take longer to create this function in blueprint than in code. I still have to ask a few more times here:
5. Create a temporary "float" value in the functions local values.
6. Create a "get actor location" node to get a vector
7. get the explosion origin vector wire from the input and feed that into a "vector distance" node, and set the local variable node to the output (four nodes to do 1 line here)
Is the temporary in 5. the equivalent to "Dist" in the code? In that case, I say: You don't need that. In blueprints its common (at least I always assumed) to only create local variables when you really need to. So instead of having all those nodes and putting it into a local, you just directly connect it to wherever it is needed in the alpha calculation. You don't need a local here - in C++ you create a local variable because otherwise you will have 2-monitor wide lines, but in blueprint you can already group calculations by position (and/or a comment block if needed), so there is no need to store every single step of calculation. Exception is of course if you need that value multiple times in the same function, AND performance really matters (I can't count how many times I've just connected the same block of calculations to multiple other nodes and it didn't matter the least). I'm even thinking about giving a shorthand for this case by making the user able to mark individual nodes as "constexpr", which would mean that in the current function, whenever the node is called, only the first time it is actually executed and the rest of the time its value is just reused, like a local variable would, eliminating the need for local variables for even more cases.
Also, from your description I can't really see if you create the nodes separately or already create them by dragging a wire from the output-slot and then type in the node name. Because if you don't do that already, there is also a lot more time to be gained. If you do that, the time between writing those one line and creating multiple nodes does reduce a bit.
So yeah, I'm not even arguing that such a function is better written in code than in blueprints, I used to put just that type of calculation in C++ whenever it got outhand. Again, thats why I'm trying to design some textual math-extention for visual scripting to solve this problem, as I doubt math will ever be douable with nodes just as good as text (unless someone comes up with a brilliant solution). Though what I'm saying is that there is a lot of shortcuts to reduce the time and amount of work you have to do in the blueprints. If you also count/add the compilation time to the mix (our project with ~10k LoC used to compile like 2-3 minutes for adding a function like this sometimes), then I'd say the difference shrinks.
EDIT: Also I noticed that if you screw the local variables you can simplify the blueprint version of your code even more, by converting the conditional return to a set of OR/AND statements, and using a Select-statement for what you return as Impulse. I'll check if I have a workable Unreal at this PC so I can give you an example of what I mean. Thats kind of what I'm trying to get across though - if you try to 1:1 map code to blueprint, its not going to work. But those visual scripts sometimes let you create code in a different fashion than you would in a textual language, which (at least) reduced the overhead by a significant margin.
)
