I know there is a randomizer already in ProjectRed. In fact there are 2 if you count the bundled cable one.

However, the Randomizer gate is in most cases useless because, when given a redstone signal from the input, the outputs continuously oscillates 'on and off' at random on all outputs. There is no control over it to make it simply pick ONE output and have the output stay solid/on until the input is turned off. There should be. And it should be able to have a "State" mode whereby you can set the delay if you wish to use it in the oscillating mode so you can control it more.

So, my idea is simple,

I would like to propose a NEW and more useful and simpler Randomizer Gate that has ONE input, and 2 OUTPUTS labeled "A" and "B" Output.

It should have a GUI that will let you set it into Mode "1" or "2"

In mode 1, it simply picks either A or B instantly and stays locked on until the redstone input is turned off.

In mode 2, you can set a state timer that will give the output a timer so when a redstone signal is applied to the input, it sets a random output either on A or B, and stays set for a period of time, at which point the timer runs out, it will then again randomly pick another output (A or B) and then again. This will remain continuous until the input signal is turned off.

Recently, I made a Youtube video that I discuss and show off a Railcraft train setup and it uses ProjectRed Gates for the switching. However, I talk about how I had to create a Computer craft Program because a ProjectRed Gate doesn't exists or work to the degree I needed it to, to accomplish the goal of what I wanted the train track to do.

You can see the video here:
https://www.youtube.com/watch?v=hgkd4H8iqXc

Please Mr. TJP, create this A/B Randomizer Gate. It is very useful and needed!

I never thinked in the first idea, but i thinked in the seconds idea already.
The randomizer is so fast for some builds that i made, so will be nice to be able to change the time.
The first option is good also, now we need people giving ideas of where this gate can be useful, but i think that is already useful, so if @MrTJP say yes, we'll have this gate.
But i think that he is bussy working in the new tube update, have you check out the commit "merge tube branch"?Now we have Pressurized/Restriction tubes, breakers, deployers, item importers (transposers i think), a new plant and a worldgen rewrite.

Using the randomizer gate by itself, admittedly, is very useless. So I looked into your problem here, spent a few minutes throwing this together. Using a few gates, Ive created an ABC version of the same gate you are describing (easily scalable to any number of outputs).

Mode 1:

Uses a pulse former gate to create a random output and latches them into memory for access. The output will not re-shift until the lever is turned off and turned back on.

Mode 2:

Simply replacing the pulse former with a timer allows you to create the mode 2 version, with the output changing every time the clock ticks (easily configurable with its GUI)

Is this not adequate? I know its quite larger than a single gate, personally, I don't think its necessary to have a whole new gate with something that can be done with no more than 3...

The code for what you are asking is manageable, but thats not really a problem. If its something that is needed, it will be added.

Actually, all the outputs on the randomizer are independent of each other. Each one has the same 50-50 chance of being on or not. So, by using only 1 of the outputs, you can create an A(on) or B(off) easily, and disregard the others.

In fact, I just thought something else that would fit for your purposes. Actually quite silly I didn't think of it before. Perhaps tweaking the current gate isn't even necessary...

The two outputs up top, one would be A, and one would be B.

I see what your saying. However, the gate still needs made. The example you give is overly complicated for the average to beginner person. Additionally, when you have large builds or a server, these "contraptions" add TONS of lag to the world. My server train world would require too many of these and your current randomizer cuts the FPS down so badly for my server its becomes useless. This is also not 3 pieces - its 5 pieces and 12 pieces of wire. This can be simplified into one gate. Come on TJP. I think you forget that most people are not engineers. While I agree its some that can be figured out, the contraption is overly complicated for something that should be so simple. We also do not need an ABC gate. Just an AB gate. If you insist on having that third out put, you need to make it so the "C" out put can be disabled by screw driver. Please - institute the AB Randomizing gate. We REALLY need it.

My design isn't optimized, but if you were to optimize it, you can create mode 1 with 3 gates and 2 wires, mode 2 with 3 gates and 1 wire. The randomizer causes a ton of FPS lag because the randomizer is set to on and it is constantly causing block updates, which is bad, and totally not how it was designed to be used, even from the RP2 days. With a design like above, FPS takes absolutely zero hit. Not saying this is a bad idea, but it does only require 3 gates, and seeing as though thats the policy we've always adapted since the very beginning, there has to be an undoubtably good reason for this, so throw some at me.

What I will do is, add more modes to the current randomizer, so sides can be disabled and also modes to make the sides exclusive, so only one side is ever on at once. This would simplify design even further, as all you would need to do is disable 1 output, and throw a timer on the end and the gate will shift to one or the other when the clock ticks.

Here are the 2 modes, highly optimized.
Here is Mode 1.

Here is Mode 2.

If you were to fix the current randomizer, that would be fine. Make it so you can disable the 3rd out put. That sucks. It needs to be A or B. The third is completely wrong. It needs to make a decision A or B. and, not keep oscillating between choices when an input signal is applied to the input. It needs to make ONE CHOICE and stay SOLID on the out put for as long as the input signal is applied. When the input is turned off, and the replied again, the randomizer will make a choice again, A or B and stay solid and not pulsing back and forth.

Create mode(s) for the randomizer and set it by default into legacy mode where it works like it currently does now. That way is doesn't break current build for people. The new mode (the right and correct mode) is to set it like I said. Make it work like a REAL randomizer so it only picks ONE out put. and make it so you can disable that 3rd output. That adds a variable that screws things up. You only need A OR B. If you need a "C" out put, chain a second randomizer to it or reenable the 3rd out put.

Is this something that is so complex that will require a major code over haul to add?
Also, policies should be looked to as a guide line - not a hard and fast boundary. With growth comes change and we need to look at bending sometimes. I'm not sure what it takes to get a new gate added beyond asking. It would make life incredibly much easier and effective for server owners. Please. Add it. Or adjust the other one. but something needs to give here - please.

In your picture - it still doesn't work for me. The 3rd out put is a variable that will make no choice in an A or B only situation. If I wire the 3rd out put back to one of the A or B out puts, that would mean that one of them will be higher in percentage to be selected because it has an extra chance with the "C" being tied to it.

It needs to be A or B... ONLY. And the output chosen needs to stay powered solid until the input is turned off. Then when the input is powered again, it makes a new choice.

Simple. It MUST be this way. No 3rd out put as a variable - that screws it up.

I like your idea to change it @TheVoltrex.

I think the Mode 1 should be left in (Legacy) mode so it won't break current builds. This would leave 3 outputs, each with its own 50% chance of being On or Off, and oscillates.

Mode 2 (On/OFF), is basically as you and I both described, 3 outputs & 1 input: When an input signal is applied, one of the outputs is chosen and stays ON until the input signal is turned off. Then all outputs are cleared "off".

Mode 3 (Pulse) gives us the same as mode 2, except its just a single pulse. The input must be turned back off, and cycled back on again to get a new random output pulse to one of the enabled outputs.

Suggestion:
Using a Bare Hand changes the mode(s)
Using a Screwdriver +SHIFT Click will allow us disable 1 of the 3 Outputs so it only has 2 Output enabled. Just like any other gate, you can cycle through your choice of which output (side) will be disabled.

I decided to not make a video, because I think with the comments above, you can see the need.

Thank you for listening and for hopefully making this gate!

I have played with your setups extensively now. I can make an A or a B choice, as you describe. However, one of the gates always remains on after chosen. Not good or useful for train control.

Imagine you have to train tracks (A & B). Track A ann Track B need to converge into a single lane. Both trains arrive at the exact same time at the convergence point. Using detector tracks that put out a redstone signal, you wire them to an AND gate and they active a Randomizer which will choose Train "A" or Train "B" as to which will be released.

Now, BOTH your lock down tracks MUST remain in the OFF state until this randomizer situations happens, and after one train is released to go, the lockdown track chosen to release a train must stay powered until the train leaves and then it must go off, returning BOTH lock down tracks into an off state.

THIS IS NOT POSSIBLE with any of your setups or the current randomizer.

While I disagree that the current randomizer is "wrong" and "it sucks", I do somewhat agree with @choleprince that the randomizer needs a new alternative mode(s). Not a NEW gate, I feel like it is unnecessary to have two seperate gates that serves the same purpose (Randomizer Gate A, Randomizer Gate B). A new mode is the most efficient way to go about this. I also disagree that having the mental capabilities on an "engineer" is necessary in order to form a simple operation. The beauty of this mod imo is the direct correlation between mental challenges that require thinking, design, and experimentation ... onto the level of complexity of operation(s) an individual desires to compose. It also balamces out the cost of resources needed.

Moving on, onto the modes I have previously mentioned, I have a relivent, yet semi-different suggestion. The way the current randomizer is set up, it is basically 3 seperate 50% randomizers. The thing is, I had not noticed this until perhaps hours of experimentation. I was trying to figure out why my 3 doors were opening in predictable patterns. And trying to fix that became a huge mess. And other applications became a mess as well. In FPS and in design..
So this is my idea:

MODE 1: Sequenced (The current state)
-since all outputs are independant, there should be a option to turn off individual outputs in order to limit FPS drops
-I somewhat think there should be a way to adjust the time it takes to randomize to make simple decorations (like random flashing christmas tree lights)

This would provide use and funtionality to the randomizer used alone by not causing huge FPS problems and headaches/seizures

MODE 2: 1/2 mode
1 input, 2 outputs
-This would make outputs dependent upon one another. Meaning, there cannot be 2 different outputs on at the same time... This would be IDEAL for co splitters, and can be manipulated to be taken advantage of because of its dependency.
-Im not sure what to think about this onw though: should it be possible to have a no outsignal? And if it shoukd act as a pulse or as an toggle latch. Maybe there should be an option for it? Im not sure.

MODE #3 (most importantly): 1/3 mode
1 input, 3 outputs
-Currently there is no way to make a 1/3 chance of something happening.
-Coherently used with 1/2 mode, several different possibiltes can be made by wiring these two in series/parallel: 2/3, 1/6, 1/5, 1/9 or.. almost anything EASILY, which would have taken a TON of gates if done with independent outputs.. There is TONS of applications of this such as mini games, puzzles, decorations, mapmaking tools (1/27 chance of a withered skeleton spawning while the rest are regular skeletons) (1/90 of a chance to receive an indestructible diamond blade in a challage map) and possibilities are literally endless.
-Overall, the point of this addition is to allow for unequal randombility (such as picking a blue cap in a bag of 3 of different colors

I would say that the "sequencer" one is unneeded, however, if that is changed, it would break everyone's current application of it in their worlds/servers. The reason why I REALLY do want the 1/2 mode is because of its output dependency, which can be manipulated as described above.

All of this is to allow for more flexibility, funtionality, more compact, more friendly, and more clean operarions that is limited by an independent randomizer.

Im going to take a few days and think everything over. Probably going to just have added modes to the current randomizer, as having 2 would be redundant. Having a mode with output pulses is redundant as well, as you could just throw a pulse former gate on the side. And so is any type of timing mode, as that could be accomplished with a timer.

@chloeprince
Here's a solution with existing gates:
(optimized for your problem)

Mode 2 (On/OFF), is basically as you and I both described, 3 outputs & 1 input: When an input signal is applied, one of the outputs is chosen and stays ON until the input signal is turned off. Then all outputs are cleared "off".

Mode 3 (Pulse) gives us the same as mode 2, except its just a single pulse. The input must be turned back off, and cycled back on again to get a new random output pulse to one of the enabled outputs.

does it help?

@TheVoltrex

-I somewhat think there should be a way to adjust the time it takes to randomize to make simple decorations (like random flashing christmas tree lights)

By the way:
let's think about a randomizer with random output and random update time :-P

New gates/modes added via afbbb06.

Spent a solid few days thinking about an elegant implementation for this gate. What I ended up doing was adding modes to the existing randomizer, as well as creating a new randomized decoder gate. (Note that the only reason there was a separate gate was because their renders were very different, so they were implemented as such for consistency).

1. Original randomizer can now be shift clicked to disable individual sides.

2. Decoding randomizer gate has 3 outputs, where only 1 can ever be in. ABC randomizer. While the input is powered, the output is shifted every RS tick, just like before. However, their will always be 1 output enabled. Shift clicking the gate disables one of the sides, allowing for an AB randomizer.