MINECARTS Mk. II *Latest Update: 9/1/2011*
Poll: Is this poll no longer relevant?
Is this poll no longer relevant? - Single Choice
- I don't care. I always click on the last answer. 3.4%
- Maybe. 2.7%
- I just like pretending I'm voting on something important. 22.8%
- Of course it's not when you change the questions and answers. 71.2%
Ended May 15, 2014
It seems like a fantastic solution to the problem, and it isn't as overly complex as most of these big... suggestion... post... things.
And it also mean people wouldn't have to rely on exploiting a glitch to make their transport systems work, either!
New findings in game mechanics have prompted a redesign and redefinition of the Minecarts Mk. II proposed block's function and mechanics! The changes add significantly more functionality, flexibility, and simplify their game mechanics. As a result, the new proposed blocks will also be much easier to implement and use in-game.
From close observations of door, sign, and track placement mechanics, I have come to the conclusion that special blocks can be placed facing a specific direction by using adjacent blocks as references and can retain that orientation indefinitely.
Based on this discovery, practical, mono-directional boosters are now possible. As such, I have developed new game mechanics for the proposed "Booster Track Piece" which now allow it to function as both a booster AND a brake! Since the newly-named "Booster-Brake Track Piece" can now perform the functions of both the old booster and the old brake, I have also redeveloped the game mechanics for my proposed "Brake Track Piece" to now operate as a full-stop block. This track piece will bring a cart traveling at any speed to an immediate, full-stop on a block adjacent to it. The updated block is now renamed the "Full-Stop Track Piece".
Special Track Placement Mechanics:
When placed, a special track piece will first check for any pieces of track on adjacent blocks. If so, it will line it's rails up based on regular track placement mechanics. To determine special ability orientation, the track piece will always try to orient the ability to face the player. (See fig. 1a)
If no adjacent track pieces are present, the special track piece would orient itself so that the special ability is pointed towards the cardinal direction (North, East, South, or West) closest with the player's location relative to the track piece. (See fig. 1b)
The New Proposed Components:
The appearance of the pieces are intended to signify their function and should blend in with existing redstone and cart objects. The original green and yellow "traffic light" style indicator lights no longer made sense due to both piece's added multi-functionality. Also, after reexamination, the coloured lights stood out too much when placed alongside other redstone parts. As a result, I chose to make the new designs have redstone red indicators. I think this will give them a more homogeneous and aesthetically pleasing look if incorporated into existing redstone cart systems.
Simplicity & Ease of Use
I feel that this update has significantly simplified the game mechanics of my proposed track pieces. There are now only two operational cases for each piece: a passing cart is either moving in the direction the piece points, resulting in operation "A", or it's attempting to pass opposite the direction it points, resulting in operation "B". This will hopefully make it a much easier task for players to understand the special track's effects and apply them to a cart system successfully.
I've decided to add suggested crafting recipes for all of my proposed items. I have attempted to base them off of existing recipes as much as possible. The track piece recipes in particular are also intended to reference the distinctive redstone layout of each track piece. I also chose to upgrade the "wood" section from a stick to a plank to emphasize the special nature and relative additional expense of each track piece. This section is highly debatable and I don't consider it significant detail in the overall presentation so I haven't included it in the actual proposal. It shared more for sake of completeness and your enjoyment.
Booster-Brake Track Piece
Full-Stop Track Piece
Cart Detector Block
Occupied Cart Detector Block
Feel free to use them how you will, a little credit would be nice but not necessary.
Booster-Brake Track Piece
Full-Stop Track Piece
A HUGE thank you goes out to my friend "Chalk" (in-game name "Chalkyzee") who had a significant part in both helping me figure out how the directional and track placement game mechanics worked, and in developing the new mechanics for the updated proposed track pieces. Without him, this update might not have happened.
Comment, questions, and criticism are greatly appreciated! I'm always looking to find ways of improving this concept. Hopefully one day it'll be good enough to become reality!
Solution for a two way booster on a single track:
It's an overhead view, but it's not a stretch of the imagination to see the redstone wiring neatly tucked under the rails for space conservation. Hopefully I have proved that my system makes it unnecessary to separate brakes from boosters. By using a detector and some redstone, you can easily disable one of the two functions of any given special track piece.
While I'm sure there are applications for intentionally having a threshold speed, it doesn't seem like a good idea for what you're trying to address.
Edit: Also when did my post count start to exceed yours
One note however; how would you tell which way a brake/power track is facing without going over it?
And another thing, wouldn't it be easier for a full-stop track to stop a minecart on it's own square?
It's possible with that solution. Just after posting that however, I kicked myself because I came up with a better and more simple solution immediate after:
Not sure. I'm not in a race though.
I designed the proposed booster brake piece to have a chevron type [>>] design which indicates the direction of the boost when placed on the ground. Here's a closer look:
The problem with having the full-stop track piece stop a cart in it's own square is that you can't set it up to be boosted again. Note that Booster-brakes only work when a cart is on top of them. Therefore, by having a full-stop track piece stop a cart beside it, you can actually have the Full-Stop deposit a stopped cart directly on top of an adjacent booster track, ready to be launched again!
for the booster brake, one way to make it easy to tell which direction it is going would be to make one dot green and one red, where the green dot is closest to the user when placed, and the red dot is further. this would make sense if you took green to be an attractor and red a repulsor, so that carts traveling in the 'correct direction would first be pulled by green, then pushed off of red when crossing, and carts traveling in the opposite direction would feel a resistance from red, and then a backwards pull when crossing the green.
I don't think that a bi-directional booster should require the track to fork and rejoin, nor should it require cart detectors. The experience of the rider is, I feel, highly degraded by rapid changes in direction of the track
They may seem too techy, which is something Notch has stated he wanted to stray from. Of course, only he knows how far "too far" is, but it's possible this is past that threshold.
Two, it could conflict with a different version of powered mine cart propulsion that actually works, or if combined trains ever happen. Especially the detectors, as a linked cart-train could contain both an occupied and non-occupied mine cart.
These are of course just hypothetical, and if aren't real concerns, then I'm all for it.
Though that's a legitimate concern, I believe that most of the elements (at least in the first version of this proposal) that this is trying to introduce into the game are already present. Pressure plates react to mine carts and differentiate between occupied and non-occupied types, yet they don't mesh well with minecarts because really, a mine cart should never leave a track.
As for brakes, I don't think it makes any sense to contemplate a system of moving vehicles without being able to slow them down, and with redstone already in the game, and given that redstone already influences at least one type of track, it isn't much of a stretch for it to turn on / off brake sections.
I'm a bit concerned about what notch will do about powering or propelling mine carts, but given that he put a video of a roller coaster on the main page, it seems that he endorses some method of boosting mine carts
I just remembered a question i had for the author... we now don't have a way to stop a minecart between two tracks, the benefit of which is to be able to detect riderless minecarts. Or at least, it isn't apparent to me, your first proposal made it very clear that it would be possible, but i'm unsure with the newer one
What I think may be too techy is the aesthetic, as it shows more of an "electric rail" feel, which might be outside the steam powered feel Notch might be going for.
Instead of a separate block that detects if a cart is passing it, how about pressure plate tracks? They provide a redstone signal yet allow a cart to pass over them.
Could it be easier to combine the brake and booster tracks? Just as a redstone signal can rotate a track turn (which has more than just on/off), could you get a combined "power track" to toggle between forward-stop-backward (and possibly off)?
Also a very good idea. I think the carts may need some space in between where the couplings would be, since they turn in near 90 degree angles (single-block turn). When they turn corners in tight spaces, there is already graphical collision with the walls due to their size, therefor if they were joined with no space, I'm sure there would be some other, worse problems with the objects' models going through each other.
I can reupload the original proposal if you'd like. I kept a copy for just-in-case situations like this. My only concerns are that it's pretty long and I don't want to confuse possible new readers who read it instead of the updated version.
The goal of my proposal was to meet all the current needs of minecart stations and replace the need for the booster glitch. During development, I found that I could add even more functionality while still maintaining a minimum level of game additions and changes. I had hoped that this added functionality would allow future players the flexibility to use my proposed blocks in ways we haven't even considered and create something amazing.
Your comment on the colour and visibility of the icon is very valid. Even before posting the examples I shared, I had already drafted and discarded about twenty other concept drawings and I'm still not content with my "final" design. I envisioned that animated effects similar to activated redstone would augment the static track piece but those thoughts are difficult to demonstrate in a still image. As it stands, more suggestions (or better yet, actual pixel drawings) of what the pieces should look like are definitely welcome and all work/additions would be credited.
Concerning bi-directional boosters. Remember, my goal is to match all the functionality and aesthetics of current minecart systems. I agree that changes in direction are still pretty jarring, (actually, they suck for the most part) however the fact remains that my basic bi-directional booster takes up six track pices and the current glitch-boosters take up at least double that amount. I'd say that's still an improvement. That aside, I would also remind you of my previous bi-directional booster suggestion. It would probably only work above a certain speed threshhold, but it's all done in-line with no changes in direction.
Good idea. It's been mentioned a few times before too and I agree that it's an idea worth considering, however, I think that it's an "extra" feature ( and one that's not currently implemented in Minecraft) and so it's outside of the scope of this proposal. If I get some time, I might do a topic on extra features, but for now, I'm just trying to introduce the bare minimum of additional objects and changes to achieve the same level of functionality the the current glitch system has. Sure, some of my objects add functionality above and beyond that of the current glitch system, but I'd like to think of that as a welcome byproduct of good design. ;-)
When creating this proposal, I envisioned three separate minecart "styles" of play. Un-powered, gravity coasters, powered minecarts (but with changes to buff them a bit as outlined in my proposal), and my proposed momentum-and-redstone powered system based off of the current glitch cart system. Players new to carts or who are unwilling to invest the resources needed to upgrade would generally use un-powered carts. Players who desired a quick and dirty method for faster-than-waking transportation or who preferred "hands-on control" when carting would most likely use powered minecarts. Lastly, players who enjoy patiently devising elaborate systems that require extensive work to set up, but once complete worked autonomously, would use redstone.
To address your second point, I don't envision powered carts and momentum/redstone carts running on the same set of tracks at the same time. I feel collisions would be inevitable. Perhaps there is a way though and I just haven't thought of it yet. That doesn't mean to say that my proposed redstone parts couldn't be applied to a powered cart track to give it that extra "boost" on tricky parts of the track or in some other application. They're designed to be pretty universal in that regard.
The detector blocks proposed game mechanics were designed so that they could be placed anywhere around a piece of track: under, beside, or even over it if needed. With this flexibility, it's possible to have two or more detector blocks both monitoring the same section of track. Cart "half-and-half" placement would no longer be necessary and my "1.5 blocks" rule became redundant. I hope that answers your question for you!
Oh, and I even thought of using a stack of detectors in a pez dispenser wall to give a real time readout in your station of how full your cart holding area was. Based my current mechanics, detectors don't have to be restricted by rails. Just another thought. :-)
True, but remember that they're extremely hypothetical. If Notch ever takes anything from this, I hope he takes my game mechanics over my visuals because that's the real meat of proposal. The fact is, people love cool concept pictures and attractive visuals. A good image can spice up a boring post or get even the most attention-deficit forum user to stop for a second and read it. While yes, I did take a lot of time to develop each image and the reasoning behind its look, this was more in an effort to ensure that my nice graphical advertisements didn't degrade from the written message I was trying to convey. What made you stop and read my ridiculously long post? ;-)
Thanks for the questions! The main reason for not making it a pressure plate is because I didn't think the detectors should be limited to placement directly under a piece of track like a pressure plate would be. This was a) in an effort to make the system as flexible as possible and :cool.gif: remove the need to have carts stop between blocks (half-and-half) like current dual pressure plate systems require. As a result, this also allowed me to simplify the game mechanics of the brake and full-stop systems. This simplification will hopefully ease programming (if they ever get to that stage) and reduce the learning curve for new players on how to effectively use them.
The problem with combining them is that you're attempting to do more than one operation with a single block and as such, will break the current redstone binary rules (among a host of other issues). Requiring two inputs and one output for proper operation severely limits the number of possible configurations you can use the piece in. Remember, a block only has 6 sides to work with and redstone is already a pain in the butt when trying to make circuits. (I still love it though xD) As much as this sounds like it would further "simplify" things, combining the functions would in fact make them much more complicated and less flexible for other applications.
That would be amazing! I'd love to see a working mod using this proposal. It could even be submitted to Mojang as a proof-of-concept or working prototype! As I mentioned in the actual proposal, anyone is free to use my graphics in any way you they'd like as long as you link my proposal in the credits.
That's it for question time. It's late here, and I have work in the morning. If my answers changed your opinion of Minecarts Mk. II from your initial vote, feel free to re-vote. Thanks for all the continued support everyone!
Oh, and one more thing. Please check out and vote on my Minecarts Mk. II related comments in the following GetSatisfaction topics if you haven't already done so:
- I'd like to think that I answered them with insightful and useful answers.
- You probably missed out.
- Support Minecarts Mk. II! :biggrin.gif:
I don't like that the only way to detect a riderless minecart is to have two detectors placed against one block, because this requires that the track be against a wall or in a ditch of some kind. i'd prefer to be able to stop carts between two blocks so that the detectors could both be under the track, allowing the track to be on a flush floor. so that is what i was getting at before.
Powered minecarts could be given stacks of coal/wood/etc in a similar interface to that of the furnace, increasing how long a trip may last. (A stack of 64 should last a very, very long time)
They should drive with a moderate speed, mabye 2-3x that of a player's walking speed, but attaching multiple powered minecarts to one train would speed the minecart train up, albeit using more resources.
One other change could be the addition of a track redstone input.
When a minecart/train passes over the specified track, it acts as if a button was pressed or a lever was pulled, allowing for the addition of traps or systems for opening doors for minecarts and closing them after the train has pulled through, preventing mobs from passing through the passageway.
The player should also be able to manually push a minecart, while inside one, though at a very slow pace, which allows the player to push minecarts onto a sloped surface without the chance of losing it.
It was a nice idea at first glance, but it really didn't satisfy the requirements I had set out for a glitch-booster replacement once put under close scrutiny. After posting the original idea, I thought about it at length, went through dozens of potential game situations on paper (think of it like "pre-pre-alpha" testing) and discussed it with my friend Chalk (another minecart enthusiast and also computer science masters student). Together, we realized there were several issues with my original idea.
[*:1ekuzyp0] It was based on an unreliable game mechanic. Carts placed on a boost track at speed 0 could be potentially propelled in two directions. We feel it would be too difficult for players to judge which direction a cart would go when placing a cart on the original boost track. This would lead to frustration which is not a good thing.
[*:1ekuzyp0] The newly developed booster-brake proposal could do anything the original booster could, and also some things it couldn't (re: braking).
[*:1ekuzyp0] The new booster-brake had muuuch simpler rules for operation which would make programming it much easier. This makes it much more likely to become a reality.
[*:1ekuzyp0] The simplicity would also aid players in quickly understanding how it operated and incorporating it into their personal minecart systems.
When deciding that, I was concerned about block "area of effect" since powered blocks typically can only affect adjacent blocks and figured "one block over" would be more bug-resistant than attempting to program "1.5 blocks". Also, I didn't think having a single detect block beside your track in a station was much of an issue since it's already a great improvement over an entire booster line.
I agree that not being able to hide both detectors under the track due to the full-stop's one block stop range is a limitation to my system and it would be really nice if it had a method of doing so. I'm just unconvinced that changing the 1 block range to 1.5 would make enough of an improvement to risk bug issues and ease of implementation. Not to say I can't be persuaded though or cede if a better idea is brought forward.
@Terrier & koeniginator (Re: Powered Cart coupling): I would really like to see a coupling system too, but it's a feature that hasn't been introduced to the current minecart system yet in any way. I'm trying to keep my proposal down to the bare minimum of additions in order to keep the scope realistic and hopefully, more likely to happen. As such, "extras" such as coupling are out of the scope of this proposal unless they address one of the current serious failings of the minecart system. Save the idea though, because we'll need it for MINECARTS MK. III !! ;-)
@ koeniginator (Re: your suggestion of a redstone "input"): That's exactly what the Detector Blocks are for. Place it beside a track and it detects passing minecarts. You can use it to trigger all kinds of redstone things, not just booster-brakes and full-stops.
I really appreciate the hard questions! They've pointed out two current limitations of the proposal so far:
[*:1ekuzyp0] It's potentially difficult to tell which direction the proposed look for each piece points. My pixel art could use some redesigning.
[*:1ekuzyp0] Double Detectors, when used in conjunction with a full-stop, cannot be both placed under the track since a cart stopped in such a way doesn't straddle two pieces of track unlike the current pressure plate trick.
I'm open to any suggestions to improve or fix these limitations, or post and let me know if they're acceptable limitations relative to the scope of this proposal. Remember, there can always be a MINECARTS Mk. III.
Just one minor suggestion: making the directional indicator on booster tracks a bit more obvious
Check out my MINECRAFT BADLANDS MOD
They add some constant acceleration factor in the direction they're pointing. The first example shown would then be a minecart reversing direction.
As for the break blocks, I like the idea of picking a pre- or post- stop. It gives some more flexibility for starting and stopping mechanisms that an empty block doesn't. I like it.
Also, and I haven't given this too much thought yet, but directional stops and reverses, combined with the detector blocks and some SR-latches, the crafty redstone enthusiast could probably build the first minecart turing machine.