| |
steve krass wrote:
> Best idea I have seen in a while.
> Will be quite a machine when done.
>
> You should try to paint or die a few balls a different
> color so spectators can follow a particular ball thruoghout the whole machine.
Having different coloured balls would also be cool because it would allow
machines to do things like sorting them so that one colour does one thing
and another colour does something different.
Mixing soccer and basket balls would let people do that and yet still
preserve Lego 'purity'.
However, introducing coloured balls isn't something you can 'just do'
without warning people because they may be relying on light sensor
readings to do specific things with them.
Another thought I had was that the organisers might want to consider
building a stage that has one input hopper and TWO outputs that sends
balls alternately to the two places. This would allow you to take
any machines that cause problems because they don't run fast enough
and put them after this special stage so they don't mess up the whole
timing of the system.
You'd also need to build a machine to combine two slow streams back into
a single 'standard rate' stream sometime later.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
In lugnet.robotics, Steve Baker <sjbaker1@airmail.net> wrote
<snip>
>
> Another thought I had was that the organisers might want to consider
> building a stage that has one input hopper and TWO outputs that sends
> balls alternately to the two places. This would allow you to take
> any machines that cause problems because they don't run fast enough
> and put them after this special stage so they don't mess up the whole
> timing of the system.
>
> You'd also need to build a machine to combine two slow streams back into
> a single 'standard rate' stream sometime later.
That's a just a cool idea in general, to have a branching arrangement. Maybe
some 'special' builders could produce modules that either divide or recombine
streams? I am really looking forward to seeing the GBC, and even though I've
never built anything like this, maybe I'll try to make a simple module. Steve,
this is a fabulous concept!
Cyndi
|
|
| |
Steve Baker writes:
> Another thought I had was that the organisers might want to consider
> building a stage that has one input hopper and TWO outputs that sends
> balls alternately to the two places.
Yes! Since the soccer and basket balls are the same physical size,
there is no reason why a module can't work with both. There is also
no reason why a module couldn't sort soccer balls out one side, and
basketballs out another.
To that end, you need a specification for a "Y" module, which has two
output faces. Also for a module which has two input faces! And a
module which is a 90-turning corner and a 270-turning corner. It's
pretty obvious what's needed for them; it just needs to be written down.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
tmassey@obscorp.com wrote:
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
>
> That way, you don't have to worry about too many Y's and not enough
> straight pieces! :)
Yeah - I agree. You need the 'average builder' to stick to a simple
straight-line standard one-size-fits-all module. If you don't then
everyone will want to build something esoteric and you'll get hardly
any simple modules of the kind that make this work.
I think that the organisers would be VERY wise to take a long a couple
of Y modules of their own design so that people who contribute machines
that are too slow don't cause a build-up of balls on their input side
and foul up the whole system. Those slower modules could be placed
downstream of a 'Y' module and thus keep working.
There is more than enough scope for innovation within the standard
specification to keep even the most sophisticated builder busy.
The art here for the average contributor is to make something that
fits within the basic rules and yet produces such an AMAZING show
that the audience will be crowding around that module going "Ooooh!"
throughout the show.
However, I imagine that the organisers need to break the rules for
their own work in order to be able to make the system continue to
play nicely even in the (likely) event that some of the modules
are balky.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
In lugnet.robotics, Russell Nelson <nelson@crynwr.com> wrote:
> Steve Baker writes:
> > Another thought I had was that the organisers might want to consider
> > building a stage that has one input hopper and TWO outputs that sends
> > balls alternately to the two places.
>
> Yes! Since the soccer and basket balls are the same physical size,
> there is no reason why a module can't work with both. There is also
> no reason why a module couldn't sort soccer balls out one side, and
> basketballs out another.
>
> To that end, you need a specification for a "Y" module, which has two
> output faces. Also for a module which has two input faces! And a
> module which is a 90-turning corner and a 270-turning corner. It's
> pretty obvious what's needed for them; it just needs to be written down.
I made a device that sends balls alternately down two chutes.
Balls enter through a 2x2 hole in the top, onto the centre of a 7L studless
beam, set up as a see-saw.
Which ever way a ball goes, it drops onto another, longer, see-saw that tilts
the first see-saw the other way to send the next ball down the other chute.
Balls exit though 2x2 holes in the bottom at each side.
I used two more studless beams (liftarms work well too) crossed over to do the
reversing links between the see-saws.
This contraption is about 13 bricks high and 4L deep, but could be made smaller
in height. Its advantage it that it doesn't need a motor. The minimum height
is dictated by the need for the energy from a ball dropping nto the lower
see-saw being more than enough to tilt both see-saws.
Of course this device won't sort balls by colour, but that's a slow process.
Also, soccer balls have black and white bits so you can't predict which bit a
light sensor will see, and hence whether the reading from a soccer ball will be
greater or less than the reading from a basketball.
I used the see-saw device with a vertical ball lifter, based on transmission
chain with a few track links. It was possible to over-run the see-saw device
with too many balls, so that two went the same way, but the through-put had to
be quite fast before that happened.
A module with 2 input faces would probably be a hopper with 2 chutes entering
it. The greatest problem I've had with ball contraptions is balls clogging in
the hopper - sometimes you need an agitator like they use in factories.
Mark
|
|
| |
Steve Hassenplug wrote:
> > That way, you don't have to worry about too many Y's and not enough
> > straight pieces! :)
>
>
> Yes, that's something to consider. It's possible everyone would create a 90 degree
> left-hand turn. Then what? :)
I think you can handle this with a little care in the design of the
rules.
If the table you are setting it up on is deep enough to permit it,
you could always use four 90 degree pieces in a LEFT/RIGHT/RIGHT/LEFT
sequence to keep the overall pipeline going straight. All you'd need
to do is to have the module design rules enforce more strict dimensions
on 90 degree pieces so that a LEFT/RIGHT/RIGHT/LEFT sequence wouldn't
result in a 'jog' in the line of modules - and to be sure it'll fit
the width of your tables.
That only works if you have the same number of left and right turns.
So simply write into the rules that everyone who submits a left hand
turn has to submit a corresponding right hand turn or they won't
be accepted.
Now, at *worst* you can only have one more pair of turns than you
needed - and you can always stick them at one end of the machine.
You'll need to design your table layout to have an equal number
of left and right turns too - but that should be simple enough.
Similarly, for Y pieces, you could make a rule that everyone who
submits a Y piece must also contribute a corresponding reverse-Y
to recombine the balls back into a single stream.
That guarantees that you'll never have too many Y's or reverse-Y's
and that all L's can be used...and it'll also dissuade most people
from making non-straight pieces because of the need to commit to
making two of them.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
| |
In lugnet.robotics, Mark Bellis wrote:
> A module with 2 input faces would probably be a hopper with 2 chutes entering
> it. The greatest problem I've had with ball contraptions is balls clogging in
> the hopper - sometimes you need an agitator like they use in factories.
Any operation involving a long sequence of events as in The Great Ball
Contraption (TGBC) is likely to be fouled up by failure of one of the events in
the chain - the so called weakest link.
Is there allowance for the fact that one of the modules may act up and not
deliver the requisite balls for the next module to act on?
Each module must at minimum be able to sense that there are indeed balls in the
input bin before acting on them and that there are balls in the output bin for
the next module to do its stuff.
A fail-safe mechanism would be such that the offending module can be by-passed
so that the sequence can still go on. I envisage Steve's train could be just the
thing to do the job, running hither and thither to make sure the whole
contraption is working.
But to complicate matters, the weakest link may not be just one module.
Different modules could act up at various times.
CS
|
|
| |
Russell Nelson <nelson@crynwr.com> wrote on 01/09/2005 04:20:10 PM:
> To that end, you need a specification for a "Y" module, which has two
> output faces. Also for a module which has two input faces! And a
> module which is a 90-turning corner and a 270-turning corner. It's
> pretty obvious what's needed for them; it just needs to be written down.
Or not: leave the standard as it is (except for specifying that the space
above the input belongs to the previous module), and have the organizers
build (or specificially request) out-of-spec modules to accomplish this.
That way, you don't have to worry about too many Y's and not enough
straight pieces! :)
That was something I saw with the Moonbase specification. A *lot* of the
samples they showed had just a single connection to their neighbor. Maybe
nobody wanted to build "boring" straight-through pieces. They also talked
about making modules configurable. But configurable in that context was
easy: a few simple pieces of non-moving Lego bolted on as necessary.
Here we're talking about moving, intelligent systems that I'm sure make a
number of assumptions that will not be easy to reconfigure on the fly.
Hence, having a specification that allows those assumptions be made with a
minimum of fuss seems like a strong point, not something that needs
adjustment...
Tim Massey
|
|
| |
In lugnet.robotics, Chio Siong Soh wrote:
> Is there allowance for the fact that one of
> the modules may act up and not deliver the
> requisite balls for the next module to act
> on?
First, test the modules as they are added to the system to make sure they
meet the minimum requirement. Second, watch the whole thing like a hawk, being
ready to shut it down to fix such problems. Third, there will have to be some
special-purpose modules within the system, such as the first "timing module", a
"return module" (like Steve's train), perhaps turn modules, etc. A very simple
bypass module can be built (I'm working in it) that can easily be adjusted in
length "on the fly" so a malfunctioning module can be hot-swapped out of the
line.
> Each module must at minimum be able to sense
> that there are indeed balls in the input bin
> before acting on them and that there are balls
> in the output bin for the next module to do
> its stuff.
At this point, most if not all of the modules I've seen can "run dry", so
there's not need for a module to check for itself.
> But to complicate matters, the weakest link
> may not be just one module. Different modules
> could act up at various times.
Yes. Babysitting will be needed.
--
Brian Davis
|
|
| |
> In lugnet.robotics, Mark Bellis wrote:
> > A module with 2 input faces would probably be a hopper with 2 chutes entering
> > it. The greatest problem I've had with ball contraptions is balls clogging in
> > the hopper - sometimes you need an agitator like they use in factories.
>
> Any operation involving a long sequence of events as in The Great Ball
> Contraption (TGBC) is likely to be fouled up by failure of one of the events in
> the chain - the so called weakest link.
>
> Is there allowance for the fact that one of the modules may act up and not
> deliver the requisite balls for the next module to act on?
Not really. :)
However, we're not expecting the GBC to run 100% of the time. It's not like letting
a train run in a circle for eight hours. There are all kinds of things going on at
the same time. In our testing, we seemed to run for about 20 minutes at a time,
before someone would say, "Stop..."
Then, we'd shut down the contraption, pick-up loose balls, check weak spots, and
power it up, again.
Generally, if one module doesn't work, we'll just take it out, slide the other
modules together, and start going again. Given that there are no "special" modules
(beyond the first and last modules) any other module can be placed in any location.
> Each module must at minimum be able to sense that there are indeed balls in the
> input bin before acting on them and that there are balls in the output bin for
> the next module to do its stuff.
I'd kind of like to see a module that won't "work" if it's empty. :)
|
|
| |
> Russell Nelson <nelson@crynwr.com> wrote on 01/09/2005 04:20:10 PM:
>
> > To that end, you need a specification for a "Y" module, which has two
> > output faces. Also for a module which has two input faces! And a
> > module which is a 90-turning corner and a 270-turning corner. It's
> > pretty obvious what's needed for them; it just needs to be written down.
>
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
Or create other "Types" That's the long-term plan.
Of course, any GBC that uses some of these other module types will require
considerabily more planning prior to set-up, and it will also make the whole
contraption less tolerant to the "weak-link" modules.
For example, if the whole contraption is laid out, and the splitter module doesn't
function, the whole contraption will not be able to run.
> That way, you don't have to worry about too many Y's and not enough
> straight pieces! :)
Yes, that's something to consider. It's possible everyone would create a 90 degree
left-hand turn. Then what? :)
>
> Here we're talking about moving, intelligent systems that I'm sure make a
> number of assumptions that will not be easy to reconfigure on the fly.
> Hence, having a specification that allows those assumptions be made with a
> minimum of fuss seems like a strong point, not something that needs
> adjustment...
right.
Steve
|
|
| |
> Steve Hassenplug wrote:
>
> > > That way, you don't have to worry about too many Y's and not enough
> > > straight pieces! :)
> >
> >
> > Yes, that's something to consider. It's possible everyone would create a 90
> > degree
> > left-hand turn. Then what? :)
>
> I think you can handle this with a little care in the design of the
> rules.
Actually, it's pretty interesting, if you consider how complex making a pair of
turns really is. If you make a 90 degree right hand turn on a 32x32 baseplate, the
module must output right next to it's own input. But, bins on a left-hand turn are
on opposite corners of the plate.
Again, a big problem comes when one of the turns don't "work". So, if you have
exactly four turns (two right, two left) and one doesn't work, then none of them can
be used.
In any case, there's not much you can do on two modules that you can't do on one,
more complex module. For example, the splitter/combiner could be built as one
module.
Even things like my "train" can be laid out as "one module". By switching the
direction of the train, instead of taking balls back to the beginning, it can just
carry them and deliver them to the next module downstream.
One challenge would be to make a module that can be configured as a straight
pass-through OR a turn.
At this point, we're not interested in making the standard more complex, and
increasing the difficulty of setting it up, when it really doesn't add any
functionality to the whole contraption.
Steve
|
|
| |
"Steve Hassenplug" <Steve@TeamHassenplug.org> wrote:
> Actually, it's pretty interesting, if you consider how complex making a
> pair of
> turns really is. If you make a 90 degree right hand turn on a 32x32
> baseplate, the
> module must output right next to it's own input. But, bins on a left-hand
> turn are
> on opposite corners of the plate.
Why not universalize the standard so that a module that can turn must be
configurable to turn either to the left or the right? A few ways this could
be done are movable output stages, EG a sliding or drop-in output that can
be placed where needed.
> Again, a big problem comes when one of the turns don't "work". So, if you
> have
> exactly four turns (two right, two left) and one doesn't work, then none
> of them can
> be used.
Have the standard changed so that a module that can turn must also accept a
feed from the back if needed.
> In any case, there's not much you can do on two modules that you can't do
> on one,
> more complex module. For example, the splitter/combiner could be built as
> one
> module.
Question on the splitter/combiner modules, will there be rules for what
modules can be placed before/after them? Obviously it's not going to be
much use if someone builds a mechanical feeder that doesn't care what balls
it passes on unless there's a splitter/combiner module ahead of it, and not
one behind it.
> Even things like my "train" can be laid out as "one module". By switching
> the
> direction of the train, instead of taking balls back to the beginning, it
> can just
> carry them and deliver them to the next module downstream.
The only problem I can see there is that a module which expects the train
will have to be equipped with a holding crate which can hold a certain
number of balls, if there are going to be multiple pickup and delivery
points, in case a train is overfilled for some reason.
> One challenge would be to make a module that can be configured as a
> straight
> pass-through OR a turn.
That's not so much a challenge as a necessity. If all modules had standard
left-feed and straight-feed rules to obey, you could theoretically make any
module into a turn module without any trouble at all, as per my earlier
statement above.
> At this point, we're not interested in making the standard more complex,
> and
> increasing the difficulty of setting it up, when it really doesn't add any
> functionality to the whole contraption.
Well, perhaps some things need more complexity, although I would agree a
standard anyone can use is preferable. The big challenge is getting the
degree of complexity as best you can for all parties which will be involved.
Cheers ...
Geoffrey Hyde
|
|
| |
tmassey@obscorp.com writes:
> Or not: leave the standard as it is (except for specifying that the space
> above the input belongs to the previous module), and have the organizers
> build (or specificially request) out-of-spec modules to accomplish this.
I agree with the principle of simplicity. I notice that the spec
implicitly allows you to make an interior corner simply by rotating
the input bin by 90 degrees clockwise as viewed from above. Any
module which has its input bin in the corner of its module will work
this way. After all, the specification specifies the output in terms
of a horizontal plane, and *doesn't* specify the path of the ball as
it goes through the opening in the plane.
So every module is an interior corner module already! And if you have
four people build their modules on a 32x32 baseplate with input and
output boxes to match, you have a continuous loop.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
Steve Baker writes:
> So simply write into the rules that everyone who submits a left hand
> turn has to submit a corresponding right hand turn or they won't
> be accepted.
Excellent idea! But it's even easier than that!! Do NOT change the
specification on this account. It's not necessary! If somebody wants
to make a single module which can be split into a right-hand turn and
left-hand turn, they can do it without any change in the spec. Their
module will simply have its own (spec-conforming) internal pair of
input and output boxes that happens to be at right angles to the rest
of the Contraption.
--
--My blog is at angry-economist.russnelson.com | Freedom means allowing
Crynwr sells support for free software | PGPok | people to do things the
521 Pleasant Valley Rd. | +1 315-323-1241 cell | majority thinks are
Potsdam, NY 13676-3213 | +1 212-202-2318 VOIP | stupid, e.g. take drugs.
|
|
| |
> > At this point, we're not interested in making the standard more complex,
> > and
> > increasing the difficulty of setting it up, when it really doesn't add any
> > functionality to the whole contraption.
>
> Well, perhaps some things need more complexity, although I would agree a
> standard anyone can use is preferable. The big challenge is getting the
> degree of complexity as best you can for all parties which will be involved.
>
> Geoffrey Hyde
Is there something that a module builder can not do because the standard is too simple?
Steve
|
|
| |
In lugnet.robotics, Steve Hassenplug wrote:
> > > At this point, we're not interested in making the standard more complex,
> > > and
> > > increasing the difficulty of setting it up, when it really doesn't add any
> > > functionality to the whole contraption.
> >
> > Well, perhaps some things need more complexity, although I would agree a
> > standard anyone can use is preferable. The big challenge is getting the
> > degree of complexity as best you can for all parties which will be involved.
> >
> > Geoffrey Hyde
>
>
> Is there something that a module builder can not do because the standard is too simple?
>
> Steve
Not to oversimplify, but I mean if the 'standard' for the ball contraption is 32
studs from the front of the hopper to the back edge of the baseplate, and thus I
personally would probably grab a 32 x 32 stud baseplate to build on, thus the
'in' hopper would be in the bottom left hand corner anyway, wouldn't my module,
by its very nature, be able to be placed 'in line' with the other ones, or 90
degrees, placing the hopper in the same location?
I think that making 90 degree turns (only to the right) would be able to be done
on many modules, just the way they are--phenominal ASCII graphix below!
XXXXXXXXXXYYYYYYYYYY
X XY Y
X XY Y
X XY Y
X XY Y
OOO XOOO YOOO
O O XO O YO O
OOOXXXXXXXOOOYYYYYYYOOO
XXXXXXXXXX
X X
X X
X X
X X
OOO XOOOYYYYYYY
O O XO O Y
OOOXXXXXXXOOO Y
Y Y
Y Y
Y Y
Y Y
YYYYYYYYYY
OOO
O O
OOO
X-Module 1
Y-Module 2
O-Input/Output Bin
See, if you leave both 'outer edges' of the bin open, both orientations work
But maybe I'm missing something.
Dave K
|
|
| |
In lugnet.robotics, tmassey@obscorp.com wrote:
> news-gateway@lugnet.com wrote on 01/10/2005 10:01:48 AM:
>
> > > Is there something that a module builder can not do because the
> > standard is too simple?
> >
> > Not to oversimplify, but I mean if the 'standard' for the ball
> > contraption is 32
> > studs from the front of the hopper to the back edge of the
> > baseplate, and thus I
> > personally would probably grab a 32 x 32 stud baseplate to build on, thus the
> > 'in' hopper would be in the bottom left hand corner anyway, wouldn'tmy module,
> > by its very nature, be able to be placed 'in line' with the other ones, or 90
> > degrees, placing the hopper in the same location?
>
> That assumes that there is nothing in front of the hopper. There is
> nothing to say that you are limited to a module 32 studs deep. If you
> choose to build it that way, great, but there is nothing that says you
> can't build a 3-foot-deep module (and according to the spec, that *should*
> be longer than deep, so it would have to be at *least* 3 feet long!). In
> that case, it could not turn the corner as you've described.
>
> However, to me, that's even more reason to leave the spec alone. You have
> described a simple way to make a spec-compliant module that makes right
> corners. Therefore, there is no reason to define corner pieces! They're
> already defined! :)
>
> Tim Massey
I completely agree with that assessment. However, the premise is that I'm using
a 32x32 baseplate with the hopper in the bottom left hand corner--using that
premise, the module can be used either in-line, or 90 degrees. If one does not
use the 32x32 baseplate with the hooper in the bottom left-hand corner, then all
bets are off ;)
Dave K
|
|
| |
news-gateway@lugnet.com wrote on 01/10/2005 10:01:48 AM:
> > Is there something that a module builder can not do because the
> standard is too simple?
>
> Not to oversimplify, but I mean if the 'standard' for the ball
> contraption is 32
> studs from the front of the hopper to the back edge of the
> baseplate, and thus I
> personally would probably grab a 32 x 32 stud baseplate to build on, • thus the
> 'in' hopper would be in the bottom left hand corner anyway, wouldn'tmy • module,
> by its very nature, be able to be placed 'in line' with the other ones, • or 90
> degrees, placing the hopper in the same location?
That assumes that there is nothing in front of the hopper. There is
nothing to say that you are limited to a module 32 studs deep. If you
choose to build it that way, great, but there is nothing that says you
can't build a 3-foot-deep module (and according to the spec, that *should*
be longer than deep, so it would have to be at *least* 3 feet long!). In
that case, it could not turn the corner as you've described.
However, to me, that's even more reason to leave the spec alone. You have
described a simple way to make a spec-compliant module that makes right
corners. Therefore, there is no reason to define corner pieces! They're
already defined! :)
Tim Massey
|
|
| |
"Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message
> Is there something that a module builder can not do because the standard
> is too simple?
Yes. Currently it's not being able to make turns in both directions with
the hopper feed setup the way it is. Someone did point out that there would
be a lot of wasted space if there was a large assembly of machines. I think
standards should be there to be helpful, not cumbersome.
Cheers ...
Geoffrey Hyde
|
|
| |
>
> "Steve Hassenplug" <Steve@TeamHassenplug.org> wrote in message
>
> > Is there something that a module builder can not do because the standard
> > is too simple?
>
> Yes. Currently it's not being able to make turns in both directions with
> the hopper feed setup the way it is.
That's really not true. As a module builder, you can make all the turns you want.
This one makes a whole bunch:
http://www.brickshelf.com/cgi-bin/gallery.cgi?i=1049772
If you can't figure out how to put the output in the correct place, with respect to
the input, that's not a problem with the standard.
See, there are two different things being talked about here.
A) Before Brickfest, many people will be building modules for the GBC
B) At Brickfest, we'll be assembling the modules to create a complete Great Ball
Contraption.
(A) should be possible, no matter how the input/output is arranged.
And, I have no doubt when we're at Brickfest we will succeed at (B), given the
current standard. Adding turns and things will only make that much more difficult.
If people are not able to make standard modules, that will be a bummer. But, I
don't really see it as a issue.
Steve
|
|
|
