Yes, indeed. And that’s what must be done to make it usable. Even in code, usually, you don’t pass any methods by simple string, but actually providing actual &UClass:MethodName - which can be validated by compiler and even code inspection (VAX/Resharper).
That’s the exact kind of sentence people shouldn’t use in technical discussions. It’s not about liking. Dissuading conversions like that is a weird way to dodge an arguments
I’m talking merely about the usability of it, not performance cost.
Unreal CLR got sometimes mentioned as an example “oh, integrating C# is easy, just look at that”. Although it looks it’s unreasonable to use it. Only because the engineer in the team very much wants to keep using C# while Unreal C++ already provides benefits of the managed environment (reflection, garbage collection, blueprint stuff). There’s no single advantage of C# over Unreal C++, except “I don’t have to learn Unreal C++”
I simply got the first look at CLR and I don’t get why anyone would use it. “Pure C#” is unacceptable in UE4, it’s a huge step back. It’s forcing users to use a worse solution just for sake of programmer’s preference. The programmer’s role in the team is to serve others, not other way around… (hope that doesn’t sound too harsh)
But in mixed C#-blueprint setup
a designer would have to know the exact name of methods from systems?
how would blueprint users know the method name changed?
genuine question: is there at least a way to see a tooltip over such a method? is there a way to search in all available C# methods?
Maybe someday we’ll get decent support for C# or custom scripting language
Sadly, all existing implementations are lacking…
It’s not the technical discussion, that’s the difference. You come from your personal preferences and opinions that have nothing to do with the actual technical part of the subject.
This quote explains you are an extremely biased person.
I’ve been quietly watching this thread, perhaps one-day Epic will have a viable scripting language.
I feel that there is a need for something in between BP and C++.
BP is good for procedural stuff and quick prototyping but beyond that, it can get out of hand very quickly, whereas C++ is too unproductive compared to a real scripting language.
Sure, the current C# implementation is far from perfect but it’s a noble effort.
Even if it’s not well integrated into existing BP architecture, I still think there are many good use-cases, such as using many .net libraries out there for free. ^^
So I hope it won’t discourage anyone. I really appreciate the efforts.
Thanks! The current approaches are not in the final form, and things will be changed significantly after .NET 5. The project is in the preview stage, and I’m gathering feedback at the moment.
Well, if major improvements are possible, I wish you success with it. That would be a voodoo magic.
Especially that now I noticed you are the author of the Unreal CLR. I hope you didn’t take to personal
This most “bias” between using a mature “Unreal C++” environment and writing game logic in pure C++ with only barebones API, standard library and supported only by stitching any kind of scripting language on the top of it. It’s walk in the park compared to what other engines (other than Unreal and Unity) would offer. Scripting language environments in game engines are usually far from ideal, including Kismet. I don’t miss it at all…
I’d love to have a mature scripting language environment, for the sake of technical designers at least. Or any developers who can’t be a full-time programmer.
That being said, that form of C++ we have in UE4 is “half-way to the scripting language”. There’s no much managing memory manually (especially in the runtime code), handling platform-specific things and such. This is not like isolated opinion on how much Epic brings C++ usability closer to scripting languages.
Congratulations @nxrighthere on getting a mega grant for this. Can’t wait to dive into this properly as it will help us work with existing C# libraries without having to reimplement them in C++. This is greatly valued in AEC industry where C# is more prevelant than C++.
Looking forward to it’s continued support and hopefully iOS support further down the line too!
