to distinguish between multiple things, like filtering things in real life, they either need to have something that is a “unique Identifier” (or unique enough) to distinguish them, or they need to be given something that is a “Unique Identifier”, and Actor->GetName doesn’t count because when you give it a name in the outliner that name will be completely different (almost random) during runtime even in PIE. For example if I give an actor (BP_TestingTargetDummy) the name TargetDummy_05 in the Outliner then even in PIE it could have the name BP_TestingTargetDummy_C_UAID_2CF05D6D9973539201_1544992946 which is “similar” to the name it will have in the released version, and GetActorNameOrLable outside of Editor is GetName()
for example if I want to have an Entity Manager, that holds pointers to all the Entities I care about (NPCs and Player to save on the lookups) then I can give them an int32 UniqueID, and I can use that.
if you really want to go down this rabbit whole (I really think you are overcomplicating this) then to get a UClass instance from a string. you will need to take the FString convert that to an FName which you then need to resolve to a UClass each of these steps is technically no more then 2 engine function calls, but they have a big list of things that can go wrong, and should be very strongly typed, and can easily fail. Then you add in how a string entered into a Blueprint is not completely the same as FString in C++.
after going through your initial post on this thread:
‘CastTo in Blueprints is not good’: yeah, kind of; but we are talking about like 5 additional processor cycles, so don’t be using them all the time, but
if ( AMyActor* actor = Cast<AMyActor>(inActor))
{
// 'this test is to ensure the actor is not being destroyed'
if ( isValid(actor) ) // there is also actor->IsValid()
{
}
}
if you are doing it every frame that is “faster” then the 2 blueprint node equivalent but can still introduce slow down, and should be avoided if possible.
and if this was going to be happening often then taking a String from Blueprints to get a UClass in C++ to then take a String From Blueprints to resolve to a property name in C++ is going to be a LOT slower then those 2 blueprint nodes. not to mention a lot more prone to errors.
can you give a more specific example of what you are trying to accomplish?