I have an idea. Similar to how the /st #stname command used to work with CraftBook, but more revolutionary. I propose that a button, adjacent to a sign formatted like: First Line.....: [Destination] Second Line.: #destination Third Line....: Text description Fourth Line.: of destination (changes to this when placed) First Line.....: -#destination- Second Line.: Text Description Third Line....: of destination Fourth Line.: -(press button to choose)- when pressed acts similarly to how the /st command worked with minecart sort blocks. This would be extremely useful for use with minecart stations not only on the server, but also for users of CraftBook as well. EDIT: This idea has been changed slightly to bypass the button, instead right-clicking the sign should send out a pulse, like a button. Sign should now be formatted Ike: First Line.....: [Destination] Second Line.: #destination OR ##set Third Line....: (empty) Fourth Line.: (empty) when implemented with a set, you should be able to scroll through destinations in some way (probably like on Stargate networks).
The fact that the button has to be located directly adjacent to the sign should eliminate the check redstone current for who triggered debacle.
Sorry to bump, but I think you may have forgotten about this sk. Please tell us what you think about the idea.
What about instead of adjacent button, you just right click the sign which also sends a redstone pulse like a button?
Mainly as a replacement for the old /st #stname command. Say for example, you right-clicked a sign at grand central for Marketplace, in addition to switching the track for the correct line, it could also auto-eject you at said station when coupled with a station/ejector block. Could also be used to switch tracks like the old minecart sort blocks.
I suppose I could add it. The thing I don't like about /st with sort is that it only works on linear routes. Often times you'd want to go to a place on a different line and so you'd want to take a connecting route, but /st isn't able to support this at all. You'd have to manually disembark and re-embark. 3 server resets ago, I was working on a system that would automatically route you the entire way between stations, but I actually couldn't figure out how the tracks would physically connect and how you'd mark that intersection so that the code would know to switch. Personally I'd prefer that a lot more.
I like that idea too, but it increases the need for tracks and time required to build the lines. Grand Central was originally supposed to be like a vanilla station in some respects, and have a line for every single destination, but I decided against in favour of lines. I do believe some cross-line linking would be possible with /st, albeit with a whole lot of minecart sorters. Maybe a better implementation of sorters for destinations is necessary, via commands so that many destinations can be supported going just one direction, eliminating the need for too many sorters. EDIT: Maybe I should have elaborated a bit more; I think maybe the sorter should support not only #destinations but also ##sets. These 'sets' would be set with a command. This is needed as to not require 10 or 20 sorters for ever track divergence. In my opinion, sets should have support for nesting. Another suggestion also, the ejector block could be modified to eject you if you have reached said destination when labelled with #destination or possibly ##set if you purposely wish to make manual switchover. Even in this server, I believe that with the above implementation I could probably implement the removal of the need to get out of the cart to switch lines.
I think sets would be painful as hell to setup for every combination. It's my opinion that we can just implement some directed graph traversal algorithm.
I can see where you are coming from and I kind of have to agree, but if you just had one set for each line then, after finishing a line, and have still not been ejected, a minecart sorter could put you back on the line in the other direction. I understand this has flaws, but I fail to see what a graph transversal algorithm is due to never having heard this term before, but since you are an experienced programmer and understand such concepts, I trust your view on implementation.
Having the server do all the work (graph traversal) would be great, but how do you deal with unloaded chunks and unlabeled nodes? That would be a huge pain in the ass. Can your code load the chunks needed to follow the rail to every endpoint? If it can, what performance issues would need to be dealt with? How about this instead. For selecting a destination, you duck-right-click a sign. The sign code is this: [Destination] Rail Network That's it. Destinations are simply 15 character descriptions (one sign line). They can be whatever you like, and ideally are human readable. They are case and punctuation sensitive. And they are not described on the [Destination] sign at all, though they are displayed on it. Rail switching signs look like this: [Switch] Rail Network Again, nothing else. No other lines. All the magic is in the next sign type. [Rail Network] A destination Another stop Someplace Next to a track, either above ground or below, you put one or more signs listing the destinations that can be had down that track. This sign must be within 32 meters of the [Destination] sign in order for it to list it as a valid stop. The sign must be next to a track as well, to indicate to the [Switch] the destinations that are in that direction. It's important to point out that 'Rail Network' can be any 13 character string... 'Blue Line', 'Summer Rail', 'Subway', 'Bob's Railway'. Finally, at a particular destination you have this sign: [Exit] Rail Network A destination This sign kicks you out and deletes the cart, no interaction needed. Here is how it works from the view of the passenger. Near the entrance is the [Destination] sign so that a player can choose their destination. As the player clicks the sign, it re-writes itself. The fourth line changes to display the current destination. When the one they want is displayed, they duck-right-click to select it, getting a short confirmation text in their chat. Then they hop on the rail, and the [Switch] signs send them down the line that has a destination listed shortly after that matches the one they chose. They can pass through multiple stations on their way. When they reach their destination, they are kicked out by an [Exit] sign, so even if they AFK they get to the right place. Multiple players can ride the same line and go to different destinations (though they will need to have a minimum distance between them to prevent switching errors). From the point of view of the track designer, they place the [Destination] and [Switch] tracks. After each [Switch], they place visible or invisible [Rail Network] signs that list the possible destinations. After every switch, they need to be sure to place the full complement of destinations for the left and right choice. Adding destinations means re-writing signs or adding additional signs. If possible, sk could write it so that a switch can look forward a switch or two to see all the destinations along any choice (within a range limit), so that multiple [Switch]es can be done immediately after one another. And here is how it looks from sk89q's point of view: When they player selects a destination, a tag is attached to the player. @Rail Network = Destination. This tag is 'read' by each switch as the player goes over it, and the switch looks at the destination signs just downstream to decide whether to send them left or right. The [Exit] sign removes the tag from the player after it kicks them out. For performance reasons, each station may not see changes done to the [Rail Network] signs except when the [Destination] sign is placed... this also allows rail designers the freedom to update destinations, but not put them into effect until they are finished by breaking and replacing the [Destination] sign. When the [Destination] sign is placed, it first looks for any [Switch] signs nearby and tells them to update. Each [Switch] looks down all three rails from it a limited distance for [Rail Network] signs along the track, and creates a table of decisions 'From track A, I need to be on position B to send them to destination C'. So it builds a decision network to allow very quick (not CPU taxing) decisions later. It passes the list of all the destinations it knows how to reach back to the [Destination] sign. The destination sign takes all these destinations, removes duplicates (which will be normal for any station with more than one switch), and adds them to its list for players to select. And that's it. This allows for a nearly unlimited size network, though the larger the network the more signs will need to be placed at each station to tell it how to get to every destination. If the distance a switch looks to find signs is limited to 32 pieces of track, that still allows for networks with hundreds of destinations. And that's just one line! You can have more than one [Rail Network] to extend this even further. It does not depend on looking into unloaded chunks to find out what destinations are down there. No information needs to be transmitted (the information is on the player, which the [Switch] signs read via code). It allows for an unlimited number of players to be riding the rail at the same time. It's not demanding of the server CPU except when placing a new [Destination] sign which triggers a re-calculation of the nearby [Switch]es. It's very simple for players to use, borrowing on their experience with the [Shop] sign usage. And it is pretty easy for rail designers to use as well, since they don't have to choose left or right, on or off, or any of that... the [Switch] does the heavy lifting on how to get the cart going the right direction. If you use a couple reserved destination words, like Unknown and None (they wouldn't be listed on the [Destination] sign), then rail station designers can use them to fix mistakes. Someone hop on without selecting a destination? [Exit] None will fix that. Is a player going the wrong way down a track? [Rail Network] Unknown destinations can route them into a loop so they are going back the proper way, or even simpler just eject them with [Exit] Unknown and have them re-select the destination. To sum up: Three normal sign types. [Destination], [Switch], [Exit]. One dynamic sign type that is searched for by the [Switch]: [Rail Network]. --------------- [Destination] Rail Network A destination --------------- [Switch] Rail Network --------------- [Exit] Rail Network A destination --------------- [Rail Network] A destination Another place Third choice --------------- An example is located on James @ -200,-1000. Obviously, since the signs do nothing it doesn't work, but it demonstrates the layout. Note that the signs are placed to be read, not where they would necessarily be in a real network. Also note how placing signs in all three directions allows the network to function no matter which direction the cart is coming from. (To keep it interesting, the switches change randomly; they are not making any actual switching decisions).
