Arse forward program

Hi everyone!

As I noted some time ago already, I have some ideas for a system to make routes bidrectional with changeable tracks without notably increased development work. My ideas for bidirectionality (not multi-track though) are thought far enough to make a test implementation. For this aim I'd be very happy if a route dev would allow me to modificate their route accordingly. It should be not too long and also have not many lines, ideal would be something like good ol' "PZVIL" (Hungary). I can't be sure whether it will work (working in railway reality, you really soon learn the difference between "theoretically good" and "practicable" or even "working" at all) so it would be useless to start off with some 10.000+ lines-routefile.

Oohhh... NWM is mostly free of copyrights, but routefiles are fairly long... Maybe graymac could allow you to use BWR, for sciencefor OpenBVE's future

Well put it this way you would need good programming skills, and I believe BVE 5 has this kind of similar thing just it's not Multi track.

Dear Northern Line, what I intend isn't a change to OpenBVE but a program, which outputs a normal, documentation-conform route file according to user parameters (now only direction, later also track changes) from a minimally extended route file as written by the route author. The inteded programming language is PHP, which is a language specifically for text processing; and that's just what OpenBVE route edition is. My skills in PHP are fairly extensive and, I trust, good enough for implementing what I have in thought.

You mean you got a program to write the thing arse-backwards???

You will not find it easy feeding it BWR-2012 (or NWM for that matter) because the files are split into separate bits and reassembled by use of "$include" in the .csv routefile. If you have the early Ballyfeckin works they are mostly in a single file. And the IWR as well, though its single track apart from passing loops. The IWR doesn't have objects built to backward viewing standards anyway.

Well, that's exactly what I hope it is, Gray

So the IWR would be good, if it weren't for the objects... Huh well, one could still use it as a test object, we still have backface culling in OpenBVE. For all poorness it will be to have the objects look the mostly same way, it will be enough for both test and demonstration. May I use the IWR?

It wouldn't do any harm to try it. At least you will get some indication if it might work.
Other than that, do you still have the earlier BWR (pre - 2012) objects? If so I might be able to find a older routefile (I should have one on a CD, though not on the hard disk as the PC was replaced) which I could send you to experiment with.

No, I usually don't keep old versions of routes. Did it back in my LokSim3D-times and found I never used the older ones...

BWR has all-around objects...? If yes, a preferably short route file would be great indeed! Thank you!

Check your email

Ah I understand where this is getting, you can sign me up for one of your beta testers (don't forget graymac) once it begins to take shape. Just the one goal is to make it easy and simple to use, besides who wouldn't want to drive from Waterville to Newbridge and back again?

I was driving the class 142 from Ballyfeckin to the docks just yesterday. I made up a pretend scenario that I was transporting some Gray's BWR Irish Cream to the docks to be carried on the ferry to France. I got there in good time and the French really enjoyed the Irish cream and regards to graymac.

Anyway back to topic, I wish you the best of luck with this program and hope to see some good results!

Regards

Shaq

Thank you, Gray, for your route file! I found it still is thousands of lines long, so it'll be quicker to first create a short test route before I try adapting an existing route. I'll report back soon.

Good luck! Sorry, I don't really do short routes

So, I'm working on the 'dummy' route for what I temporarily call, inspired by Graymac, the "Arse-Forward-Program". I'll post what I have till now, without comments though at first; maybe you'll already get an idea. But don't worry, I'll documentate *g*

However, I found there seems to be no standard for flange sounds; could some train devs state please, whether they have some 'internal' standards? Possibly a parallel to BVETSS?

###HEADER
Season{Spring}
Latitude{48}
###FILE

With Options
.BlockLength 20
.ObjectVisibility 1
.CantBehavior 0
.FogBehavior 1

With Route
.Comment This is a test route for the 'arse-forward-program'
.Timetable Test
.Change 1
.Gauge 1435
.Signal(0).Set 0
.Signal(3).Set 40
.AmbientLight RedAmb{1}; GreenAmb{1}; BlueAmb{1}
.DirectionalLight RedDir{1}; GreenDir{1}; BlueDir{1}
.LightDirection Theta{}; Phi{30|0}

With Train
.Run(0).Set 0
.Run(1).Set 1
.Run(2).Set 2
.Run(3).Set 3
.Run(4).Set 4
.Run(5).Set 5
.Run(6).Set 6
.Run(7).Set 7

EDIT: Oh well, I could as well explain what the commands do.

The six commands in the light colour sections will be replaced by the program according to the daytime (specified by the program's user) and the season (specified by the route author in the header section). The header section is not included in the output file, of course. The commands have one argument; that's a correction factor. That can be used if you e.g. have a jungle route, where you'd like a greenish light due to vegetation.

Theta{} has no argument and is replaced by the program according to season, latitude and daytime. Phi{arg1|arg2} is influenced by those factors as well, but it also has two arguments; the first specifies where north is in degrees in the mathematical positive sense (counter-clockwise) (so 90 if the route goes straight east), the second one specifies the angle between start point and end point of the route, also in degrees and mathematically positive. The latter one is necessary when the route is being driven backwards.

There will be not many more commands necessary; in the Track namespace, you'll have Forward{BVE commands only for forward direction, e.g. .Sta} and Backward{BVE commands only valid for backward direction}. Then there will be the bool Dir{}, which is positive when going forward and negative when going backward. That should be it, I think.

I shall add the question: Is this something seeming sensible to you developers? My aim is to make it as small a change for you as possible, but only you can tell me, whether what I wrote till now seems like something you'd be likely to use or whether it seems too much trouble; and if it does, what would you prefer?

I use Derryck's route shifter from time to time and find it useful. A route reversing (mirroring, whatever) tool ought to be useful too. It's going to depend on two things, I suppose. Which will be 1) Does it work? and 2) Is it uncomplicated to use? If the answer to those is "yes", you're in business and will maybe get a nomination for a bve oscar, I guess!!

Well, the question is, whether you consider what I sketched till now as uncomplicated or not? I hope it is, but I don't have any experience. What might seem a small change to me, might be too big a thing for a dev used to certain paths and patterns for years.

I've been making stuff for a couple of years now. I have successfully used Derryck's 'Route Shifter' and also Guillyman's excellent 'Platform Generator' at least before BWR-2012 was made and I got a PC with Win7 64bit. And, of course, the 'Switch' program, long time around but still greatly useful.
Initially I tried the Routebuilder program and got nowhere fast with it. Couldn't use or get it to work at all. So I learned hand coding.
I can safely say (probably) that route builders will all have their preferred methods of working. Up until now there's been no straightforward way to flip a route backwards. And rewriting it line by line isn't going to appeal to anyone as far as I can see.
So, will this situation change? . . . . . . . . .
At least you're trying something, good luck.

I'm getting curious... It isn't forbidden anywhere in the documentation, but I start to wonder; does OpenBVE allow for negative track positions...?

Negative track positions are not allowed in openBVE and the documentation does explicitly prohibit them see quote from the documents

● Track positions and lengths
Position
A non-negative strict floating-point number corresponding to a track position. All subsequent commands from the Track namespace are associated to this track position.

Ah, there it is... thanks!

LabRatAndy wrote:Negative track positions are not allowed in openBVE and the documentation does explicitly prohibit them see quote from the documents

Which alone stands as a reason for me and Anthony including a "negative check" into the Route Shifter tool.

Oh darn, sometimes it's like having tomatoes on the eyes... Forget anything I wrote here.

Let's forget the multi-track system for now. I'll concentrate on the arse-forward problem, which needs no strange commands and calculations, only #F: and #B: (for lines valid only in forward/only in backward mode, like Track.Sta, Track.Limit etc.). I had started my ideas with the multi-track problem, hence the need for additional commands, and thus I stayed in this mode and made things unnecessarily complicated. Abandoning the multi-track problem for now, the goal is reduced to a linear one.

For those with a programistic mind, here's the plan for going forward:

• Load the source file
  
• Convert it into an array, each array element containing one line
  
• Delete all lines starting with #B:
  
• Strip the first three chars from every line starting with #F:
  
• Merge the array into a string
  
• Make that a CSV file
  

And that's the plan for going arse-forward:

• Load the source file
  
• Convert it into an array $Lines[], each array element containing one line
  
• Delete all lines starting with #F:
  
• Strip the first three chars from every line starting with #B:, save the line's array element indices into an array $BLines[]
  
• Analyse every line:
  • What command is this?
    
  • What track kilometre is it on?
• Get block length => $BlockLength
  
• Get the highest kilometration => $RouteLength
  
• Get fog behaviour
  
• Get cant behaviour
  
• Get objects specified for signals, relays, beacons, transponders etc. and list them in $ActiveObjects
  
• Check if there are signals, relays, beacons, transponders etc. in the Track namespace in lines which are not listed in $BLines[]. If yes, define new freeobject commands in the Structure namespace for the objects specified in $ActiveObjects
  
• Change positioning for all lines (new position = $RouteLength - old position for pinpoint-position commands like Track.Turn and new position = $RouteLength + $BlockLength - old position for block-position commands like Track.Freeobject)
  
• Replace all signal, relay, beacon, transponder etc. lines, which are not listed in $BLines[] with a freeobject command
  
• Delete all signal logic lines (Section etc.) and stuff like markers not listed in $BLines[]
  
• Multiplicate curve/slope/... arguments (except cant, if in unsigned mode) with -1
  
• Multiplicate x-coordinates and yaw of objects and POI with -1
  
• Multiplicate Wall, Dike etc. directions with -1
  
• Switch Wall/Dike/Rail/RailStart/... with the next WallEnd/DikeEnd/RailEnd/... of the same index
  
• Replace RailStart by Rail
  
• Move all curve/slope/speed... commands and, if fog is in non-interpolated mode, fog commands to the position of the next one. At the position of the first one, insert a curve/slope/speed...(/fog) command with all parameters being 0. Move the last curve/slope/speed...(/fog) command to $RouteLength
  
• Move all ground commands to the position of the next one. Move the last one to $RouteLength
  
• Calculate the effective rotation between route start and route end, correct directional light by the value
  

So, that's roughly what I want to do. Nothing special to be quite honest, just something that should get done.

What does it mean for legacy routes like the IWR?
This is done:
The route geometry, the objects, the landscape, the physical and optical properties are correctly turned around.
What you have to do:
The program can't possibly know where to put signals, sections, stations etc. You need to add those manually. Assuming you had signals posted for the backwards direction as freeobjects, you'll need to find and delete those.

What does it mean for creating new routes?
You can keep to most of your coding habits. Just observe the following:
Instead of writing

Code:

Track.Signal 3;;-4;0;0;0;0

write

Code:

#F:Track.Signal 3;;-4;0;0;0;0
#B:Track.FreeObj 0;93;-4;0;0;0;0

(The same with stations, speed limits etc. etc., of course)
And remember to specify signals, stations etc. for the backwards direction. You don't have to calculate their new position, the program does that; you stay in the forward perspective. This means, of course, you need to keep in mind that the objects attached are seen from the behind in your perspective, so e.g. write:

Code:

#F:Track.FreeObj 0;93;4;0;180;0;0
#B:Track.Signal 3;;4;0;180;0;0

I hope I wrote understandably. If someone detects any logical errors in the points listed above, please tell me.

Also, a question to the route devs: What's the order, in which yaw, pitch and roll are executed? I assumed yaw (around the vertical axis) is executed as the last one. Otherwise, it would be tricky to get objects turned around...

While programming, I stumbled upon yet another topic not mentioned till now; it seems, formally Track-namespace commands could be anywhere. However, as far as I have seen, all authors, both historic and contemporary, keep to the well-legible, clear structure of having all commands of one namespace in one block, whether using With.* or not. Keeping to this makes also this programming somewhat easier; thus, what do you route-devs say: Can I require, that all Track-namespace commands are at the file's end and not mixed with other namespace commands, as in this 'sketch'?

Options.BlaBla
Options.BlaBlubb

Route.YaddaYadda
Route.ChitChat

Train.Alpha
Train.Beta

...

Track.FreeObj...
Track.RailStart...
...

(or with With.*, of course)


EDIT
Also please help with the questions from the post before!

Working with Gray's BWR for tests, I realized another aspect; when using split files, not all necessary data is in the submitted file, obviously, so it must be provided elseway. It's blocklength, fog and cant behaviour, object files specified for signals/beacons/... and the structure namespace. I'm not quite sure how to handle this.

Also, on a sidenote; most authors (luckily) use curved rails for curves to avoid that old BVE polygon trackwork. While this obviously is great, it's a problem when it comes to turning the whole thing; the rails in the curves are bent the wrong way then. My first thought was to rotate the rails by 180deg, but the syntax of the structure namespace doesn't allow for this. The second thought would be to replace all tracks by null tracks and place the rail objects via the dike or wall commands... I dunno. Another problem yet to be dealed with.

Erm, you will need a HUGE array to contain long routes.
- You also need to adjust x-position of freeobjects -> turning backwards mean (-x) becomes (x) and vice-versa