>>279882431
>>279903924
okay you've been shilling udon a bit and while i think its great for vrchat's future I want to clear up some misunderstanding you seem to have about it as you keep praising its "literally compiled into assembly bytecode". 
They call it a VM, but its not a real VM in the truest sense, its a really simplified stack based vm that mainly exists for program flow logic. its assembly bytecode is just a pseudocode that it parses. the instruction set is limited to PUSH, POP, COPY, JUMP, JUMP_IF_FALSE, JUMP_INDIRECT, and EXTERN, which is used to handle external calls to unity/c# functions. UdonVM is more akin to a bytecode interpreter like python, but really simplified. UdonVM does not handle any computation, purely program flow, it doesn't even have its own instruction for adding 2 integers together, it does an external call to a unity function to do so. It also does not handle data structures, any and all variables in udon assembly are address references to its heap, which correspond to a unity/c# data structure. As a result, their instruction set does not support an intermediate value, you can't define a value in the code itself, and any values/variables that are used in an udon program has to be declared as its own variable in the heap, even for single use variables. The uasm data definition spec is very limited, and only allows setting of values in uasm itself for ints, floats, strings, booleans, and "this" iirc. A lot of udon graph to uasm involves encoding value into heap data structures internally and is not represented in uasm at all. The udonpie author got around this by using a workaround but its not perfect, and results in slightly less efficient code. This is why if you make an udon program in graph and copied its uasm into an uasm asset file on its own, it will probably fail to run because of behind the scenes heap values missing.
Its still an early work in progress with a lot of issues and missing features that need to be addressed.