API differences between native and managed frameworks

[Armitage1982]

Hi,

I wanted to see how much the ecosystem compatibility was in case I needed to learn external C++ documentation.
So I went to the roadmap and randomly choose a Completed API => Character.
As it is supposed to be interoperable, I went to look for the latest official documentation :

https://docs.unrealengine.com/5.0/en-US/API/Runtime/Engine/GameFramework/ACharacter/
https://github.com/nxrighthere/UnrealCLR/blob/master/API/Character.md

But only to find out that the Class was "incomplete" with some differences in methods names.
Exemple :

		void StopCrouching(ACharacter* Character) {
			Character->UnCrouch();
		}

1. Is there any reasons to change methods names?
It doesn't look like much on one or two Class, but on the hundreds of Classes that make up the UE API it might complicate things.

2. Is there a reason why Class marked "done" in the roadmap seem incomplete?
Will this not be a problem?

3. I have noticed that Blueprint API and C++ API are mixed in the same namespace
(e.g. "InstancedStaticMeshComponent" is in fact "Components => Instanced Static Mesh", or "StaticMesh" next to "StaticMeshComponent").
When using a Blueprint component, is the UE virtual machine involved or do we call its C++ counterpart directly?

Thanks for UnrealCLR, it opens a lot of possibilities for users of C# game engines.
I'm looking forward to the addition of .Net 6

[nxrighthere]

Is there any reasons to change methods names?
It doesn't look like much on one or two Class, but on the hundreds of Classes that make up the UE API it might complicate things.

Is there a reason why Class marked "done" in the roadmap seem incomplete?
Will this not be a problem?

Unreal Engine's native framework is historically messy spaghetti due to the legacy burden it's carrying from one version to another. The plugin's managed framework is not a one-to-one abstraction of the native API. I'm trying to keep clean idiomatic C# code. If something looks like it's missed in a particular managed class, then:

• Probably it's legacy API
• It's blueprints API
• It's duplicated API that is available in relevant components (Check and compare AActor and UActorComponent functionality, as a good example)
• It's a networking API that is work-in-progress

Sometimes some variables or functions can be missed in the managed framework, but I can expose that if required.

I have noticed that Blueprint API and C++ API are mixed in the same namespace
(e.g. "InstancedStaticMeshComponent" is in fact "Components => Instanced Static Mesh", or "StaticMesh" next to "StaticMeshComponent").
When using a Blueprint component, is the UE virtual machine involved or do we call its C++ counterpart directly?

There's no such a thing as pure blueprint classes. The engine's virtual machine is involved only when you work with blueprints from the editor and weave it with managed code in one or another way.

[Armitage1982]

There's no such a thing as pure blueprint classes. The engine's virtual machine is involved only when you work with blueprints from the editor and weave it with managed code in one or another way.

That's good to hear.
The porting method used seems long and laborious, I was afraid that in addition to being not easily scalable, it would be slowed down by an overhead with the VM.