would personally like to to see udon graph version

[Trimead]

Feature Description: a command/button/w.e to switch from udon sharp to udon graph.

Additional context: being able to type C# code is nice for programmers or ppl more familiar with how udon/unity work in general, but not exactly helpful for someone that knows very little. and udon graph is a fine starting point for very little programming knowledge, but still feels really confusing and hard to understand and not really enough examples to really get the desired effect I'm looking for. if someone else made an udon sharp asset and I was able to dissect/copy how it works in graph, then maybe I could get the effect I'm looking for while really understanding udon better. (after all, there really isn't a good way to learn, just trial by error)

[BocuD]

That is kinda the point of U#, being able to work with code makes stuff a lot more clear and easy to work with compared to Udon Graph. Because of how U# works though this will probably never be added. U# does not touch graph in any way, rather it is an alternative to it. It compiles down to Uassembly, just like Udon Graph would. If you want to make use of the more complex functionality of U# i suggest you try learning how to use it by first creating simple programs in Graph and then trying to recreate them in U#, to learn some of the more basic concepts. You should then quickly realize how little code you need to recreate complex graphs and slowly learn to work with it.

[Trimead]

I appreciate the quick response, I honestly was under the impression it wasn't going to ever happen. Trial by error isn't really the way I enjoy learning. Everyone telling me to "just figure it out", is like trying to make a cake, for the first time ever, without instructions. I have all the tools I need I even have a good idea of what a cake is supposed to look like, but without the step-by-step instructions, all I can do is hope I toss the right stuff into a bowl and magically get a cake. it's frustrating, to say the least.

[evolvedant]

Even after step-by-step guides on how to be a game programmer, trial by error is still absolutely essential to being one.

No one, not even the famous John Carmack can program an entire concept without some trial and error, seeing what works and what doesn't. Testing ideas, trying out new API's. As a game programmer, you are always learning, always experimenting.

It sounds to me like you are a begininer that knows all the tools involved, but haven't actually watched any youtube series, or online courses that teach you the basics of game programming to solve various common tasks.

I suggest watching one of the step-by-step series on game design/programming by Brackeys. https://www.youtube.com/c/Brackeys

Or taking an online course (of which there are many) on Udemy.com

Once you get your feet wet following those guides, coming back to Udonsharp and seeing what people are doing with their code won't be as daunting.

Not everyone needs to work like this, but like you said, you don't want to start off by trial and error alone, so then if it's step by step you want, it's all out there waiting for you, I provided some links to get you started.

[NGenesis]

You should definitely check out Vowgan's video tutorials on YouTube (https://www.youtube.com/c/VowganVR/videos) which explains how to implement various common functions you find in VRChat worlds in both UdonSharp and Udon Graph so you can see how they compare.

[FairlySadPanda]

Just to add to this: U# code being translated into Udon Graph would look like totally unreadable spaghetti to most people. U# allows us to do a LOT more than you can do in Graph. You'd potentially be looking at hundreds and hundreds of nodes for even basic things.

U# also does a lot of stuff in sneaky hacky ways (like foreach loops) and has a bunch of fakery revolving around its proxying of C# assets into U#. All of that would have to be taken into account.

Whilst this is a nice idea it's almost certainly impossible to actually do in any kind of sane way.

[MerlinVR]

I plan to improve the scriptability of U#'s compilation pipeline in the coming months to allow other things to generate U# classes at compile time. That could theoretically be used to make a graph compiler that generates U# code similar to what Bolt 2.0 was going for before Unity bought out the project and killed 2.0. While I think it's worth giving the U# compiler the capability for that, I don't think I'd personally make a graph compiler that compiles to U# as that is a large undertaking in itself. Maybe in the future it'll look more productive for VRC to make the graph compiler go to U# under the hood, who knows.

For U# -> graphs as @FairlySadPanda has said, it's a lot more complicated and isn't as likely to be helpful. At the moment graphs are kinda limited in functionality and retrofitting U# functionality into them would be good way to burn several months of development time. I'm sure someone could write something that gives kinda viable looking graphs restricted to a subset of functionality from U#, but it doesn't provide enough of a benefit for the cost for U# to support it.

tl;dr: Graphs -> U#: maybe if VRC or someone wants to make a graph -> U# compiler, but U# itself wouldn't include that functionality only the API to allow other people to implement that functionality on top of it. U# -> Graphs: unlikely in any decent capacity. Someone could make something like that if they want, but U# likely wouldn't provide any API to assist that explicitly.

I'm closing this request since U# likely won't directly support this functionality, though it hopes to enable other people to build the functionality if they find value in it. Feel free to continue the discussion here if anyone has more input.