BRR Randomizer version 10.2

Seems to have gone a bit quiet on the Forum, maybe we've started on the Turkey and Mince Pies too soon, so I thought I'd open up this topic for discussion. Over the past week I've been experimenting with the latest (2003) version of the Randomizer on the routes that I have and have come up with the following observations:

1. It works fine on the following: ECML, Tyne Valley, Birmingham X-City, ELR and all LUL routes I use (except Hammersmith - City Line).
2. It will not work on the following: NWM, Midland Suburban, Edinburgh-Aberdeen and the BWR.

I only use it to "randomize" the signals, which it does very effectively and realistically, depending on the setting. I don't use it to change tracks as you often end up on the wrong road, which is plain daft.

Clearly the Randomizer is not compatible with OpenBve (in 2003 OpenBve hadn't been conceived, I guess) and I was wondering if anybody with more technical know-how than me (which isn't a lot) would be prepared to look at the Randomizer and see if it can be brought up to date and made workable for Open Bve, as I believe it to be an excellent tool, if installed correctly.

Any thoughts?

John

When you say

johnsinden wrote:Over the past week I've been experimenting with the latest (2003) version of the Randomizer on the routes that I have

I assume you mean running the output file on OpenBVE not BVE4?

I'd not expect it to work on BWR and NWM as they're both built in blocks aren't they? BRR would, I expect, only work where the entire route is one contiguous file.

Yep.

Sorry Hovis, I should have given a fuller answer - yes, I just use OpenBve as I find that BVE4 routes run just as well on this. Thanks for the reply and explanation.

Hovis is spot on when he mentions the single routefile. Randomiser won't work with Ballyfeckin either. Randomiser is really past its sell by date now as so many developments have occurred since 2003.

@graymac, you're right Graham, it is out of date, hence my post above:
Clearly the Randomizer is not compatible with OpenBve (in 2003 OpenBve hadn't been conceived, I guess) and I was wondering if anybody with more technical know-how than me (which isn't a lot) would be prepared to look at the Randomizer and see if it can be brought up to date and made workable for Open Bve, as I believe it to be an excellent tool, if installed correctly.


Cheers,

John

Ideally some of the former functionality of the randomiser program would be provided in the main BVE program, though that isn't going to happen any time soon. It is really up to the route developers to supply some routes with varied timetables and stops. I have done so with the Ballyfeckin routes, including one total sonofabitch with TSRs and engineering occupation enough to make a driver curse most convincingly.

You can achieve a very realistic effect by editing the 'pretrain' instruction in the file for each schedule. I've only tried this on Network West Midlands and it works very well. I can't see why it wouldn't work on other routes.

It gives random signal checks on each journey, and the checks are realistic - sometimes creating the impression of running behind another train (persistent cautionary aspects) and sometimes a straight double yellow, single yellow, red.

The only minor downside is it takes a bit of time - usually about 5-10 minutes for each file you edit. I have a few of my favourite schedules for NWM edited and saved, and do most of my driving on those schedules.

Basically, the existing files have something like:

.Pretrain 17.35$Rnd(11;18)

...every few miles. That means the imaginary 'pretrain' passes that point at somewhere between 17:35:11 and 17:35:18. The problem is that the random element is so small (7 seconds in this case, which is fairly typical) that it isn't really noticeable in running, and you soon get to know all the signal checks on your favourite schedules.

Change the Pretrain instruction to something like:

.Pretrain 17.34$Rnd(01;179)

That means the Pretrain will pass that point at some time between 17:34:01 and 17:36:59.

It seems you mustn't allow one pre-train instruction to overlap the next, so if the latest possible time a pretrain can be at one point is 17:36:59, then the earliest possible time it can be at the next point mustn't be before 17:37:00. So following the above instruction, the next one might be:

.Pretrain 17.37$Rnd(01;179)

and the next one:

.Pretrain 17.40$Rnd(01;179)

etc

You need to try to set the pretrain instructions so that if the pretrain runs as late as it can, you'll get heavy signal checks, and if it runs as early as it can, you'll get green signals.

If you set it up correctly, you'll end up with a very realistic effect throughout the route.

johnsinden wrote:Seems to have gone a bit quiet on the Forum, maybe we've started on the Turkey and Mince Pies too soon, so I thought I'd open up this topic for discussion. Over the past week I've been experimenting with the latest (2003) version of the Randomizer on the routes that I have and have come up with the following observations:

1. It works fine on the following: ECML, Tyne Valley, Birmingham X-City, ELR and all LUL routes I use (except Hammersmith - City Line).
2. It will not work on the following: NWM, Midland Suburban, Edinburgh-Aberdeen and the BWR.

I only use it to "randomize" the signals, which it does very effectively and realistically, depending on the setting. I don't use it to change tracks as you often end up on the wrong road, which is plain daft.

Clearly the Randomizer is not compatible with OpenBve (in 2003 OpenBve hadn't been conceived, I guess) and I was wondering if anybody with more technical know-how than me (which isn't a lot) would be prepared to look at the Randomizer and see if it can be brought up to date and made workable for Open Bve, as I believe it to be an excellent tool, if installed correctly.

Any thoughts?

John

Birmingham X-City South does sort of work. The thing is you always get a passed red signal message when leaving the first station, even though there is no signal within miles of the station. And nothing else works, not even NWM. I once asked if BRR could be made compatible with openBVE but people said it's not possible. I recently just realized (after reading this topic) that the only thing you could do was build a brand new bve route randomizer from scratch and make it compatible with openBVE. But we'll need someone really smart to do it. Any takers out there?

You can put it on your "wish list" but I honestly can't see much chance of it happening. James has the right approach described above, it is something which route develops may take on board in future, Though there's few enough of them too at present. Even though the documentation has been around for ages there are far too few people attempting to produce material for this sim. If consumption exceeds production there can be only one outcome.

@Buckysam - read what James (above) has written regarding the .Pretrain feature. It works..!
and on the subject of .Pretrain, what is the difference (if any) between $Rnd and $rnd (capital R - small r). Any ideas anyone?

Cheers,

Johjn

what is the difference (if any) between $Rnd and $rnd (capital R - small r).

None, as far as I know, although the recommended syntax is the capital R.
I do not know, but possibly it may make a difference on Linux systems?? Linux is usually case-sensitive.

James wrote:You can achieve a very realistic effect by editing the 'pretrain' instruction in the file for each schedule. I've only tried this on Network West Midlands and it works very well. I can't see why it wouldn't work on other routes.

It gives random signal checks on each journey, and the checks are realistic - sometimes creating the impression of running behind another train (persistent cautionary aspects) and sometimes a straight double yellow, single yellow, red.

The only minor downside is it takes a bit of time - usually about 5-10 minutes for each file you edit. I have a few of my favourite schedules for NWM edited and saved, and do most of my driving on those schedules.

Basically, the existing files have something like:

.Pretrain 17.35$Rnd(11;18)

...every few miles. That means the imaginary 'pretrain' passes that point at somewhere between 17:35:11 and 17:35:18. The problem is that the random element is so small (7 seconds in this case, which is fairly typical) that it isn't really noticeable in running, and you soon get to know all the signal checks on your favourite schedules.

Change the Pretrain instruction to something like:

.Pretrain 17.34$Rnd(01;179)

That means the Pretrain will pass that point at some time between 17:34:01 and 17:36:59.

It seems you mustn't allow one pre-train instruction to overlap the next, so if the latest possible time a pretrain can be at one point is 17:36:59, then the earliest possible time it can be at the next point mustn't be before 17:37:00. So following the above instruction, the next one might be:

.Pretrain 17.37$Rnd(01;179)

and the next one:

.Pretrain 17.40$Rnd(01;179)

etc

You need to try to set the pretrain instructions so that if the pretrain runs as late as it can, you'll get heavy signal checks, and if it runs as early as it can, you'll get green signals.

If you set it up correctly, you'll end up with a very realistic effect throughout the route.

@ johnsinden

Ok. I'll give this a shot. But this is basically what BRR does, right? All it does is it just loads the route like this every time, but different.