Staredit Network

Well if the starcraft randomizer function produces 'set' more often than 'cleared' anyway, it's not much of a randomizer in the first place. I suspect they stuck in some cheap randomizer thing that, through some overlooked numbers effect, ends up landing on one result more of the time than the other.

I think it more likely that our testing is limited rather than Blizzard's randomisation being flawed by a large amount.

Here's some interesting mathematics:

If I flip a coin ten times, what's the chance that it will come up heads exactly five times?
It's 63/256 or 24.61%, just less than 1/4.

If I flip a coin a hundred times, what's the chance that it will come up heads between 49 and 51 times?
It's 23.56%, just less than 1/4 again.

If I flip a coin a hundred times, what's the chance that it will come up heads between 45 and 55 times?
It's 72.87%. That still means that in the long run, over a quarter of all the results will be either significantly lower or higher than 50 'heads' outcomes.

In any case, it doesn't seem like anyone has done enough testing to conclude that blizzard's probability of outputting a 'set' result is necessarily greater or less than the ideal 50% in the long run average anyway.

If you don't want a great fluctuation in results, probably the simplest thing to do would be to make the results only have a limited range, say from 40 to 60 instead of from 0 to 100, by starting at 40 instead of at 0, and having less randomisations.
Tux's method is cool, but maybe unnecessarily complex for an effect that few people will notice.

Seeing as how no one has even downloaded the test map I made, how can you really say it's 'overly complex'? The only real sacrifice with it is that you need at least 2 counters to hold the weight amounts, or perhaps only one if you use the hundreds and over digit places for the weight of 'cleared' occurances, and the ones and tens places for the 'set' weight.

If you wanted to make it so randomizations wouldn't stick players on some bout of continual bad luck, then this would be good for that.

It was never my intent to start an argument with you, Tux.

I've now looked at the map, and your 'balanced randomisation' method requires about ten different variations on the one trigger - which is incredibly simple compared to most of the stuff you like to do, but conceptually quite sophisticated compared to most concepts discussed on SEN.
Nevertheless, in most applications, I still maintain that this balancing effect is unlikely to be noticed very much, and may be achieved in an even simpler way in some circumstances.
That said, the way you've done it in your map is very neat and elegant, and I like the idea.