What's annoying you right now?

I think Garry doesn't like visual scripting / prefer keeping it as simple as possible 
The one provided by facepunch will probably never allow to do complex stuff like in unreal

I hate actiongraph. We should never have a visual scripting system where you can make full games, it was never meant to be that. It got too big and complicated.

I get why people point at Unreal’s Blueprint system and go “yeah, just do that,” but the tradeoffs are brutal once a project hits any real scale. Digging through a four-screen wide graph of visual spaghetti is overwhelming. searching anything is a pain in the ass. Diffing or reviewing it in version control might as well not exist. Ci/CD pipelines just shrug at you because everything is a binary blob. Trying to handle merge conflicts with it fucking blows. 

The blueprint system is cool for prototyping and I used it that way, but people building entire productions out of it doesn't magically mean its good for long term maintainability.

Epic can pour bilions into that system, having entire dedicated teams likely in the hundreds of some of the most talented software engineers the U.S. has to offer. Most engines can't match that level of investment and probably shouldn't try. The expectation that every engine needs a full "make your whole game here" visual scripting system seems to come from Unreal's scale. 

I think a lightweight graph for quick experiments, prototypes, small toys, and designer level tweaks makes sense. Once something needs to be stable, fast, testable, and team friendly, it is almost always better to write code and expose clean hooks for people to fuck with instead. That's extremely easy and very straight forward in S&box.

I get that, but at least consider some sort of compromise down the line. I have learning issues and can't program for the life of me, and Visual scripting makes it more hands-on and accessible for people like me. I feel more empowered when I can build logic visually. I would love to see at least something more hands-on when it comes to scripting or creating game logic for full games. Dreams PS4 had an advanced visual scripting system where people made entire games with it. Heck, it doesn't have to be something like Unreal Blueprints. It can always be something more unique in the end. I hope you could at least consider something eventually, even if it's small.

I've also seen smaller engines have their own unique visual scripting systems/addons for making full games. My examples are Construct 3's event system, Gamemakers' visual scripting, Dreams ps4's visual scripting system, the orchestrator addon for Godot, Hengo, which is another unique visual scripting WIP addon for Godot that compiles the visual script into GDScript, Event sheet by WladekProd, which was a WIP event system addon for Godot that converts the events into GDscript, Hytale's upcoming visual scripting for modding, or even Unity's visual scripting(or Bolt, which was the old visual scripting addon that Unity had). I'd recommend looking at those systems for some ideas. Heck, two of the Visual scripting addons I mentioned, despite being unfinished, showed promise; they were both made by only one person in a cave with a pile of scrap(not actually cause it's a metaphor, but you get what I mean). In my opinion, Visual scripting feels like the best way to make players become designers.

Visual scripting is cute for little functions, but in the grand scheme of things it hinders from actually learning to program in a way that empowers you fully. To paraphrase what was said earlier, it's not scalable. Additionally it's a layer of obfuscation in your project that the ease of initial use doesn't make up for the debugging pain later.

My current gripe is that while IMO, that is true and I agree with what Garry said a month ago 'philosophically', those things are also why Hammer is kind of stuck in an odd middle ground for certain use cases until scene mapping is fully fleshed out. 

Maybe it can just be used to make simple mechanics or simple things for simple games, but the end goal is for those who want to put their foot through the door and then be more comfortable with learning C# for when they need/want to do more advanced things. I think that's a good compromise.

It doesn't have to start out well. Just make it exist first and then make it good later with community feedback. You can make the system powerful, but not as powerful as C,#, to encourage those who want to do advanced things to learn C#.  It's just something to get beginners' foot in the door and then be more comfortable with learning C# down the line.

 It's not a bad thing if people are able to make full games with your tool. If that's what they want to do, they should be able to do it. Even if you don't like visual scripting, C# is still there.

How hard it is to test code against host migration. A (console) method for migrating host to a local client without stopping the editor (which  breaks local clients btw ) would be very much appreciated.

something like
migrate_host [client id]

If it can be done through a ui menu even better.

DreamPiece, When I started learning c# and s&box, I don’t understand what is programming. C# is so simple for beginner, visual scripting same coding with all skills, you should think like programmers to make visual code without problems at logic. Just start create game, learn basic concept, you’ll spend small time do it. I tried unity, godot and unreal, and after programming, blueprints look very large and inconvenient. In game dev coding is a small part, but if you really want to make game, you just have make them, just code, make mistake.

There is not a single successful game with clean and perfect code, but there are a lot of hits that have bad code. and also, look how much garbage comes out on Steam on Unity, the ease of programming allowed all this to appear. You're just afraid to make mistakes, but when you're building a game, all you do is make mistakes.

And I’ll add, you’re not coding an operating system or a nuclear reactor, all you’re doing is telling the computer through code, I want the red button to open the door. There are no algorithms or data structures here, unless we're talking about procedural worlds or shaders, it's basically just structural logic that you give to the computer, it will be the same with blueprints, only the code is simpler for everything

The reliance on modeldoc/hammer to do things. They feel dated and confusing to use. I want the editor to do all game stuff, blender to do all visual stuff. This is possible right now but theres no official integration, support or documentation for it. These two editors just make the whole experience extra complicated and confusing. Its been my main turnoff with s&box as a whole

Can you elaborate on the " this is possible right now " ? I'm curious what your workflow would be.

Don't worry @Gorgazor it seems facepunch is currently working on making scene on par with hammer to slowly deprecate it and iirc modeldoc is next

vVIGAZz C# is not simple at all. I got the hang of Unreal blueprints when I used them just fine. Just because you can learn things easier doesnt mean that others can. I would like to learn C# eventually, but I just want to start out with something simpler to get my foot in the door. After making the simple things with the simpler programming, I'd be more comfortable with learning C# for the advanced things.
Edit:
Whoever called me dumb with the box emoji is rude. I may not understand things as well as I wish to, but that doesn't give you the right to be rude to me and mock me for not knowing something or wanting to do something a different way.