Archive: 8 posts

---

So I've run into a bit of a problem using the randomizer. I have an input switch hooked up to a randomizer which then outputs one-at-a-time, pattern override input. This means every time the randomizer receives an input, it randomly changes its output. In this case, my outputs are emitters, however, I noticed that when several inputs are sent to the randomizer in quick succession (i.e. 0.1s apart) some of the outputs fail. I'm not sure why, either, as my emitters are set to emit once and they are emitting holo so there shouldn't be problems with overlapping objects. I'm thinking the problem might be the randomizer... and what would work better for me is to have a randomizer that randomly selects N of M outputs to activate each time an input is received. Anyways, I'm not sure if there is a way to program something like this. A set of multiple randomizers run through OR gates won't really work since N is a constant and if two randomizers select the same output then N is incorrect. Brainstorm away if you have ideas... thx!

2011-02-11 13:00:00 Author: Thegide Posts: 1465

---

Uhm... how about this? c = counter / = inverted ? = randomizer The number after the c is the counters' max value http://oi55.tinypic.com/9axon6.jpg

2011-02-11 13:22:00 Author: Shadowheaven Posts: 378

---

It might fail to randomize in specific time frame, it's there any difference between online and offline? In beta before patch 1.02 randomizer was failing on 0.1ms speed in online but that was fixed by pre-made patterns (that is now other problem). Also do you use something else between randomizer and emitters? you may have something on the way that generate lentency and you could also try to plug counters to randomizer to make sure that it's actually it

2011-02-11 13:24:00 Author: Shadowriver Posts: 3991

---

Forgive me if I'm incorrect on this, but I don't believe this is how the "Override Pattern" option works: I have an input switch hooked up to a randomizer which then outputs one-at-a-time, pattern override input. This means every time the randomizer receives an input, it randomly changes its output. I think when you override the pattern, you remove not just the timings, but the chosen pattern as well - so the "One-At-A-Time" selection is lost here. In which case the problem is very likely that some of your hits are going to the same node/emitter (which, if set to one-shot, will not trigger a new emission). Am I way off on this (or did I misunderstand your current settings, perhaps)? EDIT: In fact, even if you remove the Override Pattern option, the One-At-A-Time pattern will not necessarily work. If you look at the pattern examples on the LBPWiki page for the Randomizer (http://wiki.lbpcentral.com/Randomiser) One-At-A-Time pattern, you can see that turns 6,7, and 8 all hit the same out put. So you would need to insert set/reset switches between the randomizer and the emitters (which would cause a 0.1 sec latency).

2011-02-11 13:45:00 Author: v0rtex Posts: 1878

---

The solution I posted before would work if used as a buffer - you would only need to use an AND with the first column of counters, a NOT from the inverted counter and the external signal; just be sure to activate the buffer as soon as you activate the emitters. I don't think you can randomly activate N outputs in only one frame (unless you link the randomizer to all possible combinations, but it would require way too much wiring)

2011-02-11 13:46:00 Author: Shadowheaven Posts: 378

---

@vOrtex there is a small off time (probably one simulation frame off)when same output been randomized so it should trigger emitter, they made it that for reason you just said and to make it seamless

2011-02-11 14:46:00 Author: Shadowriver Posts: 3991

---

Hmm... well in my experimentation, it does not work this way. Perhaps I just had the timings wrong, but I have found that it does not trigger consecutive hits to the same output.

2011-02-11 15:04:00 Author: v0rtex Posts: 1878

---

In this case, my outputs are emitters, however, I noticed that when several inputs are sent to the randomizer in quick succession... In this configuration, both the randomizer and emitters are "rising edge triggered", meaning they only activate when the input signal changes from 0 to 1. So your problem is most likely that you're lacking a rising edge on either the randomizer input (which causes the randomizer not to make a new selection), or on the emitter input (which causes the emitter not to fire). If you happen to be triggering the input very fast (more than 15Hz) you will sometimes not get a rising edge on the randomizer, because the signal is only recalculated at 30Hz - this is a fundamental limitation of the simulation. If that's not the problem, then the problem will be that you're lacking a rising edge on the emitter inputs, which will occur every time the randomizer happens to pick the same output twice in a row. To avoid this, ensure that whatever signal you're using to trigger the randomizer is a single-frame pulse (which I'll refer to as the "clock" signal), and for each output from the randomizer, connect it to two-input AND gate, and feed the "clock" signal into the other input of each AND gate. The result should be that the output from each AND gate will only go high for a single frame each time the input is clocked, so when you feed these into the emitters, you're guaranteed that the emitter will fire every time the randomizer is clocked, but, again, you're still limited to a 15Hz clock speed. If you need it to work faster than 15Hz, there's a solution which involves using two out-of-phase randomizers, but you'd also need two copies of each emitter, and may also require significant changes to whatever you're using to trigger it.

2011-02-11 21:45:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.