TrainCarts
TrainCarts Development has moved to SpigotMC.
You can get the new versions at the following URL:
https://www.spigotmc.org/resources/traincarts.39592/
This page is no longer being actively monitored, please seek for support on SpigotMC.
Plugin: TrainCarts - Linked Minecarts, sign-redstone systems, easy to use and realistic
Version: v1.73.0
Build: 1.7.2 R0.1/R0.2
Incompatible with: RailCraft
Description
This plugin looks for suitable Minecarts and links them together if possible. When two Minecarts are being "linked", the Minecarts will act as one single moving train.
Once carts are successfully linked, an effect is played and their velocity is shared in combination with an individual factor for each Minecart, which is used to remain a steady gap between carts. This gap is adjustable, the force at which this happens as well.
End result: a train! You can move it, make a roller-coaster out of it, split it in half, watch trains collide, whatever you want to do with trains. :)
As for 1.21, it is also possible to safely exit your train by setting an exit offset with a (sideways) push factor for the train. This feature is disabled by default. (only affects dropped items). If you want to display arrival times on signs (see redstone circuit part) you need SignLink, see the downloads on the bottom of the page.
As for 1.35 you can set train properties to make 'special' trains, or to 'finalize' a train

Links
For configuration, permissions and how-to's, see the Wikipedia page (it is rather long):
Note that I would prefer having comments, bug reports and others in the main Bukkit page, since I visit that site the most. :)
Addons
Special Addons for TrainCarts
Features
- Link minecarts using collision: no commands needed to make a train
- Move trains as easily as you would with single Minecarts
- Store trains to file for persistence during reloads and server restarts
- Use sign-redstone circuits for subway systems, complete railroads and much more
- Station to gracefully stop and launch trains
- Spawn
- Teleport
- Property setters
- Tag systems to switch certain tracks based on tags on the train
- Destination systems to make your train travel to far-away lands all on it's own
- Supports Minecart Mania's features
- Infinite minecart speeds are possible
- Push-away: Push mobs, players and items away from your trains to keep them running
- Everything is configurable, if something proves not to be, I will make it that way
FAQ
When players are near, trains reach their destinations. With no one near, they don't. What do I do?
By default trains do not keep chunks loaded, and they will unload once they move into unloaded chunks. To make trains keep the chunk area (and themselves) around them loaded, set the 'keepchunksloaded' property to True. This can be done using the /train keepchunksloaded true command, using a property sign or by changing it to true in the DefaultTrainProperties.yml file. For more information about train properties, see here.
Why not boats?!?!
Incompatibilities
If you have another plugin that performs similar Minecart replacement techniques, it is likely that TrainCarts will not function or function poorly. For the 'chunk persistence' part of this plugin, other plugins that unload chunks without firing events result in this feature failing. Minebackup is known for having this problem.
Metrics
This plugin sends server count statistics to MCStats.org. You can (globally) opt out in the PluginMetrics/config.yml file.







-
View User Profile
-
Send Message
Posted Apr 20, 2013@Etsija You should not power the switcher sign if the only intent is to switch the lever. Power means it is going to alter the rails, which you don't want. The set-up is fine, although you could experiment with where you place the signs on the pillar. But the idea is as it should be.
-
View User Profile
-
Send Message
Posted Apr 20, 2013More trials: I'm trying hard to activate a certain sign based on the tag property of the train. Train is spawned on the left, it takes the chest contents -> moves on to the tag setting block -> moves on to the switcher which I'm trying to switch the "chest in" sign based on the tag set. https://dl.dropboxusercontent.com/u/6411310/2013-04-20_23.53.27.png
What happens is the train is stopped at the switcher, and reverses its travel backwards.
I'm doing something obviously wrong but what is it?
-
View User Profile
-
Send Message
Posted Apr 20, 2013Do I need to have a switcher sign plus a switch (lever) for that? I use your example for empty cart destroying, but otherwise, have not seen or used a real example of such a switcher solution. Could you please give me a simple example, Bergerkiller? Thank you.
EDIT: So I'm looking for a simple way to activate either of those signs as seen on the picture. Is it possible in any way? https://dl.dropboxusercontent.com/u/6411310/chest_in_chest_out.png
-
View User Profile
-
Send Message
Posted Apr 20, 2013@Etsija As stated before, a switcher sign can take care of this. You can use a property sign to assign 'tags' to trains (addtag), which you can read back using switcher signs. You can then make sure that it only does X when tag Y is set.
Still not sure about the name to use for the goal thing. Matching is nice, but it does not make clear that it is about the 'target' inventory. I really need a proper descriptive name for this...
-
View User Profile
-
Send Message
Posted Apr 20, 2013In relation to the "matching" operation we have been discussing: would it be possible to add a new property to the trains, which would be something like "deliver/gather" or even "chest in/chest out"?
I'll explain. Below each of my chests, I will have two signs: "chest in / 20 matching" and "chest out / 20 matching". Then I would put a property sign under my train which would label the train to either take out from my warehouse / or put stuff into the warehouse, ie. either read the "chest out" or the "chest in" sign.
-
View User Profile
-
Send Message
Posted Apr 20, 2013@bergerkiller
Yes, I think this is what I meant with the "goalie" thingy, although your terminology eludes me. But it is just me! :D
How about "20 matching"? I think it would pretty much describe what it tries to do.
And...I think this new feature would have a HUGE potential. More and more things it could do pop in my mind every time I think about it!
-
View User Profile
-
Send Message
Posted Apr 20, 2013Latest BKCommonLib build has some fixes for the leaves issue.
-
View User Profile
-
Send Message
Posted Apr 20, 2013@Etsija @CommanderGizmo Sounds exactly as what I am telling. You don't have to match the source against the destination, because you are already taking items from the source. Items that match the destination but do not match the source, are not transferred anyway, because they don't exist in the source. This is all that is needed to accomplish what you want:
Which translates to: transfer 20 of all types found in the chest from the train to the chest. When using chest out, it would transfer 20 of all types found in the train from the chest to the train. As far as I know, this is exactly what you want. All that I kinda of need, is a proper name for 'goal'. It is a constant to identify all types found in the 'destination' or 'target' inventory.
I understand the issues with leaves, so I'll have to take account of this in BKCommonLib.
-
View User Profile
-
Send Message
Posted Apr 19, 2013@bergerkiller
No, I meant exactly the opposite! My idea is implementing a "warehouse collector", not the other way around. I think CommanderGizmo has described the idea far better than me.
@Commander: yeah, all of my leaves are gathered with silk touch, so that most surely is where the problem lies.
-
View User Profile
-
Send Message
Posted Apr 19, 2013@bergerkiller
The more I think about it, this seems more in the realm of a new command. Presently, you can put 'collect' or 'deposit' along with any source (c, d, f, g). This seems more like it would usurp the whole idea of a deposit sign. Thus, I propose it might work well as a 'match' command:
This would search in a radius of 10 blocks for chests and then check the contents of each chest. If the train has the same item in it's inventory, it will then place 20 stacks of that item into the chest. This would apply for all items in the chest, one by one. So if the chest had some coal and some iron_ingot in there, it would place 20 coal and 20 iron_ingot as was available in the train's inventory.
How does that sound?
[EDIT] It seems that even with this matching idea some will want to put items in the chest, while others will want to remove them. That being the case, perhaps either two new commands or some new syntax would make more sense? Maybe I just misunderstood your idea of how to do it bergerkiller? If not a new match command (which would not very well determine which direction to transfer items), what would make the most sense?
-
View User Profile
-
Send Message
Posted Apr 19, 2013@Etsija
I had similar problems with leaves before. The trick is that the data value only applies to certain bits. Therefore, the type of leaves should technically be correct, but sometimes you can get leaves whose counters for decay have been ticking. Some plugins (such as Qwik Tree) cause this and there have been issues with silk touch causing it too I believe. If you were to check the data value of the leaves in the actual chest (you can enable viewing this data in the options) you will probably find it is not quite what is expected.
-
View User Profile
-
Send Message
Posted Apr 19, 2013@Etsija I checked using leaves:2 and 18:2, both worked as expected and transferred the right type of leaves from the cart into the chest. I have not experienced any issues that you are experiencing in that regard.
Is this what you want?:
This is easily doable by introducing a new kind of 'item parser', which translates to the contents of the 'destination' (so chest or train). Got a nice name? Maybe call it 'goal'?
-
View User Profile
-
Send Message
Posted Apr 19, 2013Clarification: item subcodes for the leaves do not work, but a generic "leaves" does work. But that puts all leaves of the four trees in the same chest, it doesn't separate them by the subcodes.
-
View User Profile
-
Send Message
Posted Apr 19, 2013does not take any leaves in, although it should take in oak leaves and birch leaves.
-
View User Profile
-
Send Message
Posted Apr 19, 2013@CommanderGizmo
That was EXACTLY what I meant, thank you for making it more obvious!
-
View User Profile
-
Send Message
Posted Apr 19, 2013@bergerkiller
Maybe I'm way off, but I think he meant that the train checks it's inventory vs the chest the sign referrs to. Presently, I don't think switcher signs can check the inventory of chests not in the train.
This idea is very good. It would make it much simpler to build warehouses.
-
View User Profile
-
Send Message
Posted Apr 19, 2013@Etsija This is already possible by utilizing the switcher sign. Place a switcher sign checking for item contents (i@sticks). It toggles a lever. Connect this lever to the chest in/out sign. Now, when the items match, it will transfer the items over. This applies to all functionalities that require 'matching' a train - the switcher sign v.s. redstone power was made for this functionality.
Doors can not be stacked, like, not at all. Just verified it in SP. Transferring leaves, also, works just fine, so not sure what you mean by that.
-
View User Profile
-
Send Message
Posted Apr 19, 2013More glitches: leaves 18:0, 18:1, 18:2 and 18:3 are not recognized as arguments to "chest in".
-
View User Profile
-
Send Message
Posted Apr 18, 2013Also one slight glitch to report: doors are not stacked when depositing to chests with "chest in". Other items which are non-stackable in vanilla Minecraft are stacked just fine I think.
-
View User Profile
-
Send Message
Posted Apr 18, 2013Bergerkiller, I have an idea which could improve "warehouse" type of operation tremendously with TrainCarts: a conditional "collector" train. It would work as follows:
Example: I load my cart with one smoothstone, one netherbrick and one stick. My collector train makes one round in my warehouse and returns me 64 stones, 64 netherbricks, and 64 sticks.
What do you say? I guess TrainCarts already does a lot of inventory tweaking, so I think this would not be a tremendously big feature...?