Seite 1 von 3
Ideas for the Future
Verfasst: Freitag 23. Juni 2006, 14:38
von Blöky
Tracks closer to each other
If the maximum value of elements/km could be set to 200, the distance of paralell tracks would be 5 m which is close to reality (standard is 4__4.5 m).
However I know the vehicles and trains would became shorter. Is this indeed a matter?
I often bulid long-distance layouts where scale is 20/km. So the trains are too long, but I can (and I think anyone can) handle its consequences anyway.
I think that too-short vehicles will cause less problems than too-long ones do.
More directions than angle of 45°
In city layouts there ara a hell of streets which are almost but not totally paralell.
In country layouts I'd like connect neighbouring stations with a straight line not with a courve or zig-zag, if the geographical conditions suggest it.
If no possibility, the distances (for crossing lines) will be incorrect and/or the landscape picture will be too ugly.
Extremely when trains run by zig-zag.
What solutions are possible?
a) Bezier courves like in Rail3D Classic.
I don't treat it very good because the the extension of network requires demolishing the bezier (eg. inserting a turnout) and stations, signals also remain in 45° state.
b) Total free lying tracks (like in Rail3D 2kd or in Eisenbahn.Exe)
It would be the most elegant solution, but I don't want to suggest this because it requires a totally new model of track data against that exists in Bahn.
But Bahn layouts - theoretically - can be converted into such format.
(And for displaying, see remarks after (c))
c) A compromise: straighting 45° courves
You can think it's ambigous that the tains and else vehicles would take the courves too ugly. I don't think this is problem because they also take the courve by this mode in existing Bahn versions [img]icon_smile.gif[/img] it couldn't be more ugly [img]icon_smile.gif[/img]
The essence of this solution is, of course, that stops, signals and else track features could be installed on these track/road sections. By this way large stations or tram terminals could be built in the correct direction.
At (b) and (c) the greatest problem is displaying.
Of course I don't insist on a perfect 3D graphics. But it is a question how to display trains/buses running to new directions?
In Bahn the vehicles running "horizontally" and in 45° are described by side wiew. "Vertically" running vehicles in a combination of front/rear and top view.
There is no problem where the new direction is between the horizontal (East-West) and 45°. But how to display a vehicle which runs in a direction between North-South and diagonal?
I can't immagine another way than using an isometric view, combining the side-, fornt/rear- and top views of vehicles. Examples are Rail3D Classic and VlakoSim.
In Rail3D Classic the model is more difficult because it properly displays some details, e.g. you can "look through" above the "nose" of a V200 etc. In VlakoSim the vehicles all are "bricks", but the view is nice enough [img]icon_smile.gif[/img]
I wait for the forum members' opinion!
Re: Ideas for the Future
Verfasst: Freitag 23. Juni 2006, 18:17
von sepruecom
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Tracks closer to each other
If the maximum value of elements/km could be set to 200, the distance of paralell tracks would be 5 m which is close to reality (standard is 4__4.5 m).
However I know the vehicles and trains would became shorter. Is this indeed a matter?
I often bulid long-distance layouts where scale is 20/km. So the trains are too long, but I can (and I think anyone can) handle its consequences anyway.
I think that too-short vehicles will cause less problems than too-long ones do.</tr></td></table>
This idea is not new, it had not been done yet
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
More directions than angle of 45°
In city layouts there ara a hell of streets which are almost but not totally paralell.
In country layouts I'd like connect neighbouring stations with a straight line not with a courve or zig-zag, if the geographical conditions suggest it.
If no possibility, the distances (for crossing lines) will be incorrect and/or the landscape picture will be too ugly.
Extremely when trains run by zig-zag.
What solutions are possible?
</tr></td></table>
Don't forget that Jan Bochmann ist doing this program alone. These changes you propose here would take years to make, because the structure is totally different from the structure today<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
a) Bezier courves like in Rail3D Classic.
I don't treat it very good because the the extension of network requires demolishing the bezier (eg. inserting a turnout) and stations, signals also remain in 45° state.</tr></td></table>
This would destroy todays structure, which tells, that every element must have a width of 1. Also todays courves are static, and it would be hard to implement that (many different fields), otherwise you would have to change the whole data structure to make tracks non-static<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
b) Total free lying tracks (like in Rail3D 2kd or in Eisenbahn.Exe)
It would be the most elegant solution, but I don't want to suggest this because it requires a totally new model of track data against that exists in Bahn.
But Bahn layouts - theoretically - can be converted into such format.
(And for displaying, see remarks after (c))
</tr></td></table>
Yes, they could, but as you say, it would take a very long time to do this.<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
c) A compromise: straighting 45° courves
You can think it's ambigous that the tains and else vehicles would take the courves too ugly. I don't think this is problem because they also take the courve by this mode in existing Bahn versions [img]icon_smile.gif[/img] it couldn't be more ugly [img]icon_smile.gif[/img]
The essence of this solution is, of course, that stops, signals and else track features could be installed on these track/road sections. By this way large stations or tram terminals could be built in the correct direction.
</tr></td></table>
You would not have too many opportunities by this method. Today tracks like that have "edges" oder consist of longer strait track parts.
Todays raphics turn in a 45°-angles, that means, it does not get more "beautiful" if cars are turning upwards. And of course the same problems as mentioned before<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">
At (b) and (c) the greatest problem is displaying.
Of course I don't insist on a perfect 3D graphics. But it is a question how to display trains/buses running to new directions?
In Bahn the vehicles running "horizontally" and in 45° are described by side wiew. "Vertically" running vehicles in a combination of front/rear and top view.
There is no problem where the new direction is between the horizontal (East-West) and 45°. But how to display a vehicle which runs in a direction between North-South and diagonal?
I can't immagine another way than using an isometric view, combining the side-, fornt/rear- and top views of vehicles. Examples are Rail3D Classic and VlakoSim.
In Rail3D Classic the model is more difficult because it properly displays some details, e.g. you can "look through" above the "nose" of a V200 etc. In VlakoSim the vehicles all are "bricks", but the view is nice enough [img]icon_smile.gif[/img]
I wait for the forum members' opinion!
</tr></td></table>
In Bahn you can run 3000 Vehicles at the same time. You somehow have to choose between nice graphics and fast simulation. With todays static tracks it is not very hard to calculate the actual position of a train, because the track pieces are fix. With the other methods you would have to calculate the tracks again and again to match the position of the train for displaying...
Greatings, sepruecom
Re: Ideas for the Future
Verfasst: Donnerstag 29. Juni 2006, 13:31
von Blöky
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">In Bahn you can run 3000 Vehicles at the same time. You somehow have to choose between nice graphics and fast simulation. With todays static tracks it is not very hard to calculate the actual position of a train, because the track pieces are fix. With the other methods you would have to calculate the tracks again and again to match the position of the train for displaying...</tr></td></table>I don't think it is a very new against calculation on 45° direction. However it really neds a 3rd algorithm further to straight and 45° lines.
But since its existence, Bahn has extended by a lot of new algorithms [img]icon_smile.gif[/img]
If a vecicle runs on a 2:1 direction, it doesn't require any of the older types of calculation but the new one only, does it?
Re: Ideas for the Future
Verfasst: Freitag 1. September 2006, 11:03
von Blöky
In the topic "Wünsche ..." I've read a suggestion for ability to change the basic route of train.
Sorry I am not familiar in German, so I write my answer here.
I think about a new train identifying concept for some years, but I haven't meant it anywhere till today.
Its essence would be not to use routes for identification, but using the home depot. Routes would be given for all goings-on-duty.
The train identifiers would consist of <depot> and <number>
This system would be useful when there are trains which go ond-duty more than once within a day (or a week cycle from 3.84) and they begin ther trip with different routes.
In conversion the identifier could be created form the home depot and an auto-increment value from 1... . The duty beginning routes could be same as the original basic route.
At data changing points the reference "R=*" could be interpreted as "gets back the route for on-duty".
But maybe, the problem mentioned above is not solved satisfically by this way.
I think to generalize the basic/current route concept that the current routes could be pushed in a stack, if they are directly changed at a ch.point or a timing pt. At changing points it's needed a new feature for recalling the previous route from the stack. "R=POP" is not correct because POP itself can be a route name [img]icon_smile.gif[/img] , perhaps "R=%" cuold be useful.
When the train returns to the depot the stack should be cleared.
Re: Ideas for the Future
Verfasst: Freitag 1. September 2006, 13:29
von Sascha Claus
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Its essence would be not to use routes for identification, but using the home depot. Routes would be given for all goings-on-duty.
The train identifiers would consist of <depot> and <number></tr></td></table>
Sounds useful for the good old times when every train had a different route, but everyone making tramways, metros, suburban or other networks with line-oriented trains will love this system. [img]icon_sad.gif[/img]
Re: Ideas for the Future
Verfasst: Montag 4. September 2006, 17:50
von Gast
Identifying trains by this method as opposed to route and number would mean you assign each train its full diagram rather than its route, which would be useful for real networks, since in general a train does not operate the same service repeatedly all day. For example, a HST out of Paddington starting from Landore depot might have terminated in Swansea, Cardiff, Bristol, Exeter and Worcester (with an ECS move via Cheltenham thrown in for good measure) in the space of a day.
At the moment, I'm naming my trains based on one of three factors:
1. Where platforming becomes an issue (long-distance services), using a diagram - e.g. for train #1 at depot AB, the route code is "AB1"
2. Where platforming is less of an issue than a complex network available for the unit (mainly suburban services), a "headcode" is used to determine the destination, or the routing, e.g. all suburban services to station A get route "A", etc. This is route-code economical, in that if you have two routes which start at different points but share a destination, you may need only one code.
3. Where specific unit types work specific services, the route code will be the classification of the unit - this lets you do things such as variable stopping points (a 2-car MU might stop 2/3 along the platform, whereas a 10-car hauled set might fill the entire platform).
All of these approaches may require extensive use of data changing points for things such as defining an empty move (e.g. train goes to another station 50km away to form its next working without first going to depot)
One of these days, I'll have to post fuller details of the things I've done as regards routing, signalling, "real" depots (with trains stabled in full view in sidings instead of a "magic bag" depot), etc. especially as the only online guide I found is in German (a language I don't understand) using seemingly German railspeak (somewhat difficult to guess the British equivalent), and the standard of English in the manual is (understandably) not brilliant. I wish I had the time to work on improving the manual, but time is a fickle mistress ...
Ding-ding,
C.
Re: Ideas for the Future
Verfasst: Dienstag 5. September 2006, 17:57
von broodje
hmm, I never use depots, mainly because there are no depots in the Netherlands for overnight stabling. I use timing points to halt trains for the night at a yard. With "xx(R=YY) boards I can force the trains to their new routes. I build the whole of the Netherlands this way, where some intercity train start and end at totally different routes without any problem. (I never use the 'base route' for any pathing). I would not know how a 'real life' railway layout would benefit from this feature.
Granted a train in the Netherlands with the number 22** (where 22 is the route and the stars are the train number) will ride the same route all day, 22** will always go to breda, it will never be routed to Maastricht for example. So any exception to this rule can easily be caught by giving the junction timing codes for routes.
The English system is a bit harder were an '1A**' train can go to Abberdeen or Newcastle for example. But even then these trains should drive to a 'known' timing pattern so junctions could easily be 'time coded' for a route.
Re: Ideas for the Future
Verfasst: Freitag 8. September 2006, 20:06
von Gast
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">
Zitat:</span></td></tr><tr><td class="quote">hmm, I never use depots, mainly because there are no depots in the Netherlands for overnight stabling. I use timing points to halt trains for the night at a yard.</tr></td></table>
This is roughly how I'm doing things - rather than a single "magic box", each siding has a depot point, so the trains going off-duty are routed to the correct siding, then the off-duty status cancelled (it doesn't go fully off-duty, as the train will probably then come out facing the wrong way). At the end of the siding is a timing point just before the reversing point. Since I always know which train will be waiting at the timing point, I know when it needs to be let out
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">
Zitat:</span></td></tr><tr><td class="quote">The English system is a bit harder were an '1A**' train can go to Abberdeen or Newcastle for example. But even then these trains should drive to a 'known' timing pattern so junctions could easily be 'time coded' for a route.</tr></td></table>
1Axx will always be the Intercity services to London, though in some areas there may be alternative routes, e.g. in the Western region, services from the South West to London will be 1Axx, even though a train from Plymouth might come in via one of three routes (Westbury, Bristol/Bath, Bristol/Bristol Parkway). The main exception is services to Waterloo, which is in the Southern zone - they are coded 1Oxx or 1Lxx.
However, the system was devised back in the day when you would display the running number on the front of the train (hence being a "head" code), which came from an earlier system of an arrangement of lamps to determine only the type of train. At the time, in the absence of electronic train describers, they were used to tell the signaller what the train was.
An alternative system developed in the Southern area indicated routing rather than a specific movement, and used only two digits. A train at Salisbury showing "61" in front was the fast service between Exeter and Waterloo. Similarly, rugby trains to Twickenham run either via richmond or Kingston. The signaller at the crucial junction would decide which way the train needs to go depending on whether the front read "22" or "23".
What I've done on the suburban network in my network is something of an extension to the Southern system, that treats Up and Down services differently. Services to the same destination originating from different places which do not diverge from each other share the same route. So, trains running ABCDEFG, CDEFG and DEFG use the same code when heading towards G, as would HJKDEFG, since once it converges it then doesn't diverge. ABKLEFG, however, uses a different code, since is diverges from ABCDEFG before rejoining it. In essence, at a turnout you're giving the route as something like "All trains to station X".
Perhaps this is getting too much towards a discussion of specific aspects of BAHN as they already exist.
Re: Ideas for the Future
Verfasst: Montag 11. September 2006, 10:18
von Gast
My main problem with the 'off duty' status is that I'm not sure where the train exactly is when it needs to go off duty. However I do know at what location a train should go off duty.
The off duty is code not really useful (in the data change signs) You can't set a train to 'Off-Duty now' (eg time coded using I=*). You always have to supply an on- and off-duty time. And a train can be stabled at different sites in the country every day. (eg on Monday it starts in The Hague while it goes of duty in Groningen), because of that it is easier to set a train to c=S (special state) and route it to the depot using junctions with time-coded routes.
Considering this it would be handy to have a way to set a train to 'off-duty-now' without setting that time in that little on/of duty table in the train detail window
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">
Zitat:</span></td></tr><tr><td class="quote">1Axx will always be the Intercity services to London, though in some areas there may be alternative routes, e.g. in the Western region, services from the South West to London will be 1Axx, even though a train from Plymouth might come in via one of three routes (Westbury, Bristol/Bath, Bristol/Bristol Parkway). The main exception is services to Waterloo, which is in the Southern zone - they are coded 1Oxx or 1Lxx.
</tr></td></table>
yep sorry for that bad example. By the way in the 70ish there were 1E** trains from Edinburgh to London so not all express trains to London from the north were 1A** either
.
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">
Zitat:</span></td></tr><tr><td class="quote">What I've done on the suburban network in my network is something of an extension to the Southern system, that treats Up and Down services differently. Services to the same destination originating from different places which do not diverge from each other share the same route. So, trains running ABCDEFG, CDEFG and DEFG use the same code when heading towards G, as would HJKDEFG, since once it converges it then doesn't diverge. ABKLEFG, however, uses a different code, since is diverges from ABCDEFG before rejoining it. In essence, at a turnout you're giving the route as something like "All trains to station X". </tr></td></table>
Hmm yes, complicated stuff
, I guess I would have set specific junctions to 'diverge' the train at the right time, as you know where a train is at a specific moment (if you use a real timetable of course).
How would you handle a train halting at different platforms throughout the day?
I had a try at Kings Cross for example where all 1A** trains don't have a 'fixed' platform to halt at, they all share platform 1-7. In fact; the sub-urban routes have the same problem: they share platform 7-11 almost at random. Almost every junction into KX needs junctions that use time slots for routes because I can't join the trains at the right platforms otherwise. I tried using signals, but then you can’t make trains join, or all trains will double dock even if the platform is filled from start to end.
I have the same problem at PBRO some 1A** trains pass the station while others stop there. So I had to find out for every train at what time they pass the station, so I could set up the junctions accordingly.
So my overall conclusion was that the English numbering system sucks if you want to use it in bahn [img]icon_razz.gif[/img]
Re: Ideas for the Future
Verfasst: Dienstag 12. September 2006, 10:31
von Blöky
When I build my layouts, I plan the tracks so the trains of a given route always use the same tracks.
If there are specific cycles in which the train(s) change route I use data changing point - when possible - immediately after their departure station or I use time-coded junctions before destination (e.g. a train Budapest - Cegléd doesn't return but later it will run through to Szolnok or Kecskemét etc. For a Budapest - Szolnok through train I use separated route code)
In this case I use the simulation itself to observe that when the train arrives to the destination (Cegléd in the example above) and I record a time interval which can catch the train with security.
The alone problem is when the trains frequently follow each other. By this cause, if I set a frequent suburban traffic usually I don't use route changing.
Users who have tried to run Mark Goodspeed's Rail3D can notice an ability that routes can be changed among the train data ("Diagram" menu). Can it be biult in to the JBSS Bahn?
Re: Ideas for the Future
Verfasst: Mittwoch 13. September 2006, 12:57
von broodje
I have build the Netherlands true to the real thing (the trackplan can be found at
www.sporenplan.nl ) so I did not have the option to run trains on their dedicated lines. For trains that follow each other closely I did use 'a' and 'b' routes. In fact I did use a construction where a train changes route after splitting and changes back to the main route as soon as it past the junctions on a station.
The only real drawback of all these timed routes is that when 1 train fails somehow the whole system goes down and trains can end up anywhere
.
ps. I was the previous anonymer user, I forgot to log in.
Re: Ideas for the Future
Verfasst: Freitag 8. August 2008, 18:08
von Blöky
Now my asking is a much littler:
INHERITING TEXT OPTIONS
I often use the same colour and background in layout text formatting.
E.g. black text on white background. This was the frequent livery of old station name tables.
So I always have to format each text bar step by step (dark in night / define color / selectig / OK / backgr. dark in night, etc.) even if I use the same colours to them.
Is it possible to let this function work by the same way as creating stops?
When I create a stop the properties are preserved and the stop dialog box opens with the properties previously used.
For texts, I imagine the foreground and background colour to preserve and reuse them at the next opening of the text dialog box (when creating new text).
It would allow a much quicker inserting series of text.
Re: Ideas for the Future
Verfasst: Samstag 9. August 2008, 01:43
von micha88
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">Now my asking is a much littler:
INHERITING TEXT OPTIONS
I often use the same colour and background in layout text formatting.
E.g. black text on white background. This was the frequent livery of old station name tables.
So I always have to format each text bar step by step (dark in night / define color / selectig / OK / backgr. dark in night, etc.) even if I use the same colours to them.
Is it possible to let this function work by the same way as creating stops?
When I create a stop the properties are preserved and the stop dialog box opens with the properties previously used.
For texts, I imagine the foreground and background colour to preserve and reuse them at the next opening of the text dialog box (when creating new text).
It would allow a much quicker inserting series of text.</tr></td></table>You may use "Copy to Clipboard"...
Re: Ideas for the Future
Verfasst: Samstag 9. August 2008, 15:45
von Rolinator
@ broodje
Is it possible to download your layout somewhere?
Because I'm very curious about it
Roland
Re: Ideas for the Future
Verfasst: Samstag 9. August 2008, 18:03
von Blöky
<table width="90%" cellspacing="1" cellpadding="3" border="0" align="center"><tr> <td><span class="genmed">Zitat:</span></td></tr><tr><td class="quote">You may use "Copy to Clipboard"...</tr></td></table>
But I do not want to copy the whole text [img]icon_wink.gif[/img]