There should be a page for what the GBC standard is, so users who are creating articles and/or edits knows if what's on the page is true or not. Not only that, readers (like me) might be unfamiliar of what the GBC standard is and what rules are placed that make some creations pass it or not pass it. For example, on the article at Great_ball_contraption#Single_File, it says "Type 1". This and other values such as "No" raises questions to the viewer:
- What conditions make a creation go under 'Type 1'?
- Are there other types, such as 'Type 2', 'Type 3', etc. ?
- Why doesn't this creation follow it?
- If I make a module myself, how will I know how to follow these rules?
- And other questions not listed..
|Posted by SamanthaNguyen on 18 March 2015 at 02:04.|
Agree. I have so far leaned toward referring people to Steve Hassenplug's teamhassenplug.org GBC page as that has the canonical rules. But those are good questions. I've been mulling over an article that would be more than just a regurgitation of the rules. This is probably content I should give some priority to.
|Posted by ALittleSlow (administrator) on 18 March 2015 at 03:18.|
If this website is to be a community-driven, one-stop-shop GBC resource, then it makes sense to host the canonical rules here (as perhaps a page that's immune to editing by the vast majority of contributors).
|Posted by Captainowie on 2 June 2015 at 13:38.|
Is there anyone who really cares about anything other than "type 1"? I don't think anyone is browsing this wiki to find modules for any other type, so it makes little sense to include that information. Seems better to just label other types as obsolete and rename this column to "deviations from the standard" (or similar - maybe just "notes"). It seems likely that visitors are looking for good example modules and pointing out such flaws will hopefully help prevent them from being replicated.
|Posted by Torso on 9 June 2015 at 11:35.|
Labeling the other types (I think the only other type is 1a) obsolete is a good idea. [Edit: the only other type is 1b. ]
|Posted by ALittleSlow (administrator) on 16 June 2015 at 14:25.|
Edited by ALittleSlow (administrator) on 1 July 2015 at 03:28.
For what it's worth, I build my modules exclusively to the Type 1b standard. But I guess that doesn't mean it's not obsolete!
If we're going to host the canonical rules here (which I think is a good idea), can we please remove the parenthesised (beams) from rule 2? Since the advent of studless technic, a 'beam' has been a thing different from a brick. Ten beams tall is a lot shorter than ten bricks tall.
|Posted by Captainowie on 28 June 2015 at 06:14.|
Curious why you built to Type 1b, Captain?
Oh, and I dropped "(beams)" from the standard.
|Posted by ALittleSlow (administrator) on 1 July 2015 at 03:30.|
Primarily so that I can hook the baseplates together and I know they'll all line right up. It also makes it easier to run a single axle down the line.
I saw that. It seems you also dropped the word "tall" from the end of the rules too! (Fixed already).
|Posted by Captainowie on 1 July 2015 at 10:23.|
The Type 1b standard was used shortly after the GBC standard was created, when we included a small GBC in a train layout. It easily allows for design of a non-ad-hoc layout.
I kind of laugh at the suggestion of a "best practice" for builders to not follow rule #2, and make the in baskets lower than 10 bricks tall. I've always thought the best practice would be to make your OUTPUT HIGHER than 10 bricks (or 10 1/4 bricks) so you can feed into a 10-brick-high basket.
It does cause problems if the input basket is too low, and balls bounce. Why encourage people to vary the height?
And, if the 1/4 brick height difference of the output causes a problem for your output, I'll bet there are going to be other problems with your module.
If your module can not output 1bps, the biggest problem is not the fact that downstream modules will be starved. The problem is that your module will be flooded as balls build up in it.
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".
I don't understand why a module running "too fast" would ever be a problem.
|Posted by Hassenplug on 7 July 2015 at 18:58.|
Great work on the new Standard page.
I have to agree on recommending a low in basket can be a bit misleading. Trying to be more bold, I've rewritten that section to put more emphasis on output height instead.
|Posted by Torso on 7 July 2015 at 21:41.|
Actually, that's kind of what is built in to the standard as it's written: Nowhere does it say "Modules should output balls at 10 bricks height"
Posted by Hassenplug on 7 July 2015 at 18:58.» I've always thought the best practice would be to make your OUTPUT HIGHER than 10 bricks (or 10 1/4 bricks) so you can feed into a 10-brick-high basket.
|Posted by Captainowie on 8 July 2015 at 09:56.|