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