BAHN400-Beta1

[GNock]

is available now - let's find out why the "4" is entitled in the version number.
The new features and enhancements should first be internalized, so that layouts can be set up even more flexible.
I've to put some additional information on the Internet, some downloadable as pdf, and I hope they will facilitate working
with the new BAHN.

The information is based upon my current knowledge (3. November 2012) of the first beta version and refer to the standard delivery status
of BAHN, future changes are reserved by the author, and they will not be updated here. This job every user should make itself during the beta phase.

1. Track Center Spacing Halved
2. Track Geometry Extended with 22.5° Elements
3. Assignment of Functions Simplified to Driveways
4. Easy Sorting of User Defined Graphics
5. Preview


1. Track Center Spacing Halved

The edge length of the track elements was previously 15.625 meters. The edge length and thus the track center spacing of parallel horizontal / vertical tracks is halved now to 7.8125 meters, and the converted elements have a quarter of their former size.

The good news for motorists among us: The cars stop in traffic now de facto bumper to bumper, and when a traffic light switches from red to green, more vehicles than before pass through the intersection. This reduces the duration of the rush hour, and you get much more relaxed to work in the morning and home in the evening.

a) The graphics of the driveways look compressed in zoom1; but in zoom2 with activated zoom2 files resembles the look of the previous
zoom1 representation.
b) For the coordinates should be noted that x and y now have twice the value as before to display the same position in the layout.
This concerns especially the conversion of geographic coordinates in layout coordinates - in mathematical formulas are the values
15.625 (m) or 64 (items / km) to be replaced by 7.8125 and 128, and the two reference coordinates x,y for the zero point in the layout are to double.
c) The maximum layout area is increased and now amounts to 131 072 * 131 072 elements, which corresponds to an edge length of 1024 km.
This means that the route networks of almost all European countries might be faithfully reproduced.

The most important thing for working with layouts up to version 3.86:
These layouts need to be converted to the new format. So for the driveways is to say:
The previous element will be replaced by a similar new and by an additional straight element.

The conversion transforms driveways and sceneries; driveways are done fast, but scenic elements like roads or surface waters might require a lot of time. To get an idea of it and not lose patience:
My network of Germany has a certain size, but so far relatively few surface elements and is therefore converted after about 13 minutes.
In contrast, the conversion of small urban layouts with many surface elements may be well more than 20 minutes;
so it's worthwhile in the morning first to start BAHN and load a layout to be converted and have breakfast then ...
Here you can compare the look of a freight depot in the future. Left the original, on the right the streamlined version with the halved track pitch.

I remember a discussion - I think it concerned the routes - in which a participant wishes he could insert a contact between two switches for a crossover track. Well, this is possible now, if you don't streamline your layout but leave it in its converted form.

2. Track Geometry Extended with 22.5° Elements

Elements in 22.5° geometry have been required in this forum too; now we can remove this request from the list. BAHN received - except buffer stops, tunnel entrances and ramps - 120 new elements in this geometry:
24 simple driveways
56 elements for crossings with straight tracks
32 simple turnouts
8 double slip points

Some structural bodies must be implemented in a combination of two elements, the actual function symbol and the corresponding element of crossings / switches / double slip points.

It will take some time until you have internalized yourselves, where each element is found and which elements belong together.
I have uploaded some graphics. Some of them you can download as pdf file for offline working.

The following figure shows inter alia the smallest possible circle in the 22.5° geometry.

Phantasie.png

In any case I'm looking forward to replace a lot of driveways, which are approximated to the reality with 45° curves, by straight lines in this geometry.

3. Assignment of Functions Simplified to Driveways

Function symbols are not here anymore, except for turnouts, tunnel entries and ramps. All driveways will be incorporated as simple elements.
Double clicking a track opens a selection window in which one of the functions can be selected and then supplied as normal with parameters.
Or a pre-activated function can be deleted and replaced immediately by another when needed.

And now I would like to highlight an enhancement, that will be in future no longer on the wish list:
Functions such as timing point and shunting point now can be assigned to curves too.

4. Easy Sorting of User Defined Graphics

Over the years, many user defined graphics have been created (sceneries, driveways, etc.), some of them are available for download
in archives, some of them are partially exchanged between BAHN friends. Not always is it possible to install files with similar elements such as platforms in the list of user graphics in consecutive file numbers, and then the clarity is easily lost.


BAHN now contains a function that simplifies the assembly of very similar groups - read more...

5. Preview


City Impression
A fine example of an interesting traffic management in Leipzig, created by Jan Bochmann. On his site Beta–Test he has uploaded an updated screenshot. You can imagine very well how detailed the city planning will be possible, often with two tracks per street, one for each direction, in a small area.

B400b0p6_Leipzig1.gif

Geographic Approaching
Train station and railway yard in Hannover-Nordstadt. The green circle shows the geographically correct position, the red one is a hitherto possible version.

HAN-Nordstadt.gif

So let's have a nice time with BAHN!
Best regards
Gerd

Edit: screenshots uploaded

[Chris]

Oh, cripes. Just as I was getting the hang of making beautiful curves. I suppose on the upside track spacing will now only be twice too big instead of four times.

As regards timing points:

The train goes ahead, reverses at the shunting point and will stop at the rear timing point (see lower part of the graphic).

Is it possible to also do the reverse? Something I would like to be able to do is use two linked timing points (same name, same data) but have the train only stop at one of the two. So, in the related picture, a train from the right would stop at the leftmost TP, turn around and ignore the rightmost TP, even if it was not occupying that track piece. In essence, for the train to "remember" that it has just stopped at that shared TP and not to stop a second time.

Or an already activated function can be deleted and if necessary immediately replaced by another.

I have yet to test this, but can a way piece have more than one function attached to it? For instance, something that would make my life (insomuch as BAHN contributes to it) much easier would be to be able to declare a tile as being both timing and shunting point. As of 3.86, to do double-berthing properly requires (I think) two timing points and three shunting points.

Code: Alles auswählen

[TR===R=x=RT======
|||   | |||| 
|||   | |||^ Timing point for signal end berth
|||   | ||^ Shunting point for signal end berth
|||   | |^ One clear tile
|||   | ^ End of longest train allowed in buffer end berth
|||   ^ Shunting point for dividing trains
||^ Shunting point for first half of joining train
|^ Timing point for buffer end berth
^ End of line

[GNock]

Hi Chris,

one answer to your first question:

As regards timing points:

The train goes ahead, reverses at the shunting point and will stop at the rear timing point (see lower part of the graphic).

Is it possible to also do the reverse? Something I would like to be able to do is use two linked timing points (same name, same data) but have the train only stop at one of the two. So, in the related picture, a train from the right would stop at the leftmost TP, turn around and ignore the rightmost TP, even if it was not occupying that track piece. In essence, for the train to "remember" that it has just stopped at that shared TP and not to stop a second time.

Ok, maybe this is the way you want:

Declare in the timing point e.g. "10(R=10x)"
After your train has left the station, you need a data changing point: "10x(R=10)".

This way requires that all trains which are to stop at the timing point are listed in the input field.

[Chris]

This way requires that all trains which are to stop at the timing point are listed in the input field.

... which is precisely the reason I've not used that approach in the past. I suppose that would make this my first firm feature request for the 4.x line.

Now that I've managed to start the program, the second request would be that the prototype tiles in the status window be made bigger, perhaps also with the backing (grey by default) not encroaching all the way up to the edge.

I suspect this may become rather a long list ...

[GNock]

Another way for the input field in the TP:
10(C=s) or 10(L=10x,C=s)
And the command in the data changing point:
10(C=p) or 10x(L=10,C=p)

Then you list only the affected lines in the input fields. I guess this might be easier.

[GNock]

Hello again!

A small correction to my additional information: In 01_Elemente-en.pdf I had entered on driving way 327 the number 323, which has been corrected now.

[Voimala]

I love the possibility to make geographically more correct layouts with Bahn 4.00. The only thing preventing Bahn from becoming defacto standard layout&timetable simulator now is the track building system. In previous versions it was like playing piano, once you mastered the shortcuts you could fairly easily 'play' any track layout. Now as there are even more elements the system is becoming truely tricky and time taking. This kind of system creates unnecessary steep learning curve for beginners and prevents many from building anything more complex. I would love to see some kind of line drag & drop system where user could draw straight or curved line marker and the program would try to match the line as closely as possible just like 'build connection tool' but with some sort of visual aid and possibility for simple curvature.

[Jan Bochmann]

Hello,

As regards timing points:
Is it possible to also do the reverse? Something I would like to be able to do is use two linked timing points (same name, same data) but have the train only stop at one of the two. So, in the related picture, a train from the right would stop at the leftmost TP, turn around and ignore the rightmost TP, even if it was not occupying that track piece. In essence, for the train to "remember" that it has just stopped at that shared TP and not to stop a second time.

That is not possible this simple way. A solution may be to use a route change, as mentioned by Gerd.

I have yet to test this, but can a way piece have more than one function attached to it?

No.

For instance, something that would make my life (insomuch as BAHN contributes to it) much easier would be to be able to declare a tile as being both timing and shunting point.

I don't believe that such combinations would make something easier. It would be complicated to manage, to define and redefine an order, and to display it in any suitable way.

As of 3.86, to do double-berthing properly requires (I think) two timing points and three shunting points.

Code: Alles auswählen

[TR===R=x=RT======
|||   | |||| 
|||   | |||^ Timing point for signal end berth
|||   | ||^ Shunting point for signal end berth
|||   | |^ One clear tile
|||   | ^ End of longest train allowed in buffer end berth
|||   ^ Shunting point for dividing trains
||^ Shunting point for first half of joining train
|^ Timing point for buffer end berth
^ End of line

In 4.00 nearly nothing will change here. Ofcourse, there will be available much more clear tiles because the number of tiles is doubled for a track of same length. And there is no connection between the functions and any graphics, i.e. you can erase the signs of the 3 shunting points if you don't like to see them, or replace them by something in UK design as you like. Same way you can delete the plates of the timing points, or set them to another position, or add 3 new plates anywhere on the platform, all of it without influencing the functions that have been assigned to the track tiles.

With kind regards,
Jan B.

[Chris]

That is not possible this simple way. A solution may be to use a route change, as mentioned by Gerd.

Last time I tried this, it required having to explicitly name every route at each timing point, when this is at least somewhat cumbersome, and for my own purposes stopping position is less to do with the route of a train, but rather its length (which brings me to another thing I'll mention further down). However, for a terminal, I suppose one can impose the minimum turnaround at the RP, flip the direction of the TP and use the actual intended departure time, which works out to be more logical.

In 4.00 nearly nothing will change here. Ofcourse, there will be available much more clear tiles because the number of tiles is doubled for a track of same length.

I suppose that it at least at the "new" standard scale of 128/km the wasted slack space is only around 30m instead of 60m, and shunting movement means the train only "jumps" forward by 8m rather than 16m. I'll have to test that some more to see how it looks.

I notice that signals now have the option of activating at the end of a train. This means that if one religiously uses extra contacts, one can have first-wheel replacement when passing a signal and last-wheel replacement on the system modelling the track circuits. Since a vehicle may be up to 256px in z1, and a "virtual" vehicle may model several real vehicles (e.g. an entire MU set, as has been my usual practice), I believe it would be useful to separate the train/vehicle counting from head/tail activation.

On a related note:
* the stopping point for a reversing train on a through track will depend mostly on its length; and
* depending on where you are, an increased speed limit may apply when the rear of the train passes the sign rather than the front.
So I suggest that tail-activation be enabled for these elements also. A stop set to "tail" would cause the train to stop with its rear at the stopping point, and a speed limit element set to "tail" would cause the train to hold its speed until its rear has passed the element. Sticking the limit before the sign works for a reduction in speed, because you can justify it with the real requirement that a train driver must know where the lower speed limit is before having sight of the sign.

Now, as if I wasn't already whining enough (), the new elements as shown in the status window are too small, and the window background (the stuff that isn't green) coming right up to the edge makes them even more difficult to see. Can we maybe get these slightly bigger?

Since these days monitors tend to be wider, it would be useful to have the option of a vertical status window, since losing that estate across the top of the screen costs more than losing the equivalent down the sides. I'll make a couple of mocks to illustrate how this could look.

Finally, as a bit of a stress test, I have a layout with a background image of 18000x13000, which comes in at about 750MB. Unfortunately, BAHN will not open it if I reduce it with RLE (granted, it still gets expanded in memory anyway), or use grayscale. In the new beta, attempting to change it (with the "Select new image" button or similar - I'm not in front of it right now) for something smaller generates "out of memory". Given my generous set-up, I'm assuming it's hitting the 32-bit address space limit somewhere. Since layouts are now in effect being inflated 4x, this is going to impose more demands on memory, and within a fairly short time* I can see the 2GB ceiling becoming a problem. I suggest that at some point during this run you should explore generating 64-bit builds.

Apologies if all this seems like a lot, but experience suggests that getting stuff like this out of the way early makes it easier to deal with later on.

* In the context of a 20-year old program where a beta cycle may take 2 years, around 3-5 years would be a "fairly short time"

[Jan Bochmann]

Hello,

Now that I've managed to start the program, the second request would be that the prototype tiles in the status window be made bigger...

See Beta1a for that.

Grtx,
Jan B.

[Pablo]

Hello,
When can we expect v.4 with new function from 3.88? We can expect a gift?
Regards

[Jan Bochmann]

Hello

Hello,
When can we expect v.4 with new function from 3.88? We can expect a gift?
Regards

I don't know. Actually I am not able to give any gifts.

Regards,
Jan B.