Roujin wrote:
Nope. In this case the bits of normal rail occupying the same tile as a bit of electrified rail are electrified as well. There might only be some measure to display it as if it weren't.
That's what I figured after reading planetmakers reply (I should think before I post ).
Anyway: does this feature cause bridges to always match the proper railtype. Perviously, when using total brigde renewal set and either Shinkansen or Metro tracks, I'd get monorail bridges.
Also I'm not quite sure if it is now intended for high speed trains to be able to run on default electric track, or that foobar's "trickery" of introducing a third track type is needed. One of the great advantages to me seemed that it would no longer be needed to build a completely seperate Shinkansen/High Speed network. This always requires extensive "restructuring" of urban areas around stations and railways. It would be nice if you could keep the inner-city part of the network the same, and have the trains switch to a high speed network outside the city, where there's space.
The feature is intended to adress both the bridge and the railtype compatibility problems, but it does not magically fix the existing GRFs. The GRFs have to be adapted to the new system first.
I.e. brige sets will provide new "blank" bridges that will get the overlay rail sprites automatically for each railtype. And the train grfs need to be recoded to give the appropriate railtype property for the new compatible railtypes. So a "Japanese Railtypes" grf that adds a shinkansen track [instead of replacing the monorail track], and a "Japanese Train" grf that makes Shinkansen trains compatible with regular tracks [and possibly a different speed limit depending on current railtype]
as saied in the 2cc trainset topic, i've made a new track set. The gfx are not yet in, but they will be soon(TM). A .grf can be found in the 2cc trainset thread, or it can be downloaded from the devzone.openttdcoop.org bundles site from todays nightly build. I.e. aprox 1815 CET. (Or CEST or whatever that daylightsaveingtime is called)
Building a certain type of rail cost X money.
Building a Station cost Y money.
Sometimes are Y < X, and then you can remove the station (via the "remove" tool, not dynamite), and the station is removed, but the rails are there, at a fraction of the cost.
I.e. If a rail cost 10k per tile, the station still only cost ~250 per tile...
I'm probably saying something stupid now, since if it is not, someone would have suggested it a long time ago, but anyway:
is it possible to (with some new variables or something) let the rail graphics of a tile depend on the (four nearest) neighboring tiles? That way one could have curvy rail without extending the map array.
If you can make curvy rail you also need to change the vehicle's behaviour, or it just does not follow your curvy rail. That means changing the time where the pathfinder is called, which means massive rewrites. Not to mention that in a long curvy corner you need to draw stuff outside of the tile causing massive glitching.
[2009-12-14] [12:59:01] * peter1138 wonders what's left with railtypes
[2009-12-14] [12:59:14] <peter1138> oh yes, depots and tunnels
[2009-12-14] [12:59:24] <Eddi|zuHause> peter1138: a varaction2 that can check the 4 neighbouring tiles?
[2009-12-14] [12:59:43] <peter1138> for what?
[2009-12-14] [12:59:50] <Eddi|zuHause> (like the elrail-catenary code does)
[2009-12-14] [13:00:58] <Eddi|zuHause> for example: chose on which side to draw the 3rd rail
[2009-12-14] [13:01:21] <Eddi|zuHause> or more insane: smoother looking curves
[2009-12-14] [13:02:42] <peter1138> yuck
[2009-12-14] [13:03:06] <weaselboy246> smoother curves? as in larger than 1 tile turn? think we need more sprites for that to look decent
[2009-12-14] [13:03:33] <Eddi|zuHause> anyway, my point is that it's not some revolutionary new concept, the code already does it, so it might as well be opened to newgrf
[2009-12-14] [13:04:03] <Eddi|zuHause> and then let the grf authors figure out how to abuse it
[2009-12-14] [13:04:06] <peter1138> not quite the same
1. You don't need to change the track much to make it look a lot smoother and easier on the eye.
2. A small change like this wouldn't look too bad with a train moving over it.
3. Trains move fast, tracks are stationary; a good looking track is worth the "cost" of a train not quite sitting on the rails.
Rubidium wrote:If you can make curvy rail you also need to change the vehicle's behaviour, or it just does not follow your curvy rail. That means changing the time where the pathfinder is called, which means massive rewrites. Not to mention that in a long curvy corner you need to draw stuff outside of the tile causing massive glitching.
If someone says you need to change vehicle behaviour, you can tell them not to use the newGRF that has curvy rail. It is obvious that it will be suggested from time to time though.
I'm not suggesting that anyone makes LONG curvy corners, If only the 4 nearest tiles are exposed, that would not be possible.
NekoMaster wrote:I support the idea of having curved rails : )
Its not "having curved rails" it is the whether or not there will be one route available to allow a grf designer to codec rails which look slightly curved under certain circumstances. This is quite a big difference...
*edit* On the subject of varaction2 variables it would be good to also have access to the current rail tile's orientation, ie whether it lies in the NE-SW/NW-SE/N-E/E-S/S-W/W-N direction.
Okay okay, since you asked I made two more examples. I draw something advanced, it is easier to change it when there are no intersections, as Zephyris showed. In the second sketch below the rail also responds to hills, but that could cause glitches I guess(?)
I also think detail like this becomes more important with fullzoom, maybe some time in the future it could be a good idea to let trains follow curves like these, and have more orientations as well, but whatever...
Variables:
Rails directions present on NE neighbour tile
Rails directions present on SE neighbour tile
Rails directions present on NW neighbour tile
Rails directions present on SW neighbour tile
Return format:
Bitmask encoding presence of rail, eg. binary 000001 could indicate straight cross-tile track, 000011 could indicate a crossroads, etc.
Variable:
Current rail direction being drawn
Return format:
Value corresponding to track orientation, eg. 1 could indicate a straight SW-NE track, 3 a bottom tile edge horizontal track, etc.
Using just these a curved corner track (ignoring vehicle movement code) would be possible:
1; check the direction of the current rail direction being drawn
2; check the tiles this rail could/would connect to to see if they have rail in the correct orientation to connect to
3; assign graphics according to the above, there are 9 variants which cover the 15 possible connecting track combinations (simplifying some junctions)
Amyways, enough open speculation, but this would be a very powerful set of tools for many bits of track eyecandy!
Snail wrote:Perhaps we could avoid having both 3rd rail and catenary on the same square: we could have engines, however, that should be able to keep running from a catenary-powered square to a 3rd-rail-powered one, although at a *very* limited speed (like 5 km/h).
i can't see this being either realistic or useful. I haven't seen trains switch from catenary to 3rd rail, but between phase-separated catenary systems, trains travel at high speed through an isolated section. getting to a standstill at that point would be fatal.
Well, I haven't seen it either, but I'd imagine it would be done at low speeds. When switching between catenary and 3rd rail, the pantograph needs to be raised (or lowered) and the 3rd rail shoes lose (or gain) contact with the 3rd rail. If this is done at high speed, I imagine it could result in damage to the structures or the locomotive parts...
Then again, I'm no engineer so I could be wrong. My point is, some sets would definitely need amphibious locomotives which could operate on both 3rd rail and catenary-powered tracks.
I do know however that railway by-laws in the UK only allow the changeover when trains are stationary.
As for the changeover points, arent we going to have to add a new section of track to link together tracks of different types, more specifically NG and SG.
EDIT: Apologies for dropping back to an early topic of convo in the thread.
). 
![:]](./images/smilies/pleased.gif "Pleased"){kind=small}
don't worry, be happy and checkout 
