Arse forward program

That's already mentioned above:

• Multiplicate x-coordinates and yaw of objects and POI with -1

And yes, it's huge arrays. BWR results in arrays of 14662 elements on the longest file. Still gets processed in the blink of an eye, although I already have four loops processing all this. I'm optimistic the data amount is well manageable.

Well Mate, all this looks fantastic and could be a really good idea, but like your ICE train, it seems to be stuck on a red light, hope you can at some point try to utilise them big words you keep using and maybe knock up something we can actually see

I want my shovel back Gray!

When I can see how it works in practice (as I've already privately told Quork) I'll look at adding 'posterior advanced' capability to OTE.


Phil

I've been away from BVE for a couple of weeks, trying to catch up now. This project sounds really promising. If you still need routes, all of mine are Creative Commons, so you have every right to change them as you want.

Thank you!

I shall clear up one point however which I already mentioned in private communication with some of you. This program is not intended to and will never be able to take an existing BVE route, turn it around and have it usable; it is a tool for the developer to make his route bidirectional with minimum effort, but it's no ready-to-use output.

Basically there are two cases:
1. A dev decides to "reverse" an existing route of his. In this case the program will take the route, turn it around, clear it of one-direction commands (signal, beacon, station etc.). The dev still needs to do quite some postprocessing like erecting new signals, sections, station commands, writing a time table etc. Also the program can't know how to change the rails; the dev will need to go into every RailType command and manually select the correct curve rail.
2. A dev writes a new route and plans to have it bi-directional from the beginning on. In this case, he keeps some additional coding rules in mind (like specifying .Sta etc. for both directions via #F and #B, like specifying which track is to be replaced by which via #D tags, keeping to a set of rules concerning the structure of the files in the case of split routes). Postprocessing is minimal here.

I mentioned rules for the structure of split file routes; here they are:
- route in one complete csv file without includes
OR
- 1 "mother" csv file containing all non-Track namespace commands and
- one or several include files containing all and only Track namespace commands

Looking through the existing routes, this should be no change anyway for most devs. If this structure is not kept, the program will miss one or the other information and thus not be able to do the one or other operation. In this case, comment lines are inserted by the program to show the dev, where manual postprocessing is necessary.


EDIT

So far, when inputting the Waterville-Newbridge run 5D, the program of so far 92 code lines outputs

Code:

The block length is 25
The fog beviour is set as 0
The cant behaviour is set as 0
The route has a length of 106850m

The project is en route, obviously.


EDIT 2

Now also object files referenced for signals are read out. Keep in mind there are two possibilities; either a .ANIMATED signal file, which is specified together with the file extension, or a .csv/.b3d/.x signal file, which is specified without file extension. As the program can't possibly know which file type it is, I decided to assume .csv always, so that the route dev will have to manually correct the .freeobject definition in the seldom case it is not a .csv-object file.

May I ask what type of array is being used for this? Array of strings? Objects?

An important facet of PHP is variables usually are not defined as a specific type; it is flexible. Take this as an example:

<?php
$testvar = 8934; //defines the variable and assigns a value
echo stripos ($testvar, "4"); //here the variable is treated as a string
echo $testvar*4 //here the variable is treated as an integer
?>

That's cool for some things, problematic for others...

In this case, first the whole files (the input requires two files; one's the file containing all non-Track namespace commands, the other one's the one with Track namespace commands. If everything is in one file, that file is to be specified in both fields) are read into two big strings. Those are then "exploded" (after some cleanup: Deleting empty expressions etc.) into one array each, with every array having numeric indices and each element being one expression. And those expressions are of ambiguous nature like in the example above. Most of course are strings obviously due to their content; ".SigF" can't be anything else than a string; but those are again split into their arguments, and those are partially text, partially numeric. Also, position lines are obviously of numeric content.

A propos numeric data; a route dev can, obviously, specify it using the $rnd command. If this is done, is_numeric() returns false on those lines. I'm not quite sure how to deal with this.

The program has a little restriction; it supports $rnd(), but only if the number containing it is an integer. Otherwise I can't deal with re-instating the $rnd()-directive. Why?

₍₂₃₂₎ $templow = checkRandom($track[$i], false); //purge possible $rnd() directives temporarily
₍₂₃₃₎ $temphigh = checkRandom($track[$i], true);
₍₂₃₄₎ if (is_numeric($templow)) { //if it's numeric, i.e. a position...
₍₂₃₅₎ x if ($templow-$temphigh == 0) { //if there's no randomness...
₍₂₃₆₎ x x $track[$i] = $routelength - $templow; //the new position is routelength - old position
₍₂₃₇₎ x }
₍₂₃₈₎ x else { //elseway...
₍₂₃₉₎ x x $temphigh = $routelength - $temphigh; //inverse higher bound
₍₂₄₀₎ x x $templow = $routelength - $templow; //inverse lower bound
₍₂₄₁₎ x x $track[$i] = "$rnd(".$temphigh.";".$templow.")"; //put it all together in a new random directive
₍₂₄₂₎ x }
₍₂₄₃₎ }
₍₂₄₄₎ unset ($templow, $temphigh); //memory cleanup

checkRandom("23$rnd(3;9)8", false) returns 2338, checkRandom("23$rnd(3;9)8", true) returns 2398. Now if the route length was 2450, the inversed values would be 52 and 112. I see ATM no other practical possibility than making $rnd(52;112) out of it.

What's affected?
Positioning only. The other manipulated numbers are only re-signed, so the program doesn't care whether the x coordinate of a .freeobj is 34 or 3$rnd(4;9).5$rnd(3;8)4, as long as it isn't affecting the sign. Reversing a route with a freeobj whose x coordinate is $rnd(-3;-1)89 would create -$rnd(-3;-1)89, which OpenBVE resolves to e.g. --289 which I don't suppose to be correctly interpreted as 289...
Position lines, X coordinates, yaw, pitch, roll.

Why don't I consider this a problem?
If I'm not totally wrong, the moment you as a route dev use random positioning, you don't care for submetric precision anyway.



What has been achieved till now?

• #F: and #B: directives are resolved
  
• all necessary data is read out from the files
  
• signals defined in signal namespace are analyzed and corresponding Structure.FreeObj definitions are added
  
• same goes for beacons defined in Structure namespace
  
• if reversing,
  • signals outside #F:/#B: directives are replaced by corresponding freeobjects
    
  • beacons outside #F:/#B: directives are replaced by corresponding freeobjects
• and all this takes place in currently 280 lines of code
  
• and now I'm gonna go to work. 3rd night shift in a row (and the hardest one...)

Turning freeobjects around works as well now. Cracked the 300 code lines threshold.

EDIT: Mind the edit in the above post under "What's affected?"

Work's being very absorbing currently, but progress continues still, slower though. Replacing signals and beacons by freeobjects is finished, the code got cleaned up a bit in a few places, so yeah, we're getting to it.

Or to put it in numbers for number lovers, based on the chapters of OpenBVE's documentation (though it's not really meaningful in my eyes - Track.Freeobject, Track.SigF etc. e.g. are obviously more work intensive to process than Track.Section)

Track.
11.1 (Rails) - 0% of commands
11.2 (Geometry) - 0% of commands
11.3 (Objects) - 12.5% o.c.
11.4 (Stations) - 0% o.c.
11.5 (Signalling and speed limits) - 80% o.c.
11.6 (Safety systems) - 100% o.c.
11.7 (Miscellaneous) - 0% o.c.

On a side note - once more I found I'm most productive at coding at night after a long day... I'm curious why. Maybe it's easier to get into this specific work trance mood when one is tired?

Two and a half man, erm, moons passed. Progress hasn't been done in this time, I must say exams and exam preparation took up more of my time than I expected, and while they went well, I still have two to go (internal DB exams, see my sig) and while I'm not finished yet, I got very little done in any of my free time projects. Even the Welsh station building bricks I promised haven't been done, which really isn't so big a thing compared. I must also admit putting railway stuff low on my priority list; with work preparation being so big a thing in this time, I didn't want to spend all my sparse free time with railways as well. I hope you can understand that But have no fear, I'm far from being oversaturated or bored with railway, and nothing is forgotten.