[Suggestion] Catenaries and pantographs for electric locomotives
wooky opened this issue · 33 comments
One way for electric locomotives to get electricity is through overhead lines. They should be cheaper to make than electric tracks, as such:
These wires do not actually store any energy, but rather just get it from other energy sources, like generators and wires. They still lose energy over distance, so it makes sense to shorten the length of the catenaries.
Note how the catenaries are rendered - they are rendered in the top part of the block so that placing them underneath under blocks for decoration, like metal posts, makes sense.
For the locomotive to actually collect energy, we'll need a pantograph.
Pantographs have durability (currently 20,000) and it decreases whenever the locomotive is moving and touching the wires, to simulate friction. If you want to destroy the pantograph even faster, just wedge it into some block and the durability will be falling by 100 every so often.
The electric locomotive now has a special slot for a pantograph:
Placing the pantograph will render the locomotive as such:
Admittedly, this is not the best design, but it's pretty understandable.
I think the main advantage over electric rails is that you can now run your train over high speed rails and still be able to collect energy from the overhead lines.
The disadvantage, though, is that these catenaries are just as lossy as regular wires, but they do not store any energy, so it's up to the player to implement the design to reduce energy loss. Plus, since the pantograph has durability, the player has to maintain the trains to make sure they don't run out of power in the middle of the tracks.
As you can see, the code is pretty much ready. I would like to hear some opinions before submitting pull requests. Note that not only will this require a change in the code, but also in the API (two new interfaces are added, IElectricDistributor for the non-energy storing wires and IPantographProvider to be able to provide a pantograph) as well as a few lines in the localization files.
@CovertJaguar How will this be?
I definitely still support this option as having to run on electric rails has killed me a few times...
The only one point I want to make though is that the pantograph should either be angled and/or jointed (like real ones), having it go straight up like that in the images just looks weird.
I think perhaps a fishing pole/antenna like setup could work well in Minecraft. Like the Electric Buses use.
Yep, that's pretty much what I meant, optionally with a "joint" close to the base so it doesn't sit too far behind the cart.
Something like this...
¢¢ from a user: (and some brainstorming)
- Unless maintenance can be automated, having a durability will just be a PITA. Also if it can be automated, it would be useless to have it in the first place. Therefore I'd rater have infinite durability. Maybe using a little bit more energy would be a better alternative.
Maybe it could be a config option: Durability = 0 → infinite, otherwise track distance in meters.
- If the wires are a replacement for electric tracks, they can as well be part of the track. Power distribution on tracks is already implemented. isn't it? Tracks would transmit power if they are electric or have a wire, but only locomotives with the pantograph could receive from wires. If a track has both, it will forward the energy, if not, the neighboring track must provide the same kind of conduit.
Because of using the track's power mechanism, wires would not transmit power unless if it's above a track, but that would be OK if there was a shunting wire to connect a neighboring track (instead of adding powered rails and wire frame and a ground-based shunt).
- Since (2) turns around the mechanism, from "hang on a pole/block" to "place on rail", the wire would need a support every (e.g.) 16 or 32 blocks. Otherwise they block the rails.
closing not because of kit but because this is hard to implement while people don't have too much interest.
I'm hoping to be able to keep all discussions in this thread.
Right now I'm still ironing out a few bugs and trying to come up with the best way to let wires communicate with each other without causing too much lag. I'll post an update and start committing my code in the upcoming days.
Wooky, that looks pretty awesome. I would think as long as your code is in a releaseable state, it should be fine to create the PR which provides an easy means of seeing the scope of the code changes.
Have you already chatted w/ CJ about this feature?
Sent from my iPhone
On Jan 28, 2015, at 11:28 PM, wooky [email protected] wrote:
One way for electric locomotives to get electricity is through overhead lines. They should be cheaper to make than electric tracks, as such:
These wires do not actually store any energy, but rather just get it from other energy sources, like generators and wires. They still lose energy over distance, so it makes sense to shorten the length of the catenaries.
Note how the catenaries are rendered - they are rendered in the top part of the block so that placing them underneath under blocks for decoration, like metal posts, makes sense.
For the locomotive to actually collect energy, we'll need a pantograph.
Pantographs have durability (currently 20,000) and it decreases whenever the locomotive is moving and touching the wires, to simulate friction. If you want to destroy the pantograph even faster, just wedge it into some block and the durability will be falling by 100 every so often.
The electric locomotive now has a special slot for a pantograph:
Placing the pantograph will render the locomotive as such:
Admittedly, this is not the best design, but it's pretty understandable.
I think the main advantage over electric rails is that you can now run your train over high speed rails and still be able to collect energy from the overhead lines.
The disadvantage, though, is that these catenaries are just as lossy as regular wires, but they do not store any energy, so it's up to the player to implement the design to reduce energy loss. Plus, since the pantograph has durability, the player has to maintain the trains to make sure they don't run out of power in the middle of the tracks.
As you can see, the code is pretty much ready. I would like to hear some opinions before submitting pull requests. Note that not only will this require a change in the code, but also in the API (two new interfaces are added, IElectricDistributor for the non-energy storing wires and IPantographProvider to be able to provide a pantograph) as well as a few lines in the localization files.
—
Reply to this email directly or view it on GitHub.
It does use the same energy system, but I have to write a different energy distribution system than the ones implemented.
What I ended up doing is setting up an "invalidation" system, so if you remove a set of wires from any energy sources, it will eventually be "invalidated" and you won't be able to pull any energy from it.
wouldn't it be less difficult to have high speed powered rails? typically these trolly style systems were not exactly quick, and it doesn't make sense to have high speed trains using this. something like mag lev rails or something would be pretty awesome. i know that hovering trains aren't going to happen but i think you know what i mean.
One comment, I've actually been thinking about rewriting the electric grid system to be tickless, since there does seem to be some performance costs associated with large electric track networks. It sort of looks like that's what you did with the catenaries, thoughts on merging the two systems?
Also, can the catenaries work as general wires? (they shouldn't)
I think one problem with a tickless catenary would be how to let the catenaries know where the power sources are (and if there are any). One way is to have a giant list of blocks providing the shortest path to the power source, but when I tried doing it, I couldn't get it to behave properly without it filling up with random, nonexistent blocks. Maybe you'll have better luck implementing it.
I don't believe they can act as wires because they are not extending IElectricGrid, and right now the only thing that can request power from an IElectricDistributor (which requests power from an IElectricGrid) is an electric minecart that extends IPantographProvider.
Ok, so they are not tickless now then? I can work with that. Graph traversal isn't really necessary, btw.
this is great! Though the pantograph looks a little weird going straight up, the arm probably should have an elbow in the middle or even use the classic diamond design.
Question though, I don't see it mentioned anywhere, is the height fixed to what I see of ~2.8m or is it variable?
one thing to test for is behaviour across long distances and unloaded chunks, the later would be an unlikely scenario as you would still need to deliver power to the nodes regardless of the medium, but how would a setup about 2km long with at least 16 nodes behave, a distance cap on the source searching would definitely be needed...
I wanted to make the arm go at an angle, but creating renders that are not upright is not an easy task; same for the height. I might revisit this at a later time.
I don't think a distance cap is necessary because each cable gradually transfers its energy sources to the neighboring cables, so if your source is really far, it might not even be able to reach to distant cables. From a realism perspective, it doesn't make a lot of sense to get energy from a source really far away, but considering that this is Minecraft, anything is possible.
Le 06/02/2015 05:42, wooky a écrit :
I can see a few issues with that. For instance, what if one cable is
broken? How would the cables past the broken one know that they are not
connected to the pool? Or what happens if you have wires going in a loop
after being disconnected from any energy source? I believe it's tiny
issues like these why it's better to have some sort of cable traversing
function. Plus, no need to write any of the information on disk.I'm willing to support whatever idea you have, but it needs to take into
account all these tiny issues.
KISS principle:
Have catenaies binary powered / unpowered states.
Only do connected traversal within a cubic chunk 16x16x16 (all
coordinates modulo 16):
- It will prevent needing to chunkload for connexion traversal.
- will prevent all chunk state issues (like with redstone)
- It will save from complex layouts, branchings, redundant routes
blocking...
Only update connexion on block-change or powered state change.
Once a power source connect to catenaries, it form a group with
registered power source coordinates.
When train connect to a catenaries bloc:
- It will issue a state update on powersource group within its current chunk
- If catenary is powered, it get powersource coordinates and issue a
call to drain on the power source (pole).
Have poles be power source sockets or receivers.
Leave energy distribution up to user preferred mod. (EU/RF).
Maybe allow tuning poles to receive energy wirelessly:
- Will save the need to deploy long distance and complex wired energy
networks.
On a user point of view:
- A minimum of 1 pole every 16 blocs will be required to power catenaries.
- Maybe setup an energy emitter to transmit power to poles on a given
channel and use-up EU or RF as input.
each block of contact line (catenary) should have an nbt tag for at least one power source, upon place or break it should traverse neighbour wires with the like source and update them. The same tag could also have the direction the source was initially in so the traversal is only sent down opposing blocks.
The pole based idea above sounds like a good option, alternatively we could take the real-world approach and have the existing energy wires interact with the contact line the same way catenaries in the real world have the messenger cable to deliver the bulk of the current over the line between substations. Droppers could be rendered every 4th block (modulus).
Full-poles probably shouldn't be a requirement as you never see them in tunnels and some station setups.
Rather than source searching, its better to just create a pool and have blocks add themselves to the pool when they load. The pool would have a communal energy charge from which to draw. Some effort must go into managing when blocks enter and leave the pool, and there are still questions surrounding how disk serialization will work, but that's the general idea.
I can see a few issues with that. For instance, what if one cable is broken? How would the cables past the broken one know that they are not connected to the pool? Or what happens if you have wires going in a loop after being disconnected from any energy source? I believe it's tiny issues like these why it's better to have some sort of cable traversing function. Plus, no need to write any of the information on disk.
I'm willing to support whatever idea you have, but it needs to take into account all these tiny issues.
Well if you're pool was stored as a self populating node graph, it would fairly trivial to split the pool on a node. Trickiest part is that you'd need to do a little path searching between the two disconnected nodes to see if there is an alternative route.
Why not ditch the concept of having a place-able block for the cable, and I hate to say this, take a page from build craft and it's land mark system, provided that their is a special overhanging pole straight within x (16) blocks of the last, a decoration cable is displayed like the red line that connects the land marks. that way you would only need to network the poles which is a lot less calculating.
You could make a spool of cable item that one can use to connect poles to one another which is consumed in the process, giving user control on the network layout, and if for any reason the connection is lost, two snapped cable items could drop, or something like that.
The concept of a spool was exactly my plan initially, but for it to be successful, I can't use the TileMachineDelta block that Railcraft uses for all its electrical wires (or at least I didn't manage to get it working properly).
I like mrfrase3's idea. From a user standpoint, placing a bunch of wires in the air one block at a time seems pretty tedious. especially if the wire has a small cross-section with which to click on.
It could be done in the same way the Force Track Emitter works. Place your "markers/power poles" whatever you want to call it, and then just spawn blocks in between them. It shouldn't matter whether they are machine blocks or not (and honestly there is nothing forcing them to be machine blocks anyway).