 | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | |
| |
|
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-----
| | | | | | | | | | | | | | | | | | |
| |
|
> 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.
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-----
| | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
> 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | |
> > 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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
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
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
"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
| | | | | | | | | | | | | | | | | | | | | | | | |
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.
| | | | | | | | | | | | | | | | | | |
| |
|
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.
| | | | | | |
