C# source generators

[celeronpm]

REDACTED

https://www.change.org/p/tell-epic-you-want-to-see-code-orchestra-in-unreal-engine

[ScottKane]

That is absolutely brilliant For me, trying to move from Unity, I've encountered the same problems. Just wishing I could have a derivable in-engine class to work with to tie together blueprints and C# through inheritance rather than awkward back and forward static method invocations (at least I assume the generated C++ classes play nice). This for me would be a game changer.

[nxrighthere]

Nice work! A few questions if you don't mind:

• Do you reload a module with generated code dynamically while the editor is running?
• If yes, what approach do you use to track changes and trigger compilation of the generated code?
• Is hot-reload works consistently in your case when you consecutively add/remove properties after initial code generation?
• If generated code is used in the game module just like a regular C++ code, how do you handle cases when it's impossible to reload it (for example, with a blueprint function library)?

[celeronpm]

@ScottKane please DM on Discord - CrushDepth#0001

[MostHated]

I would definitely be interested in hearing as well.

[celeronpm]

I would definitely be interested in hearing as well.

DM me on discord please.

[darkguy2008]

@celeronpm any way we can get updates to this without getting into discord and DMing you? I feel it's too bloated. The discussion was great and I'd like to see more news coming in from here. Thanks!

[celeronpm]

@darkguy2008 yes, I can ping you here if/when we have a path forward for distribution. Given the complexity of the situation, there are no guarantees we can proceed as we had initially planned, unfortunately. I am extremely grateful to @pixeltris for bringing clause G of the EULA to my attention and hope we can find a resolution.

[celeronpm]

Hi all, we've decided to move forward with a custom .NET solution which fits our needs more closely and addresses unique requirements we have for our large scale high fidelity project. Please close this discussion if no longer needed and/or delete this comment if not appropriate.

Our solution is called code orchestra and can be found at https://code-orchestra.com

[celeronpm]

"Say you add a C# property to your class and press build, how long does it take in total reload into UE? " For our project a few seconds. We've built intermediate caching mechanisms where possible. The c++ proxies are lightweight and the build is quick.

Code gen has many benefits over runtime approaches, I can't go further into the details at this moment as it is core to our IP.

[pixeltris]

A few seconds sounds great. If you could get say a ~3 second hotreload for a structural modification on something on the size of ShooterGame or UnrealTournament that would be great and definitely the iteration cycle people would be looking for in a C# integration.

And yea I can imagine this type of code gen gives you a lot more control. I've definitely felt the limitations of the UObject system while working on USharp. For me it came down to compile times and having the ability to use C# without a C++ build system (i.e. BP + C#, or just C#). I guess I was wrong about the compilation times! I guess I should have at least tested...

If iteration times are good it sounds like a good choice for UnrealCLR too.

[celeronpm]

One thing I'd like to note also is that our codegen is bidirectional. Existing UE APIs are accessed via memory pointer offsets from C# proxies.

We do this at scale to ensure we can provide UE engine version specific supports including 3rd party plugin support (access 3rd party c++ class from c#, etc).

[MostHated]

It's a bit of a shame how much of a turn this thread took. Going from talk of merging awesome additions to the library, to "I can't go further into the details at this moment as it is core to our IP". I mean, I get it, but still.

[celeronpm]

@MostHated I definitely feel your frustration and thank you for the understanding. I would definitely PR the changes if they were changes to UnrealCLR. The only thing Code Orchestra and UnrealCLR have in common is that they provide C# functionality for UE devs. That's where the commonality ends and why 'merging' isn't actually possible.

Code Orchestra is a project that was born out of necessity to solve a problem that still exists for our use case. It just so happens we first tried UnrealCLR and started sharing our ideas to solving these problems publicly here before we went full force on rethinking how the problem should be approached.

I am also completely open to removing this entire discussion from UnrealCLR to begin with; I am not comfortable taking up so much time and space away from the project on its own discussion thread. It is quite disrespectful from my perspective but at the same time, I feel compelled to respond to the discussion I started as long as @nxrighthere is OK with it. The moment he feels there is no longer value in this thread, I encourage him to delete it, archive it, or take any action he feels appropriate as the project owner.

At a minimum we've provided value by confirming approaches which were not fully explored by UnrealCLR or USharp have benefits. Both projects may benefit from the noise we've created here.