So, say I have a random number of units spread out randomly over a designated space, these units cannot move, and I'd wish to select one of them at random, and center a location over it. I wish that this randomized selection system had an equal chance of selecting any of the units, but there doesn't seem to be any way except to make triggers that randomly select one for each possible number of units.

Is there a way to perfectly randomly select a unit from a list of units where the total number of units varies without using random selection triggers for each possible number of total units?

I used this with DCs in my D1 map (e.g.: random value between 0 and an unknown value).

Steps:
1. count the units (cycle through all of them with "give" and store the count in a DC: "Count")

p# brings at least 1 men to area -> give to another player & "Count"++


2. create random value

set TMP = 0 and TMP2 = 0 and TMP3 = 0

randomize (8 switches)

Count at least 1 & switch1 > +1 (add # to TMP and TMP3) -> TMP = [0;1]
Count at least 2 & switch2 > +2 -> TMP = [0;3]
Count at least 4 & switch3 > +4 -> TMP = [0;7]
Count at least 8 & switch4 > +8 -> TMP = [0;15]
Count at least 16 & switch5 > +16 -> TMP = [0;31]
Count at least 32 & switch6 > +32 -> TMP = [0;63]
Count at least 64 & switch7 > +64 -> TMP = [0;127]
Count at least 128 & switch8 > +128 -> TMP = [0;255]


3. check the random value (needs to be inside the range [ 0 ; Count ])

Count at least 128 (TMP subtract 128; add 128 (save) to TMP2)
Count 64
Count 32
Count 16
Count 8
Count 4
Count 2
Count 1

TMP = 0 -> TMP3 is inside the needed range -> progress index++

TMP >= 1 -> set TMP = TMP3 = 0 (do it again :S)

recreate Count 128 (out of TMP2)
recreate Count 64
recreate Count 32
recreate Count 16
recreate Count 8
recreate Count 4
recreate Count 2
recreate Count 1


4. give units to the old player untill tmp3 = 0

5. center location and give all units to the same player (first owner)
_______________________________________________________________________________________

all triggers need to have an progress index count (DC) which you need to set to exactly with all triggers. Step 1 and 2/3 need different values because step 2&3 may be repeated.

~Ahli

http://www.staredit.net/topic/2644/

Yeah, I thought as much.

The best way can be found at the bottom of this tutorial, the Single Switch Randomization, a faster version uses one switch, one death count, and can get any binary multiple, and the entire thing can be done in a single trigger loop. Now, what I would recommend is to use Binary Count-Offs in combination with what was discussed in this topic to quickly transfer units, subracting the number transfered from the random number generated, and then when there are no more units to be transfered and if there are still numbers left in the randomized number, you give them all back and start over again, and once it reaches 0, the next unit in line is the selected unit

Make it physically:

Let an observer junkyarddog over the area where the random units are. Follow this Observer by a location and move 1 [men] at this location whereever you want to have it.

I believe that would favor the center, if JYD worked well, but it seems to favor the sides at times. Either way, not really the most fair random thing.

aaaaah yelloow it burns... but you have linked to useful topics.

Well, that is his website, and also his topic.

My point was that it is violent toward human eyes. What's yours?

Anyhow, after looking through the randomization topic a fair amount, I wanted to make a comment, but I figured I wouldn't bring back something from April.

I was going to point out that in nature, you can simulate a random number with dice, as the movement of the human body is quite unpredictable in this case, when you put a spin on it, or whatnot. Motion helps the random process. So my theory is that perhaps something similar could be introduced into maps that have a number of outcomes that are not simply powers of 2. Here's a physical example I got from googling [dice wiki] :

make a prism with however many sides you want, but with the 2 main faces of the prism rounded off, so as to prevent "landing" on those faces. So you'll be left with something like a pencil. You roll this and get a random number.

SC example: perhaps you could use pixel locations for each outcome several times over, and run an observer and stop it, if say, a player were tossing a die. Or some variation, if bnet is sufficient to make SC have different outcomes with computers.

Advantages:
-may have a more consistent duration of calculation.
-allows for the player to "physically" control dice.
Disadvantages:
-at least somewhat slow, probably.
-possibly not completely random. Needs thought and experimentation.

Depends. If the random cage is near the middle the path won't really favor anything. And still if it would, that doesn't matter when you also let the ground units junkyard dog. If you make the cage near the map edge you might want to make your own junkyard dog script. Place as many waypoints as you wish and let the units patrol between the waypoints. You can also randomize that.

Post has been edited 1 time(s), last time on Aug 7 2008, 11:25 pm by NudeRaider.

True, but ironically, making your own JYD would bring us back to a form of binary decision making, though I'm not entirely sure how it'd work out. The issue I'm putting forward is that there's often issues with probability that cause favoring. For instance, when you flip 2 coins, you have a 50% chance of getting a heads and a tails (HT or TH), but only 25% for HH or TT. I think it'd be hard to assume it doesn't favor anything without giving it a nice test, recording how long the unit is in each area after a long period of time.

Think about how hard it would be to not favor the edges or the center. Perhaps an exercise is in order, which I think i'll do myself now out of curiosity... make a box out of say, 8x8 dots. connect a line from each dot to every other dot. where is it most dense? That's the issue at hand. though JYD is different, since it can change directions at any time. Honestly i'm not sure how to emulate that.

Theoretically, if you're not in a very time-sensitive situation, you could cycle through each of the units by giving it to another player, and at each unit, randomly create one of two burrowed or air units at it as dictated by the randomization of a single switch. Once all the units have been cycled through, unless there is exactly one of one of the created unit types, just remove all the created units, give the main units back, and repeat the process. When there *is* exactly one of one type, that's your randomly selected unit. It'll take a random number of cycles to perform the selection (which is why you don't want to use it in a time-sensitive situation; you might get unlucky and need the triggers to repeat for a while before it succeeds), increasing with the number of units, so duplicate the triggers until it runs fast enough or your V key breaks from pasting too many times.

I'm not sure if that's what you meant Wolf, but reading your post made me think of another good physical way:

The units you choose from have to be stationary. Cycle through them and create a burrowed ling (cleared) or a burrowed hydra (set) under the each of the units.
Then give back only the ones with a hyd underneath, remove the burrowed units and repeat. That way you randomly seed out 50% of the units each step, until only 1 hydra is left.
Center on this hydra when you need the unit.
You can "precharge" the random selection that way or you could make as many copies as necessary to do this in a single trigger loop incase intervals between random selections can be very short.

Fox, your idea is slower than simply using Method II of Clokr_'s... imagine using just switches instead of those burrowed/air units. basically you're saying whenever all are 0 but a single 1, progress... otherwise repeat. This is far slower than simply repeating when an invalid number occurs within a few 2^power switches. Either way, it's a similar method, one I'm trying to overcome, as theoretically it could go on forever. Even if it's highly unlikely, it is hard to use a randomizer like that when it's so unpredictable. What if you need it done in one trigger cycle? Or, more reasonably, a set number of trig cycles. That's what I'd like to see come out of this discussion basically. One with equiprob, of course.

I'm not sure how fast Nude's method is, but at least it's debatable speed-wise. However, same issues here. You never know when it's going to end.

Did you guys completely miss my suggestion? It's completely random and can be done in a single trigger loop. While Nudes could work, it takes time and I believe it would favor the center, as that is where the observer starts.

... Note that the yellow will also be removed, that was just a test page.

Why yes, I completely did miss your suggestion. Well, that is, I refused to hurt my eyes any more after a little of it. Really, it's the tight font and yellow color that hurt.... the background was only emphasizing the mass of yellow. I'll try to read it by highlighting after I eat though.

(I wanted to get this down before commenting... too much crap going on and i got two ideas while reading partway through your explanation I pasted to a word doc to make more readable =P. sorry about the double post, but I didn't want to relate the last post to this one.)

I just thought of another consideration with method II... to make it more usable, you can have it calculate its first value however long it takes, but from then on whenever it gets an invalid variable, it chooses whatever variable was last, or possibly some simple change to it. The idea is to store several random variables, so when the thing takes longer than usual, you have a few left to use. Using it would cause it to assign the 2nd var to the first, 3rd to 2nd, and so on. this method may not be what one would consider perfect, but it would always be ready with a result, and would still technically be random, though the same thing is more likely to happen next. Sometimes this might actually enhance gameplay, depending on how it's used, but i think predominantly the method II triggers would work fast enough to keep the randoms coming. you could even assign it an additional +max number (+7 for 0-6) so you can tell when it was defaulting to last value, and that could just be used in emergencies.... otherwise it'd write over it with the next value it gets that is valid. So if => 7, and new var =< 6, then write over.

The only weak time would be at the very start, and if you wanted, you could either have a game start button that would verify the random process is finished, or just have the game start after it, or use a slightly less random but quick version to get things started, if it doesn't matter a whole lot right off, but is needed. You can also use it of course to sway game modes in favor of a more popular one, of course.

Next thing I was thinking about, which is before I finished your tutorial, was using a death counter and some form of randomizing translations of the number. Basically you'd just have it constantly fake randomize it, with equal probable outcomes. This can be as simple as adding 3's to a 0-6 constantly, while modding down to keep it in 0-6. If the randomization is simply whenever the player activates it, it will be sufficiently random based on time: just as motion is one way, so is time. I would be wary of using trigger functions for this time, as they are very precise undoubtedly, or at least mostly, so you'd likely get the same results each game. But throw in a human, and things get random. Throw in some random switches to the translation to determine the number added, and it's basically random. I'm sorry if this is basically your method =P... I stopped reading where you talked about "add one or subtract one" paragraph.

*reads* yeah dang, your death count randomization is basically the same thing. Well at very least, you were the inspiration. Yeah, on finishing, it's essentially exactly the same. yarr... oh well i tried =P. In any case, given a few seconds of time and/or human intervention for randomness, it's all pretty much worked out here, i believe.