How can I get a random unint32, so far I know I can use FRandomStream is there any other methods ?
Thank you.
NumberChosen = UKismetMathLibrary::RandomInteger(YourNumber);
Wouldn’t that return a signed int32 ? I need a unsigned int32 up to its max value 4294967295U
Thanks.
i do not see any functions that use unsigned int32s.
int64 UKismetMathLibrary::RandomInteger64InRange(int64 Min, int64 Max)
That should let you get that big of number and just put it in the positive side when telling it the min, max. ?
That’s a good solution however for some reason this function is limited by the size of a in32 so going over MAX_int32 will always return 0.
I tried this and the result is always 0
int64 Num = UKismetMathLibrary::RandomInteger64(MAX_uint32 - 1);
Looking at the function definition it makes a call to FMath::RandHelper which takes a int32, as far as I can tell there’s no RandHelper that can take something bigger than int32.
Thanks for trying to help I appreciate it.
Yeah i see that also, â– â– â– â– !
I’m assuming you looked into the Math:: CLASS file.
Yes I have. On the bright side though I attempted to create a uint32 version of the RandHelper function and it’s actually working.
uint32 AMyActor::RandomUint32(uint32 A)
{
return A > 0 ? FMath::Min((uint32)FMath::TruncToInt(FMath::FRand() * (float)A), A - 1) : 0;
}
I called it with the max value of uint32 and I got good results.
uint32 Num = RandomUint32(MAX_uint32);
UE_LOG(LogTemp, Warning, TEXT(“%u”), Num);
Sweet.
Oh wait a minute there’s a RandHelper64 so your original suggestion is the way to go, with that I can do
uint32 Num = (uint32)FMath::RandHelper64(MAX_uint32);
or use the UKismetMathLibrary::RandomInteger64InRange which calls that same function.
It didn’t work for me previously because I was calling the non range version which I believe it has a bug because seeing the definition here in KismetMathLibrary
KISMET_MATH_FORCEINLINE
int64 UKismetMathLibrary::RandomInteger64(int64 A)
{
return FMath::RandHelper(A);
}
It’s calling RandHelper which is the int32 version when it should be calling RandHelper64. The 64InRange version does call the RandHelper64 which is why it’s working.
Cheers.
Basing it off FMath::FRand() is probably not the best idea either due to its limited precision. Internally the implementation of FMath::FRand() uses a random value between 0 and 16777215 inclusive, see https://github.com/EpicGames/UnrealEngine/blob/99b6e203a15d04fc7bbbf554c421a985c1ccb8f1/Engine/Source/Runtime/Core/Public/GenericPlatform/GenericPlatformMath.h#L377
So you won’t be able to get more different random values out of it. On top of that your function suffers from loss of precision if you pass a value that cannot accurately be stored in a float (e.g. 2863311530). Even if FRand would return 1.0f you wouldn’t get 2863311530 as the random result but the next closest representable value.
In the worst case you’d have to do something like generating multiple smaller range random values and then do the byte operations to combine them to the desired size.
1 Like
I based that function on the similar implementation, take for example In UnrealMathUtility.h RandHelper64() is also using the FRand().
For generating a random unique ID for a few hundred items would that be an issue if you can’t get all possible random results ? or is that not what you meant.
I like your idea about generating multiple smaller range random, good idea.
Thanks for this info about this i had a wheel i was trying to rotate and it kept wobbling could not get it to act right, It is what you are taking about THE PRECISION. I actually had to every frame make sure the
WheelPitch = 0.0f;
WheelRoll = 0.0f;
are reset every frame other wise you get a wobbling wheel. I set those in the constructor to be 0.0f, but they change as they are not really 0.0f , well they are 0.0 bunch of numbers, enough to make your wheel wobble when running it thru tick to turn it. This is frustrating when you think ohhh 0.0f is 0 = zeroed out, oh no it some s-h -i -t like 0.02345678 enough to make a wheel wobble, but you see you set it to 0.0f and so you think oh its zeroed. reality its not!
Good point, I didn’t look at RandHelper64() before, it should have the same issue though since it’s based on FRand(). For a few hundred items that is likely good enough though. Could you use a simple incrementing counter instead?
If generating unique IDs is your use case you could also take a look at FGuid::NewGuid(). It produces a 16-byte (4 uint32’s) value. But the implementation is platform specific (e.g. CoCreateGuid on Windows).
While there’s both a +0 and -0 float representation, 0.0f should always be accurate. There may have been some float to string sanitization going on, or some other calculations/transforms involved that caused the final transform to not be exact though.
I figured out what the problem was with stopping them and them going off kilter. I had the x axis at -90 it needed to be 90. Caused some weird stuff as in causing the wheel to rotate wrong direction after you stopped it and restarted it. Also it was stopping on weird angles. Once i set it to + 90 that fixed everything.
Now the issue i seem to have is. When i ask them to stop at a certain degree they all stop at the same degree even tho my code says they are at different degrees. Question? If i had those as radians and not Degrees would that cause this problem.
Edit: Solved the above, i just got the code out of control and wrote stuff i did not need to once solved i had it to 4 lines and its all working.
Thank you I’ll take a look at FGUID.
The issue for me using an incrementing counter is I might be dealing with multiple servers that share the same data base.
Cheers.
If you have a database shouldn’t that be generating the ids when you insert new rows?
It should however the data base gets updated from time to time therefore I need a unique ID right away that I can work with without needing to access the data base remotely right away.