koobas.hobune.stream
any else way finding floating point
is there any else way finding only floating point?
char c;
float f = Time.time;
f -= (int) f;
if (f < 0.5){
c = 'z';
}
else{
c = 'x';
}
I know I could do it with random but I don't want random
and if there is a way I'd like to know how to find let say everything that's after
0.00...
Not sure what you are after. To find everything after above you can do something like:
f = f * 100.0f;
f -= $$anonymous$$athf.Floor(f);
f = f / 100.0f;
the question is not clear.. can you explain clearly want you want with a example set of numbers or something?
because it's not exactly randome
because most of times you get too much or too less that's why I'd do it on timer and set it from range
0.009 - 0.05 for true 0.05-0.1 for false
or what ever I want to do with % and numbers
You could use % (modulo) or Mathf.Floor(). Note that % is a division operation, so be sure to check the second argument is not 0.
There might be a better way depending on what the end result you want is though. Why is random bad?
oh ok I can see that $$anonymous$$athf.Floor is doing same job as I'm
I don't like randome because it many times gives too large or some times too low
let say if I give it 50% chance
some times it'll rapidly give 75-85%
and some times it'll rapidly give 15-25%
you just can't get it around 45-55%
and even if you go on huge amounts like 10$$anonymous$$ you won't always get around 50% but more like 40-60 or even wider range
I don't like that
so giving time 0.01 is accuretly enough so noone is actually able to precise hit the button on correct time and the % accurecy is much better
basically what you want is for past results to influence future performance so as to normalize the chance. Ok well just code it in.....
do a SuccessionCount bool LastValue;
guess a random number and see if it fails or succeeds
if fail last value = false;
if true last value = true
also if fail & lastvalue = false; successioncount++ else succesioncount = 0;
same for true
so that tracks each time you get a value the same as the last one
and lets you know how mnay tiems in a row you've done the same thing.
you can now use succession count inside your algorithm of probability.
for eaxmple
probably = 50 + 10 * succession count
now for a result to happen 3 times there is a 50% chance teh first time a 40% chacne of it happening agian and only a 30% chance if it's happened twice. that helps prevent chains of success or failure.
A random number will "tend towards" 50% but, as you say, it can be uneven for small samples. It really depends on what you are trying to achieve. I think its probably worth noting that your time-based approach would be subject to the same randomness, by the way. In fact, random number generators sometimes take time as one of the inputs for calculating the "random" number.
If you start tracking frequencies, if you are not careful about the implementation its possible you might fluctuate even more as well. If you do use something like Sparkzbarka suggested, be sure to Clamp the values so you don't even up with negative probabilities/etc.
Imagine this situation: Game is an RPG with critical hits and dodges, which are "balanced" with a bias that makes one more likely as the other occurs. User gets "lucky" and dodges 4 times in a row. To "balance" the outcomes, the game forces 4 criticals in a row. Suddenly dodge goes from a useful stat to a dangerous stat! (I realise this is pretty extreme, but trying to make the point)
Another thing you might want to look into is binomial distributions of random numbers (basically adding 2 random numbers together). That will give you a very strong bias towards the centre. (Add two random numbers between 0-1 and you are much more likely to get around 1 than 0 or 2)
yea my method would never punish you though per say. That is if you did good things it would only increase the chance you wouldnt do it again. The moment you break the cycle the probability resets.
It's not like 50 to 60 to 70 to 80 percent then to 70 to 60
its 50,60,70,80 fail 50
and of course crits and dodge would each have there own seperate non interactable counters.
