Inactive [MECH] TrainCarts v1.71.2 - Link minecarts of different types together to form trains [2222]

I've tried Your solution today, but it looks like switcher sign is always operational with or without power from redstone, so my trains are going with one route either way.

@maro48m @_frozen I believe that the detector sign doesn't work with the directional tag, because it doesn't switch tracks. Keeping the bottom three lines empty is sufficient.

I suspect that you forgot to power the detector sign itself. I am not sure, but it could be it differs from switcher signs, in that it requires a powered sign to make it toggle the lever. Either way, try if this works:

The switcher would start toggling the rails only if it receives redstone power. (or power is inverted, etc.). The l/r/f/b etc are relative to the sign, so, when you look at the text-side of the sign, it is relative to that.

@dibujaron Did you power the sign and did the sign face into the right direction? I haven't done a check-up on those portals for a while, so it could be a bug in MyWorlds...

Alternatively, check if the elevator sign works. It works very similarly to portal signs. If that fails too, it must be in the TrainCarts itself.

[train]
detector

works fine (without power applied) - it switches levers
but i've been doing experiments with switcher signs
and the do not need redtorches
even when written:
[train]
switcher

hence my instruction to have the output signal feed its power to the switcher sign to determine the switching criteria was met when needed.

Example:

============================================
||
============================================
S~ D~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ D
|__| <--Redstone Line (~ = blank space, ignore those; its needed to keep the two D seperate)

*I hope this text formatting works*

Switcher has nothing to do with detecting rail. That we know. Therefore, we feed the signal from detector sign which will detect whether theres trains on the tracks. If the condition is met (on), it feeds a sign to the switcher sign, powering the condition r:true.

Is this design in error?

Yes, they do not need POWER if you do not give them any criterias to determine where to switch tracks. But if you do this as a example:
[Train]
switcher
r:empty
f: passenger

Then this needs power.

@bergerkiller:

My signs are powered and the elevator signs work fine. I build the exact same configuration from the video demo you have. then, when that didn't work, I found another demo on youtube and build that. still didn't work. I'm confused.

However, at present, I was able to workaround using elevators instead. So no rush on fixing.

@dibujaron alright, I'll do some testing on the portals system. Just in case, you did place them under the tracks, facing to the side the train comes from? Did you power them? It does not work like in MyWorlds, where the train would enter the purple portal block and get teleported. It acts as a regular [train] [cart] sign.

@_frozen There are a lot of improvements I had in mind. A few years ago I had this HO-model train driving all around the attic with junctions and such. I did the electronic wiring myself. I know the possibilities of TrainCarts related to all that, but the problem is: How do I make sure that the player can understand all this? Minecraft lacks a simple GUI where I can show wiring plans, otherwise I could easily make complete schemes. For example, allow you to drag the a line from the 'switcher' sign or 'detector' sign to a destroy sign, or even have virtual redstone circuits embedded into this.

I have no idea what the Minecraft API will deliver, so I'll be waiting for that to continue the real development. I fear that it won't offer my demands and I end up using Spout instead...especially if it would support the API as well through a bridge.

About the set-up now.

Yeah the design seems in order, though maybe you could have the switcher and detector sign both under the same piece of track. It depends on how this system should work of course, you may need a delay.

Hmm. Maybe at the worst, use a item to check all wiring information (this idea I noticed was used in Railcraft, a tekkit plugin similar to this). Like String and Worldguard (was it Worldguard? Im not sure.), you click the item on the tracks and it tells you which detector region it is covered under, destinations that is possible, things like that. I DO know that this might be unnecessary due to the upcoming API, and agree completely to hold off major development like that until further notice.

ok, i tried Your suggestions:
~~~~====================
====|==================|=======
ST~~S1~D1~~~~~~~~~~D2~S2~~~~ST
~~~|...|~~~~~~~~~~|...|

S1 and S2 are switchers facing STations with text:
S1:
[train]
switcher
l:true
r:false

S2:
[train]
switcher
l:false
r:true

D1 and D2 are detectors fcing each others
and switchers still work even without power.
You can see it on my server:
maro48m.dnsd.info:25565

@bergerkiller:

yes I did. I set it up exactly the same way the videos did. so unless the videos did it wrong, I did it right. for 2 separate videos.

I am having the EXACT same issue lol, i tried Chunkenforcer to fix it but it didn't work.
Will try and replicate your steps and hope it fixes it for me

@dibujaron I tested it locally, and trains are not teleported..at all. So I'll be fixing this now, thanks for the heads-up.

@maro48m The problem I've seen is that, when unpowered, it will not do anything at all. This makes it a bit impossible to use switcher signs as a redstone-based switching station. The only solution I can give, is to have two switcher signs underneath one rail, and power either of them using an inverter:

And power the above two signs using the same wire. Then the train will go right when powered, forward when not powered (not not = yes)
I am considering a separate statement to read redstone power around the sign. Only problem is that the sign would activate/deactivate as well. So then you would have to put a torch below the sign and an additional wire to the sign, which you read. For example:

Redstone coming from the left? Go right. Else go forward. Instead of the torch I could add another ID for 'always active', for example:

@ bergerkiller

great thanks a lot!

Alright I resolved the teleport problem, added a +train and +cart version for 'always powered' and am now going to add a directional redstone power check.

is it going to be next release of train carts?
Or should i rebuild source myself?

@maro48m will be the next release (1.69). Also, the redstone based statement now works really nicely! This on the sign:

Left side powered, switches left, right side powered, switches right. It works amazingly well, but it did require me to pass in some more information to each statement. Hope it didn't break anything in the process. So I'll first be testing detector signs more thoroughly, then I'll publish it.



But I just remember that I had to improve the spawn sign to allow a timer in it...

@maro48m Alright I did a full-out test complete with your set-up. I managed to make that extra line when the other line was crowded, and handle proper switching when coming from the other direction. This is how it looks like:


I see no better way to do it, so for now, this will have to do. What this does, is basically:

• All trains entering facing that sign, will go left when ahead is powered, otherwise forwards
• Trains coming from the left or from the back of the sign (relative front) will go back (facing the sign)

The detector signs also work as expected without problems. (did have to fix something...as well a huge rewrite to make that code less confusing...)

Not sure how I am going to implement that spawner sign, because it requires permanent storage of spawner signs and a pulse now and then to trigger a spawn.

dang another problem. I have an automatic train system between 2 stations. the train occasionally gets stuck at the station when no players are around. I have your plugin and RollingMinecarts as a backup to keep the chunks loaded, and the config option "keep chunks loaded only when moving" is set to false. please help; I keep having to fly out to the far station and fix it.

my stations signs are set up like this:
[train]
station 5
10
reverse

the train is a storage minecart, 3 minecarts, and another storage

edit to previous: it only happens when no one's on. and another question: do transfer signs only work
if the sign is facing sideways? they don't seem to work if the sign is facing the same way as the track. generally with
your plugin if the sign is sideways it works for both directions, but if it's facing one way it only works for that direction. however, this doesn't seem to be the case for transfer signs. Am i wrong? or am I going to have to redesign my system?

Have the signs replicate a button press? Not sure how to approach it, but for every duration, it ends with a 5-tick power-up. As for the permanent storage, dont over-engineer it, and reuse the current "keepchunkloaded" attribute to any and all signs with the spawn line enabled? Not sure if this is possible via coding.

@dibujaron I had to slightly alter that system. When the track above is not curved, it works both ways when the sign is sideways. When facing a certain side, then only that side. When the track above is curved, it only works to the direction facing that sign. To have custom directions to trigger the sign, say, you have a 4-direction switcher, you can do that on the first line:

It will detect trains coming from the left and right, and switch those trains forwards. You can have multiple switcher signs underneath the same block (pillar) to handle all directions.

@_frozen To loop through all signs in all loaded chunks of all loaded world is incredibly slow. Right now, SignLink handles the updating these signs. That one, too, stores the signs that have variables on the signs. For spawner signs I could use a variable and ask SignLink for all the signs, but that is a workaround. I prefer storing the signs to pulse, combined with the interval, and update these signs one after the other. But the problem is that a crash could potentially erase all data, something I dislike.

@bergerkiller
I don't know how plugins work internally, but maybe You can have some sort of signs array,
Where you put all spawner signs taht have timer set. and later in some sort of main loop you check all signs from this array, and force spawn if their time has come.
Looping through ALL signs every time will be complete waste of time - most of them will not be timed spawners.

@maro48m Yup, but that requires me to store data in a flatfile for when the plugin/server disables. That is the offline part of it all...and if something goes wrong at that point or the file gets corrupted, you have to replace all spawner signs in the world...

isn't this a problem in all other signs as well?
Oh, right - you don't keep other signs in files - train detects sign when is above one.
But you keep trains in file, and that didn't stopped you

Mhh that is true yes, same for detector signs. Guess it isn't such a big deal.

You could always add some mechanism for backup files.
When you save a file , do a copy before that.
When for some reason save will fail and file will be dead - just replace a file, and user will be happy not to recreate all 20000 traincarts from scratch.
It could even be done internally by plugin (with some message to server console)

@bergerkiller:

let's see if I understood that. so on the first line you can put [train:lr] and it'll detect from left to right only?

also, the links on both bukkitdev and this page that are supposed to go to the wiki are deleted. can you edit them to point towards the new minecraft forums pages?

@dibujaron Yes, you can set the directions from where trains are coming from to detect. And I thought I updated the links to point to Minecraft WIKI....odd.

@bergerkiller oh m'bad this page's link works. bukkitdev's doesn't though...

also the signlink wiki link doesn't work either on either page. I really need that one, as I have no idea how to create a variable, but it looks really cool.

@dibujaron yeah the wiki admin seems to be too busy to not forget my e-mails about temporary restoring it...lol

Anyway, @maro48m I started development on a timer for the spawn sign. I rewrote most of the build logic to use a sign action event to get around the annoying overloads for all functions. Now all functions use one type, SignActionEvent, to send sign information over. Sign spawners get their own block map, and like detectors, their own save file. I already wrote how the intervals are handled, rules around loading and such. Now time to debug...the best time during development.

My personal favourite is when i get idea how to solve some complicated problem. Right after that is debuging