Proof of concept only, utilising P-tracks & D-tracks, no traditional booster involved. Note: additional info in case you happen to be new to station building: destination selection is done separately, this is just the "engine room" so to speak.
Version 3.2
I think this should be ready for real-world implementation
(just add destination selection)
- Updated track design inspired by Bill-Zarr's excellent simple design, now it costs even less and takes up a lot less room.
- fixed issue with wrong cart re-fill order.
- tidied up overflow control
- tidies up arrival layout
- added flood guard for arrival (just showing the concept so not implemented for other parts)
Also very compact solution. (page 2) (note: orientation specific)
----------------------------------------------------------------------------------------------
Also, another rider detection launcher design based on Alfalis' loops booster (http://http://www.minecraftforum.net/vi ... 7#p4266627)
Again, proof of concept only:
You step onto the pressure plate, which releases the cart into the boosting circle, you wait for a few loops then hop on; the release of the pressure plate activates a monostable circuit to release you from the loop and send you onto main track. The momentum gathered would allow you to travel quite some distance without further boost.
New version now based on the concept of a German player's design utilising traditional glitch booster (soz can't remember his name), which I think may have informed Etho's concept, which in turn informed my V.1 & maybe Tenkin's design.
Features:
- Rider detection - hop-in to go
- 8 cart dispenser, easily scalable!
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
- [new!] cart queue disruption tolerant! (this I believe is a first for designs which aren't reliant on glitch boosters or door-PEZ booster)
Sorry, I don't know how to record video, so no video
The queue handling is the best so far, the building cost is reduced, and this would be the easiest to build so far. It is very long... I believe clever track designs could reduce the length of the whole thing by doubling back/folding the design in two etc.
Potential to do:
A RSNOR at arrival to prevent cart pile up if another cart arrives before first is sent away.
Features:
- Rider detection - hop-in to go
- 5 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video
The queue handling is a bit better then V.1, and the building cost and size and difficulty is greatly reduced. This is only a 5-cart version, but the system is easily expandable. And it is even possible to sacrifice compactness to make it flat.
Again, a bit of redstone work could help so that if the replacement cart doesn't come, it would keep calling until one is sent; this shouldn't be too hard, a RSNOR latch should do, but I'm too tires right now
Features:
- Rider detection - hop-in to go
- 8 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video
Known problem:
The system is depending on "one cart out, one cart in"; it is ok if extra carts arrive into the station as the overflow prevention will prevent a clog up; but if there are fewer arrivals then departure, the dispenser wouldn't know, and you will have a gap in the line-up, which will need manual cart replacement... This can probably be solved by some redstone genius. help please?
EDIT1:
forgot to mention: the dispenser idea is inspired by Etho's LP series episode 55. Great channel on Youtube, go check it out if you haven't :smile.gif: http://www.youtube.com/user/EthosLab#g/u
What are the specs? Number of powered rails, redstone etc, and size?
Yes, I know, I'm lazy
Well, these specs won't mean much at this stage, this is only a proof of concept, so there is probably still room for improvement, esp if with the help of a redstone guru.
As for the rails, in the dispenser section, each slice (2 wide) will need at least 1 D-rail & 3 P-rail & 1 normal (I used one extra P instead of the normal rail), and 1 P-rail + 1 normal to send car to the next slice.
For the departure launcher, at least 2 P-rail for the up ramp, preferably 3; 2 P-rail for launching; and 2 P-rail (maybe 1 will do) for "pulling" the rider-cart away from standby position.
For the arrival, the automated return will need 2 P-rails, the over flow prevention will need minimum 4 or 5 P-rails.
As for redstone, they are cheap, I'm not motivated to count them at all :smile.gif:
Even though this looks somewhat impressive, it's just big.
It doesn't seem worth the size and effort to build, when you can build something that's somewhat just as useful, but way easier to build.
The only original and smart thing, imo, was the departure where you have a cart ready all the time and it detects when you jump in.
Serious question; what were you trying to accomplish ? To build a station without the glitched booster carts ? I might have missed something, since I can't figure what this big machine should benefit over smaller ones.
The design goals are: No1. You don't talk about fight club...
Avoid glitch booster completely
Have a bank of carts to call on (carts storage & dispenser)
Essentially, there are three designs showcased here, all observing the rule#1 listed above:
1. the departure mechanism - I'm glad you like it; even though it's quite simple really, based on what I saw on the forum, this particular design might be a first.
2. the arrival mechanism - I prefer things that are simple and preferably won't accidentally break.
3. the dispenser - this is the real hard part, as it is trying to fill the big shoe left/going to be left by PEZ dispenser; PEZ dispenser RELIES on glitch booster to work, so we must find alternative despite our love of it.
So, please, my ear is all open if you have a better idea regarding the dispenser; but so far this proof of concept seems to be the best design execution based on the idea in Etho's episode 55 (which itself may have been based round an existing horizontal storage/dispenser design by a German guy, which was relying on glitch booster).
I do have a couple of other ideas to try, but it would be great if some redstone guru can help with issues listed below:
#1 shrink the circuit I used (when a cart leaves a ramp, the circuit turns off this ramp track and calls previous track to send a cart, which does not turn off until a cart is indeed sent.)
#2 add circuit which would allow the system to know and fix the cart gap issue. (I may have an idea for this...)
If the above issues are fixed, at least we will see a working design for a multiple cart dispenser that avoids glitch booster completely, despite being big.
Features:
- Rider detection - hop-in to go
- 5 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video :tongue.gif:
The queue handling is a bit better then V.1, and the building cost and size and difficulty is greatly reduced. This is only a 5-cart version, but the system is easily expandable. And it is even possible to sacrifice compactness to make it flat.
Again, a bit of redstone work could help so that if the replacement cart doesn't come, it would keep calling until one is sent; this shouldn't be too hard, a RSNOR latch should do, but I'm too tires right now :tongue.gif:
Can't you make a PEZ dispenser using doors not boosters?
I'm a bit suspicious of the reliability of door-PEZ, it could break in laggy situations such as with old computer or SMP. So I try to find an alternative.
Actually, CaptainSparkles just made a dispenser, completely vanilla with no glitch-booster.
Clever :tongue.gif:
It's very reliant on the correct friction and timing, but as long as the momentum is well calibrated up the top, this should work pretty well. :smile.gif:
Actually, CaptainSparkles just made a dispenser, completely vanilla with no glitch-booster.
Clever :tongue.gif:
It's very reliant on the correct friction and timing, but as long as the momentum is well calibrated up the top, this should work pretty well. :smile.gif:
You could probably set it up to work perfectly with the button's timing with the right lengths of track.
I watched the episode you mentioned, and I didn't really understand the second rail he made.
So I came up with a version of the first one, that don't **** up carts totally if you press more than one out.
You just make detector rails to get the "next in line"-cart go. I can post a screen if you want to.
in my V.1, I didn't use the straight forward detector-calling-next-cart approach because two reasons: 1. in the design the towers are too tall and requires too long a powered section, the activation time of a straight detector won't be long enough to send cart through reliably; 2. I did it that way trying to solve a certain worry - what if there is no next cart? what is the next cart arrives late/out-of-sinc? Unfortunately my V.1 design did not exactly address that issue well enough.
My way of addressing Etho's issue was to prevent multiple call-out by ensuring the cart is only called when someone actually rides a cart and go past a certain point. But this only solve half of the issue as described in my V.1 :tongue.gif:
Well, my V.3 is out, I believe this is quite close to what I want to do, all design parameters fulfilled - apart from the size being ...a bit big :tongue.gif:
p.s. That long slide dispenser by captainsparkle is quite clever; but it's a bit too ...um... fuzzy(?) It's not precise enough for my liking... Hmmm.... I may have an idea for V3.5 or V4 :tongue.gif:
Dang, I just finished rebuilding a variant of your first version which handles the queue problem through redstone. I think what I have would work better for large numbers of carts, as each module is only two wide*. However, they are much longer* (with nice big redstone wings) so it is worse for small numbers of carts.
Also, it will break occasionally because of the old booster glitch, but once that is gone it should work fine.
Logic:
Two detector rails per component: DRA and DRB
One "bridged" RS-NOR latch per component: RS
DRA(i) turns on RS(i+1).
DRB(i) turns off RS(i).
First position in queue: i=0
The on-state of each RS-NOR latch is connected to a repeater, which feeds directly into the on state of the next RS-NOR latch, preventing them from being reset until the queue is full up to that position. It also has the effect of causing all the carts to move simultaneously.
My design is not very compact, so it would be interesting to see what you could with this logic.
* These dimensions are similar to your original version, so the module length is one side of the rectangle and the width is additive to get the other.
(12 high, 14 long, 2 wide)
EDIT: download link: http://www.mediafire.com/?ll65talm71yg6ml just look for the big thing. Also in this map is a departure mechanism (enter the door, which locks it and calls cart, enter cart, which launches and unlocks door) an arrivals overflow handler (stick um in a loop til the other guy is out of the way) and a few simpler concepts.
I am not sure if you have figured out this problem yet, but I noticed in you V.1 and V.2, you didn't have a way to keep minecarts at the front of your dispenser(i.e. If you had more minecarts leaving than you did returning) without using the old minecart booster glitch. If you haven't, then I have posted a proof of concept of just such a creation. Mind you, it isn't optimized at all. Click here for solution
I've found this a very good design, but I have noticed that sometimes the "booster cart" that pushes the departure cart doesn't go far enough on the pressure plate, and the new "booster cart" pushes against it (the new "departure cart") several times, and sometimes the third new "booster cart" comes by, adding to the chaos, pushing it but putting an extra minecart on the system.
*snip*
The on-state of each RS-NOR latch is connected to a repeater, which feeds directly into the on state of the next RS-NOR latch, preventing them from being reset until the queue is full up to that position. It also has the effect of causing all the carts to move simultaneously.
My design is not very compact, so it would be interesting to see what you could with this logic.*snip*
Wow! How wonderfully mechanical :biggrin.gif: and it looks like the style of a redstone oldtimer too!
I will need to take some time to understand the wiring, but it looks really nice.
I quite like your H-shaped switching mechanism too, and I think it is a very practical solution which is not too resource heavy either, and if a queuing system can be added, it will do nicely on a SMP server.
The arrival looping delay is a great idea; I've been using multiple arrival points redirection in my own world (6 bays? 8 bays? can't remember), which was based on the old rails but can be easily converted into the new system, I think if it were to be implemented on a big SMP world, the looping system can be a great backup and will help conserve resources: say the normal expected simultaneous arrivals are estimated to be no more then 4, then we could have 5 arrival bays plus the looping delay as the backup in case all bays are full. My current system will re-route the incoming cart to go on a big circle and re-attempt entry, but your method is a more elegant solution, which will use less resource as well.
As for the departure lock out, it would be great is the destination selection is also done in the locked space, also I think it would be a good idea to have an exit solution that will be hooked onto the RS-NOR reset as well, so if the rider changes mind, there can be a clean exit.
Some great ideas! I'll sure start borrowing your H-intersection idea right away if you don't mind :tongue.gif:
In fact, instead of my centralised 9 destination stations in my own world, these kind of intersections could work well in the form of a road network, not unlike the roads we use everyday :smile.gif: which is hopefully less resource hungry and easier to build too :smile.gif:
I am not sure if you have figured out this problem yet, but I noticed in you V.1 and V.2, you didn't have a way to keep minecarts at the front of your dispenser(i.e. If you had more minecarts leaving than you did returning) without using the old minecart booster glitch. If you haven't, then I have posted a proof of concept of just such a creation. Mind you, it isn't optimized at all. Click here for solution
Sounds like a great idea! so the circuit should "know" how many carts are loaded hence deciding where to send an arrival cart into the system or to redirect the cart to overflow control.
But is it possible for you to put up some signs so we know what to do? the first thing I did accidentally messed up the whole system :tongue.gif: I think the final solution based on your design will have to be a sealed-core structure with good anti-dumbness design built into both the entry and exist. For example, because there were quite a few times when I accidentally destroyed large sections of my own station due to flooding, my current station is built in a way that both the engine room and the destination selection circuits are water-tight :tongue.gif:
Doing a counter did originally drift past my mind when I was doing V.1, but I'm simply not up to the task of wiring a counter, so it was a very remote fleeting thought... hahahah :biggrin.gif:
We do need to get that circuit down to scale though, then I think this could be a vry elegant solution :smile.gif:
I've found this a very good design, but I have noticed that sometimes the "booster cart" that pushes the departure cart doesn't go far enough on the pressure plate, and the new "booster cart" pushes against it (the new "departure cart") several times, and sometimes the third new "booster cart" comes by, adding to the chaos, pushing it but putting an extra minecart on the system.
Thank you :smile.gif:
What you are describing sometimes does happen when the world is reloaded - the standby cart would be loaded sideways and it takes the booster/next standby cart a few pushes to send you on your way, but eventually they all go on their way... the worst case I had took 4~5 seconds of bumping :tongue.gif: but that was due to the system was still in testing stage and I accidentally bumped the cart out of where it should be (the glass box wasn't in place properly; once the cart launching sequence has been run once or twice, it should be quite smooth, especially now the "follow-through" P-rails are always powered in the published designs (originally they were reliant on the stone plate, which did cause a few failures) The positioning of the carts in relation to the stone plate and the rails are critical, which is why the whole thing is encased in glass, and that normally you don't get to "touch" the carts and bump them out of place.
But the "third cart"??? AH HA!! I know what you are talking about now... you are using my V.2 design right? That's the only one that has the "next-cart-calling" hooked up to the pressure plate... with that design, if there is a delay in launching, it could mess everything up. Thank you very much for pointing it out. This further strengthened the case of designing the cart-calling to be done on the exit rather then at the departure point itself.
p.s. now after reviewing my test ground, OMG I have so many typos :sleep.gif:
Version 3.2
I think this should be ready for real-world implementation
(just add destination selection)
- Updated track design inspired by Bill-Zarr's excellent simple design, now it costs even less and takes up a lot less room.
- fixed issue with wrong cart re-fill order.
- tidied up overflow control
- tidies up arrival layout
- added flood guard for arrival (just showing the concept so not implemented for other parts)
pic:
world:
http://www.mediafire.com/?ag4gtfvap682lb7
I might update my own main station with this system then post if I've got nothing better to do :tongue.gif:
----------------------------------------------------------------------------------------------
Bill_Zarr's design:
Excellent compact solution. (page 2) (note: orientation specific)
----------------------------------------------------------------------------------------------
last_username's design:
Also very compact solution. (page 2) (note: orientation specific)
----------------------------------------------------------------------------------------------
Also, another rider detection launcher design based on Alfalis' loops booster (http://http://www.minecraftforum.net/vi ... 7#p4266627)
Again, proof of concept only:
You step onto the pressure plate, which releases the cart into the boosting circle, you wait for a few loops then hop on; the release of the pressure plate activates a monostable circuit to release you from the loop and send you onto main track. The momentum gathered would allow you to travel quite some distance without further boost.
--------------------------------------------------------------------------------------------------------------------
Version 3:
New version now based on the concept of a German player's design utilising traditional glitch booster (soz can't remember his name), which I think may have informed Etho's concept, which in turn informed my V.1 & maybe Tenkin's design.
Features:
- Rider detection - hop-in to go
- 8 cart dispenser, easily scalable!
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
- [new!] cart queue disruption tolerant! (this I believe is a first for designs which aren't reliant on glitch boosters or door-PEZ booster)
Pic:
test world download:
http://www.mediafire.com/?p152hcadhdclmq6
Sorry, I don't know how to record video, so no video
The queue handling is the best so far, the building cost is reduced, and this would be the easiest to build so far. It is very long... I believe clever track designs could reduce the length of the whole thing by doubling back/folding the design in two etc.
Potential to do:
A RSNOR at arrival to prevent cart pile up if another cart arrives before first is sent away.
--------------------------------------------------------------------------------------------------------------------------
Version 2:
New version now based on a modified version of the diagonal track with door regulator concept from Paghira74, original thread: viewtopic.php?f=1020&t=151936&p=2522131#p2522131
Features:
- Rider detection - hop-in to go
- 5 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video
test world download:
http://www.mediafire.com/?zeb8nsr7gofcj
The queue handling is a bit better then V.1, and the building cost and size and difficulty is greatly reduced. This is only a 5-cart version, but the system is easily expandable. And it is even possible to sacrifice compactness to make it flat.
Again, a bit of redstone work could help so that if the replacement cart doesn't come, it would keep calling until one is sent; this shouldn't be too hard, a RSNOR latch should do, but I'm too tires right now
--------------------------------------------------------------------------------------------------------------------------
Version 1:
Features:
- Rider detection - hop-in to go
- 8 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video
test world download:
http://www.mediafire.com/?x6xnxnn54v6jsmg
Known problem:
The system is depending on "one cart out, one cart in"; it is ok if extra carts arrive into the station as the overflow prevention will prevent a clog up; but if there are fewer arrivals then departure, the dispenser wouldn't know, and you will have a gap in the line-up, which will need manual cart replacement... This can probably be solved by some redstone genius. help please?
EDIT1:
forgot to mention: the dispenser idea is inspired by Etho's LP series episode 55. Great channel on Youtube, go check it out if you haven't :smile.gif:
http://www.youtube.com/user/EthosLab#g/u
EDIT2:
Added version 2, now based on a modified version of the diagonal track with door regulator concept from Paghira74, original thread: viewtopic.php?f=1020&t=151936&p=2522131#p2522131
EDIT3:
V.3!! I think this is VERY close to final...
EDIT4:
V3.2; plus another rider-detection launcher
EDIT5:
adding Bill_Zarr & last_username designs
Edit6: Modifying version number to prevent confusion, X for experimental :tongue.gif:
Well, these specs won't mean much at this stage, this is only a proof of concept, so there is probably still room for improvement, esp if with the help of a redstone guru.
As for the rails, in the dispenser section, each slice (2 wide) will need at least 1 D-rail & 3 P-rail & 1 normal (I used one extra P instead of the normal rail), and 1 P-rail + 1 normal to send car to the next slice.
For the departure launcher, at least 2 P-rail for the up ramp, preferably 3; 2 P-rail for launching; and 2 P-rail (maybe 1 will do) for "pulling" the rider-cart away from standby position.
For the arrival, the automated return will need 2 P-rails, the over flow prevention will need minimum 4 or 5 P-rails.
As for redstone, they are cheap, I'm not motivated to count them at all :smile.gif:
EDIT: typo
btw looks awesome :smile.gif:
The design goals are:
No1. You don't talk about fight club...Avoid glitch booster completely
Have a bank of carts to call on (carts storage & dispenser)
Essentially, there are three designs showcased here, all observing the rule#1 listed above:
1. the departure mechanism - I'm glad you like it; even though it's quite simple really, based on what I saw on the forum, this particular design might be a first.
2. the arrival mechanism - I prefer things that are simple and preferably won't accidentally break.
3. the dispenser - this is the real hard part, as it is trying to fill the big shoe left/going to be left by PEZ dispenser; PEZ dispenser RELIES on glitch booster to work, so we must find alternative despite our love of it.
So, please, my ear is all open if you have a better idea regarding the dispenser; but so far this proof of concept seems to be the best design execution based on the idea in Etho's episode 55 (which itself may have been based round an existing horizontal storage/dispenser design by a German guy, which was relying on glitch booster).
I do have a couple of other ideas to try, but it would be great if some redstone guru can help with issues listed below:
#1 shrink the circuit I used (when a cart leaves a ramp, the circuit turns off this ramp track and calls previous track to send a cart, which does not turn off until a cart is indeed sent.)
#2 add circuit which would allow the system to know and fix the cart gap issue. (I may have an idea for this...)
If the above issues are fixed, at least we will see a working design for a multiple cart dispenser that avoids glitch booster completely, despite being big.
but love the idea! Here take some pig!
Need I say more?
The new version is now based on a modified version of the diagonal track with door regulator concept from Paghira74, original thread: viewtopic.php?f=1020&t=151936&p=2522131#p2522131
Features:
- Rider detection - hop-in to go
- 5 cart dispenser
- Automated calling for next cart to standby
- Automatic cart return on arrival
- Overflow prevention
Pic:
Sorry, I don't know how to record video, so no video :tongue.gif:
test world download:
http://www.mediafire.com/?zeb8nsr7gofcj
The queue handling is a bit better then V.1, and the building cost and size and difficulty is greatly reduced. This is only a 5-cart version, but the system is easily expandable. And it is even possible to sacrifice compactness to make it flat.
Again, a bit of redstone work could help so that if the replacement cart doesn't come, it would keep calling until one is sent; this shouldn't be too hard, a RSNOR latch should do, but I'm too tires right now :tongue.gif:
I'm a bit suspicious of the reliability of door-PEZ, it could break in laggy situations such as with old computer or SMP. So I try to find an alternative.
Clever :tongue.gif:
It's very reliant on the correct friction and timing, but as long as the momentum is well calibrated up the top, this should work pretty well. :smile.gif:
You could probably set it up to work perfectly with the button's timing with the right lengths of track.
in my V.1, I didn't use the straight forward detector-calling-next-cart approach because two reasons: 1. in the design the towers are too tall and requires too long a powered section, the activation time of a straight detector won't be long enough to send cart through reliably; 2. I did it that way trying to solve a certain worry - what if there is no next cart? what is the next cart arrives late/out-of-sinc? Unfortunately my V.1 design did not exactly address that issue well enough.
My way of addressing Etho's issue was to prevent multiple call-out by ensuring the cart is only called when someone actually rides a cart and go past a certain point. But this only solve half of the issue as described in my V.1 :tongue.gif:
Well, my V.3 is out, I believe this is quite close to what I want to do, all design parameters fulfilled - apart from the size being ...a bit big :tongue.gif:
p.s. That long slide dispenser by captainsparkle is quite clever; but it's a bit too ...um... fuzzy(?) It's not precise enough for my liking... Hmmm.... I may have an idea for V3.5 or V4 :tongue.gif:
Also, it will break occasionally because of the old booster glitch, but once that is gone it should work fine.
Logic:
Two detector rails per component: DRA and DRB
One "bridged" RS-NOR latch per component: RS
DRA(i) turns on RS(i+1).
DRB(i) turns off RS(i).
First position in queue: i=0
The on-state of each RS-NOR latch is connected to a repeater, which feeds directly into the on state of the next RS-NOR latch, preventing them from being reset until the queue is full up to that position. It also has the effect of causing all the carts to move simultaneously.
My design is not very compact, so it would be interesting to see what you could with this logic.
* These dimensions are similar to your original version, so the module length is one side of the rectangle and the width is additive to get the other.
(12 high, 14 long, 2 wide)
EDIT: download link: http://www.mediafire.com/?ll65talm71yg6ml just look for the big thing. Also in this map is a departure mechanism (enter the door, which locks it and calls cart, enter cart, which launches and unlocks door) an arrivals overflow handler (stick um in a loop til the other guy is out of the way) and a few simpler concepts.
Wow! How wonderfully mechanical :biggrin.gif: and it looks like the style of a redstone oldtimer too!
I will need to take some time to understand the wiring, but it looks really nice.
I quite like your H-shaped switching mechanism too, and I think it is a very practical solution which is not too resource heavy either, and if a queuing system can be added, it will do nicely on a SMP server.
The arrival looping delay is a great idea; I've been using multiple arrival points redirection in my own world (6 bays? 8 bays? can't remember), which was based on the old rails but can be easily converted into the new system, I think if it were to be implemented on a big SMP world, the looping system can be a great backup and will help conserve resources: say the normal expected simultaneous arrivals are estimated to be no more then 4, then we could have 5 arrival bays plus the looping delay as the backup in case all bays are full. My current system will re-route the incoming cart to go on a big circle and re-attempt entry, but your method is a more elegant solution, which will use less resource as well.
As for the departure lock out, it would be great is the destination selection is also done in the locked space, also I think it would be a good idea to have an exit solution that will be hooked onto the RS-NOR reset as well, so if the rider changes mind, there can be a clean exit.
Some great ideas! I'll sure start borrowing your H-intersection idea right away if you don't mind :tongue.gif:
In fact, instead of my centralised 9 destination stations in my own world, these kind of intersections could work well in the form of a road network, not unlike the roads we use everyday :smile.gif: which is hopefully less resource hungry and easier to build too :smile.gif:
Sounds like a great idea! so the circuit should "know" how many carts are loaded hence deciding where to send an arrival cart into the system or to redirect the cart to overflow control.
But is it possible for you to put up some signs so we know what to do? the first thing I did accidentally messed up the whole system :tongue.gif: I think the final solution based on your design will have to be a sealed-core structure with good anti-dumbness design built into both the entry and exist. For example, because there were quite a few times when I accidentally destroyed large sections of my own station due to flooding, my current station is built in a way that both the engine room and the destination selection circuits are water-tight :tongue.gif:
Doing a counter did originally drift past my mind when I was doing V.1, but I'm simply not up to the task of wiring a counter, so it was a very remote fleeting thought... hahahah :biggrin.gif:
We do need to get that circuit down to scale though, then I think this could be a vry elegant solution :smile.gif:
Thank you :smile.gif:
What you are describing sometimes does happen when the world is reloaded - the standby cart would be loaded sideways and it takes the booster/next standby cart a few pushes to send you on your way, but eventually they all go on their way... the worst case I had took 4~5 seconds of bumping :tongue.gif: but that was due to the system was still in testing stage and I accidentally bumped the cart out of where it should be (the glass box wasn't in place properly; once the cart launching sequence has been run once or twice, it should be quite smooth, especially now the "follow-through" P-rails are always powered in the published designs (originally they were reliant on the stone plate, which did cause a few failures) The positioning of the carts in relation to the stone plate and the rails are critical, which is why the whole thing is encased in glass, and that normally you don't get to "touch" the carts and bump them out of place.
But the "third cart"??? AH HA!! I know what you are talking about now... you are using my V.2 design right? That's the only one that has the "next-cart-calling" hooked up to the pressure plate... with that design, if there is a delay in launching, it could mess everything up. Thank you very much for pointing it out. This further strengthened the case of designing the cart-calling to be done on the exit rather then at the departure point itself.
p.s. now after reviewing my test ground, OMG I have so many typos :sleep.gif: