yes, it only not fails when comparing on blueprint side, the library is not 100% functional on C++ side, it need us to overload operator manually
I am sure this is not a bug, this is just something I think only I am doing 
From my point of view this is not possible.
Index = FCustomThunkTemplates::Array_Find(TransformArray, Location);
Location and Transform Arrays are Ftransform and index is an INT.
There is not much information on âFCustomThunkTemplatesâ but if it does not offer a a conversion option you cannot convert these to your INT Index .
Smart thing to do is try at least a different aproach, turn your int variable into an int array and maybe since they are all arrays it will convert from array to array.
FCustomThunkTemplates, so I donât think this is a conversion function, the math library converts things.
still not 100%.
the expected result is like this, I got this result when done in blueprint.
from this data table
donât know but in blueprint it working, donât know what type of conversion is happening behind the scene.
do
{
switch( __CurrentState )
{
case 1:
{
if(::IsValid(ItemGroupRef))
{
(AllTransforms).Reset();
ItemGroupRef->AItemGroup::GetAllTransforms(/*out*/ AllTransforms);
}
AMyGameMode::RandomLocation(AllTransforms, /*out*/ Location);
}
case 2:
{
FindIndex = FCustomThunkTemplates::Array_Find(Available, Location);
bEqualValid = UKismetMathLibrary::EqualEqual_IntInt(FindIndex, -1);
if (!bEqualValid)
{
__CurrentState = -1;
break;
}
}
case 3:
{
SpawnLocaton = Location;
}
case 4:
{
AddArray = FCustomThunkTemplates::Array_Add(Available, SpawnLocaton);
__CurrentState = -1;
break;
}
default:
break;
}
} while( __CurrentState != -1 );
}
I did not see this in your code in the previous posts
bEqualValid = UKismetMathLibrary::EqualEqual_IntInt(FindIndex, -1);
itâs a bool and if it meets the requirements meaning it finds a match it will turn to true.
Is this made by you ?
FindIndex = FCustomThunkTemplates::Array_Find(Available, Location);
bEqualValid = UKismetMathLibrary::EqualEqual_IntInt(FindIndex, -1);
Or did you find it in a tutorial ?
From what I can see when you call on the math lib FindIndex is suppose to be an int already, meaning the values have been converted with FCustomThunkTemplates, from the floats of the Ftransfrom to Int values, I donât see any other functions there responsible for conversions.
when we see the result output, it seems to me that the location vector transform is randomized by -1 subtraction.
location x.5738 was changed to x5638
after lots of tries, I decided to generate the native code to see what is happening behind the scene, and found these datas and shared
Hahha that is from relative possitioning because you did not transform vectors back and forth. Itâs from Relative possitioning because they are not transformed properly and as I told you they can shift on world possition.
So relative possitions will cause shifts between items when transformed in an imporoper way to world. Meaning you did not transform to world possition in a porpoer maner and when you did the items that had relative position shifted.
so I need to store the spawn points/locations in world transforms?
You canât leave relative position without transforming to world, they will constantly shift from different angles, perspectives , points of view of comparing things, if this == from this angle then itâs like this, itâs all relative and shifting. So world transfrorm is like a lock on relative once itâs applied corectly, the individual values will show up correct.
1 Like
I copied locations from this ralative location into data table, the spawn points.
I need to make them world and then record?
That is the problem, you need to convert them to world possition, and then compare with that. Relative position , I would also convert to local space even if it is local space then to world.
Relative position represents the distance of objects to the middle point representing the main actor of your class, or component, the main object, all these items are around it relative to it. So there is the middle point and then you have all these items with relative positions , relative meaning the distance coordinate offset from the middle of your main actor componet.
You are getting relative possitions from some where else ? and then adding them to your main component ? The main component has a middle point, root point and these have offsets from the main point. That is called Relative (to middle) how far from it.
void AItemGroup::GetAllTransforms(/*Out*/ TArray<FTransform>& Transform)
{
for (auto Mesh : { StaticMesh01, StaticMesh02, StaticMesh03, StaticMesh04, StaticMesh05 })
{
if (IsValid(Mesh))
{
Transform.Add(Mesh->GetComponentTransform());
}
}
}
not like that, you need to get location first on them.
Location on staticmesh01 02 and so on, you are getting the location on world like this, you need the reative location of items.
Get relative location on them and with that transform. Without getting location you are getting world coordinates on the meshes that are offset really from the main component, and you are getting the main component coordinate because world does not know yet about your extra items.
Makes it easy with Vecotrs, I donât use Ftransform.
when we see the result output, it seems to me that the location vector transform is randomized by -1 subtraction.
location x.5738 was changed to x5638
It seems to me that the difffrence is neglectable and this is your problem, the items have shifted to middle point because you got the main component location middle and itâs giving you a shifted possition on them as an offset because the world position does not know about your relative objects.
the world position does not know then why the items are spawned on the locations I want? and the problem is just they are duplicated, on one location 2 or 3 items are spawned
You need to shift your relative objects to world possition, so world possition knows about them, otherwise how can it ? if you donât transform relative positions you have to world. If you donât all the world knows about is the main component possition and the items you have it will see the same location for them as for the main root object.
So itâs going to take your relative positions you have and shift them to the middle and values are going to get scrabled. World does not know of your relative positions for the objects that have them, it must know and itâs why you have to transform them to world, once you do the world location will know about these items or better put their location, and itâs going to treat their position apart from the main component as a offset where they are and not shift everything where the middle point is.
But you got to know how to transform relative position to world.
1 Like