should interpretations of the standard to a redirect hereDone. ALITTLESlow: t/c 03:16, 1 July 2015 (UTC)
- should update the style guide to remind editors to use Rule 4 for orientation
- should create dictionary entries for left, right, front, and back.
- Of the links on the Hassenplug page only the French one still works Captainowie (talk) 12:00, 1 July 2015 (UTC)
- Cool. Feel free to add that link to the page ;-) ALITTLESlow: t/c 12:19, 1 July 2015 (UTC)
- I did! The reason I mention it here was more to explain why the others weren't there as well. Captainowie (talk) 08:58, 3 July 2015 (UTC)
Is going faster than 1 bps good, bad, or indifferent? Bad:
- The standard says 1 bps, so faster is arguably non-standard.
- While a module shouldn't receive more than 1 bps, experience dictates otherwise. I often have seen the clearing or bypassing of a jam result in a surge which then resulted in a flooded and then jammed module downstream. Where is the fault here? In the module that ran faster than 1 bps.
- A module which runs faster than 1 bps will run on empty a lot, and that is boring.
- Such a module will rarely flood.
In my opinion, as you might guess, a module should not run significantly faster than 1 bps. Ideally it would run exactly 1 bps. Since that it not possible, it should err on running too fast rather than too slowly. ALITTLESlow: t/c 02:52, 28 July 2015 (UTC)
I claim that your point 1 above is not valid - the standard only specifies the rate at which a module should accept balls, not at which it should dispense them. That only puts a lower limit on the output rate.
In the forums, Hassenplug said And if a module is given an out-of-spec batch (more than 30 balls, as "often happens in the aftermath of clearing a jam") it should be 100% OK for the module to flood and fail. (see "Following the Spec") It doesn't matter if that batch passes through a module that is "running fast". to which ALittleSlow replied Where did the out-of-spec batch come from? It came from a module that ran faster than the spec. If a module creates an out-of-spec batch, it is out of spec. (repeated here so that we can keep all relevant discussion in the same place - I'm not sure if this place is better than the forum, but whatever, we can go back there if need be).
A module that runs fast can only create an out-of-spec batch if it's given one, whether by someone clearing a jam or by someone dumping a cupful of balls into its in-basket. A module will handle such a surge in one of a few ways:
- Bind - too many balls at once get stuck in some mechanism and things stop. This is poor design - not exactly out-of-spec, but definitely against best-practice.
- Leak - excess balls are ejected from the module, preferably at minimal velocity.
- Process them all - by running at faster than 1bps
- Store the excess in a reservoir and dispense them at 1bps. This is the best design.
Clearly we can't require that all modules be capable of item 4 - that would be changing the spec. If we require that a module not run faster than 1bps so that it doesn't flood a downstream module, then the only option left is to flood itself - either way there'll be a flood to clean up. The more modules a surge passes through before hitting a module that can't handle it, the more spread-out and the less damaging the surge becomes.
So, I claim that it boils down to running empty more often vs flooding less often. Boring vs reliable. I don't know about you, but I'll take Reliable any day of the week. Captainowie (talk) 11:11, 29 July 2015 (UTC)
- "the standard only specifies the rate at which a module should accept balls, not at which it should dispense them"
- By that interpretation, my module could hoard balls, then drop several batches of 30 balls in quick succession without violating the spec. Hogwash.
- Regardless, I concede to your summary (if I understand it correctly). If you run faster than 1 bps you are more boring and more reliable. If you pursue strategy 4 you are less boring and cover the faults of your neighbors (making the GBC more reliable), but at the expense of a more challenging design.
- "By that interpretation, my module could hoard balls, then drop several batches of 30 balls in quick succession without violating the spec."
- Absolutely it could (and Jeremy's Binomial module essentially does). But since the ball rate will be significantly above 1bps in the dump phase of your module, the downstream module doesn't have to handle it gracefully. I would put a module that does this in the same category as a module with an exit chute a meter above the table: not violating the spec per se, but also not going to be allowed to play :-) (unless of course a dedicated following module is built that can handle it - like the catcher from the Beehive or the one that follows Binomial).
- That's a fair summary of the argument - strategies 3 and 4 both make the GBC more reliable, but in different ways. I certainly think it's possible to go too far in one direction - I probably wouldn't think much of a module that could handle 10bps but ran empty 90% of the time - but it's not necessarily something that should see a module removed from display. Captainowie (talk) 09:47, 30 July 2015 (UTC)
There is some confusion between "bps" and "running empty". First, in every module I've ever seen, balls take some length of time to travel through the module. My Factory module runs at about 4bps, and balls take about 6 seconds to pass through it. If balls come in at 1bps, they leave at 1bps, and there should be about 6 balls in the module.
Someone please explain how a higher bps equates to running empty. (talk)
I guess "running empty" is sloppy terminology on my part. I really meant "running at less than capacity". Keeping your Factory module as the example for the purposes of discussion; if I remember correctly it has 4 'hands', each running at ~1bps. If it receives a stream of balls at 1bps, then you have three 'hands' (on average) not picking anything up. Or looking at it another way, each 'hand' will only collect a ball every fourth cycle. This is arguably less "interesting" than if you ran the whole thing at 1/4 the RPM (NB, I'm not recommending you do this, it's just for the sake of argument), and all 'hands' were picking up a ball on every cycle. Captainowie (talk) 10:15, 5 August 2015 (UTC)
-- To argue the original question: Going faster than 1bps is NOT bad because:
- The Standard says 1bps -- as stated above, the standard says "Accept balls at 1bps"
- To point 2 above, if the "fast" module was not present, would the jam condition still exist? -- yes, the surge of balls from clearing one jam would still go and cause another jam.
- Again, how does bps relate to running empty? I disagree that slowing my Factory module to 1/4 speed would make it more interesting (less boring). ([Hassenplug])
Rule 2: Baseplate included?
Some argue that the rules imply building on a baseplate and having an in-basket whose top layer is a row of bricks with the studs exposed. This would imply the actual maximum height is a baseplate plus 10 bricks, plus the studs on the top row of bricks. Others would argue that the baseplate should be thought of as the surface from which to measure from.
Can we come to a consensus on this? I would like to call it 10 bricks plus the top row of studs. To be more precise (assuming studs are 4 LDU high), this comes to 244 LDU. ALITTLESlow: t/c 03:31, 29 July 2015 (UTC)
Is it really that important to nail the height down to the LDU? As has been mentioned elsewhere, unevenness in tables is an issue, and I claim that that problem is an order of magnitude larger than whether or not to include the thickness of a baseplate in determining the height of your in-basket - allowing for table unevenness gives us stud/baseplate variations for free. I mean, are we also going to include the height of the LEGO logo that sits atop each stud? Captainowie (talk) 11:11, 29 July 2015 (UTC)
- No. I would prefer to define it as 10 bricks plus the top row of studs. This would include the LEGO logo. You can test this in isolation, and arrive at a GBC knowing you are compliant and therefore confident you have done your level best to be compatible. You can't test against the other factors until you get there. ALITTLESlow: t/c 22:09, 29 July 2015 (UTC)
I was under the impression that Type 1b was in the dustbin of history. Should the Type 1 and Type 1b designations be promoted or ignored? Are there any Type 1b advocates out there? ALITTLESlow: t/c 03:31, 29 July 2015 (UTC)
Me! Almost every one of my modules conforms to Type 1b. Why? I had started to type out something about making it easier to use one XL motor to power many modules, but I think that's a side-issue. There are two reasons:
- I've always done it that way.
- I like things to be neat.
However, now that I've started to participate in events with other people, I'm finding that that neatness comes at the expense of flexibility - I can't 'snake' my modules around a corner, for example. Maybe I'll change my ways in the future, who knows. I'm not sure about dispensing with the type designations. On the one hand it allows for expansion of the spec into potentially non-compatible areas (which would be OK, because it's a different Type). On the other hand, if it hasn't really been done in the last 10 years, chances are slim that it'll get done in the future Captainowie (talk) 11:11, 29 July 2015 (UTC)