Operations in OR

Hello all! I would like to offer some ideas for discussion, and perhaps we might arrive at a consensus, which would help the OR Team.
No Sim allows full scope for operating the route, or rolling stock that has taken months or years to create. OR offers our only hope.
I`m not connected to the OR team, nor am I a programmer. We must also remember that initially the existing MSTS AE will create activities for OR. Here`s my first item:
1) Variable Timing
MSTS acts. work to rigid train times because the dispatcher isn` robust enough to cope with the unexpected. Acts are predictable and boring. The OR team have promised signalling based on local track circuits. If train start timings were variable then the signalling would really be vital. You can belt along at speed in MSTS knowing that sigs will be green : a different experience if the next could be a red.
So the start time of all trains given in RE would vary, amd the variation could be different too! So 12.00 start could be +/- 1min or 5 min and so on. which brings me to:-
2) Train priority
Your express is late and due to cross a branch train. How the sim handles this should depends on the priority assigned to the trains.
Lets pretend that an express has a priorty of 5 and the branch 3. Normally 5 beats 3 and the express gets the road. But a late express gets a priority penalty, and might well be held at signals. In days when connections for passengers were considered important expresses were held . A goods train with low proirity would frequently be "looped", and OR needs to use the "Begin passing path" feature that seems to be redundant in MSTS RE. This would shunt the low priority train out of the way.
The other sim does feature train priority, but for some reason it doesn`t seem to work correctly.
I think these 2 features (Variable start times, and train priority) could easily be fitted into OR interpretation of the MSTS activity, and would make activities far more interesting.
Rick

Hi Rick

Some good ideas there

Geoffrey (gswindale) is trying to incorporate random request stops into acts, not easy seeing how MSTS acts work, and you would have to work in some triggers to make it work in MSTS, so the ability to be able to easily generate random request stops in OR would also add interest and variation to activities.

Thanks for the reply Mark. Geoff`s work on request stops is interesting, but as you say, hard to coerce MSTS into complying. But many goods services were request or "as required" in the trad. railway. Leads me to item 3.
3) Variable consists. The fixed goods consist is either a MSTS fiction, or only a recent feature, as "block trains". For most railway history goods trains varied with daily traffic fluctuations, and train consists were altered en route. So we need varying intial train consists, and varying "spawning" of wagons at wayside stations and industries. Obviously an industry should only spawn appropriate wagons. So a colliery would spawn coal wagons, and demand empties. As well as generating traffic, goods must be delivered to a place demanding them. So a pick up goods can amble along dropping off empties or loaded goods, and collecting wagons too.
If OR could read the MSTS siding marker name, "Colliery" would indicate a wagon spawn location, and say, "Coal" a siding demanding it. Adding a line "wagon type COAL" to the .wag file would enable the spawner to generate the correct wagon . Factor in a probability or random mulltiplier, and you have your fluctuating traffic flow. I`m no programmer, but I hope this might be achievable using the existing MSTS AE, but running OR.

4) Evaluation
Having delivered appropriate loads, and picked up originating traffic, not forgeting the empties, it would be good to get an evaluation.
Something like ton/miles hauled against fuel used. With time keeping and safety too. I know train simmers sometimes frown on "arcade game" type scores, but I think it would add satisfaction.
Rick

Without wishing to denigrate this thread don't you think that you're getting a bit ahead of the OR possibilities here?

I would be happy to see OR run all current MSTS acts as they run in MSTS, or at least something close.

I don't really have a machine capable of doing OR justice and when it (my PC!!) falls over I hope I will be able to get one.

At the moment I get terrible pauses and stuttering with it, but I haven't tried the "test" version.

I quote from the OR mission statement/objective:-
"One major technical objective is to achieve backward compatibility with existing MSTS content, embracing and extending the life of over a decade of community and third party developed content.
Despite this backward compatibility, we will not be bound by the limitations of those file formats. We will extend those formats and create new file formats as needed to support the advanced capabilities of current computers and graphics technology."
It can be seen that in the short term OR and MSTS are likely to be compatible, and I believe that it is in that area that this forum should direct its comments, bearing in mind our own aim of maximising the use of MSTS.
In the long term I always personally believed that OR and MSTS would diverge as OR looks to take advantage of new technology, and its likely that much of the existing MSTS content may not be acceptable to OR. Of course I may be wrong but the end part of the above suggests otherwise.
I would therefore ask that we should perhaps use this area of the forum to see how OR can extend the life of MSTS.
For myself I don't expect to use OR because I will not be in a position to buy the hardware that is likely to be required to maximise the benefits of OR, although of course I wish the OR development team and those who are actively interested the best of luck in their endeavours.
Alec

In my experience with a 10 year old P4, OR is much less demanding on hardware than MSTS.
If the members of this Forum are happy with MSTS activities, then fine. OR is unlikely to achieve full compatibilty with MSTS acts.
Personally I find MSTS activities (and on the other Sim) excruciatingly limiting. By the time you have dropped off your brake van for a spot of shunting, and picked it up again, MSTS has gone "POOF!" in a flurry of reverse points. Realistic activities are impossible.
I don`t think my suggestions are "getting ahead" as I`m being careful to propose improvements that use much of the existing MSTS framework, in both RE, AE and the .wag.
In my opinion OR is the future of MSTS, and not merely a means of prolonging the existing content of MSTS.
Many routebuilders and rolling stock modelers are developing advanced fresh content, expecting to take advantage of OR.
But I asked for views, got some answers, and shouldn`t complain. I see there is an exciting new experimental release of OR so off to try it now!
Rick

Rick
I suspect that my understanding of OR is severely limited, and hence I feel that my comments may have seemed too negative.
Please accept my apologies for any unintended offence, and be assured that I would welcome anything that enhances MSTS.
Alec

I believe that they already have introduced a non-msts feature where an AI loco will uncouple, but I can't off hand remember how it worked. I think it involves a dummy waiting time.

To be honest I don't think they could really advance activity possibilites without a new Activity Editor. I would like to think that they will cast in stone a final MSTS "mostly compatible" version before doing that.

I think my problems with OR are down to lack of memory.

Digressing, I reported a problem with OR quite some time ago in that a flipped steam tank loco has the controls reversed. I was told that there was nothing wrong despite the fact that the same thing didn't happen with a diesel shunter or one with a recognisable back and front.

Alec, I wasn`t offended, but I did let my disappointment show that others aren`t excited by Open Rails, and I`m sorry for this.
Mendes, usually the OR team are very helpful about investigating reported problems. OR makes more efficient use of resources than MSTS, so I`m surprised it doesn`t run well for you. If you post your computer specs, I`m sure someone will suggest a solution.
Just released is an experimental version of OR, giving major advances in signalling. There are 2 modes of operating.
Auto , with the path and switches set for you. This looks to be similar to MSTS, and will likely be compatible with existing MSTS acts.
At any time a player can op out of Auto, into manual, and in manual the switches can be altered. This will allow unscripted shunting "off path" and avoid the tangle of reverse points found in MSTS. The player can later resume the path in Auto mode.
In addition there has been some careful work to avoid deadlock meets on single lines.
The "passing Path" option has been fully implemented : very good news! Train priority has been shelved, and it would be interesting to know why.
So OR has made big strides towards more flexible Operations. I urge everybody to try the experimental release. Please don`t be put off by "experimental", version x1423 is working very well for me. Look for the small print on the OR downloads page
http://www.openrails.org/experimental.htm
Rick

Rick
Thanks for the update, which I imagine will be of interest.
It may well be that when I drive more trains in the future, I will find OR of benefit. At this time in my MSTS development I continue with my FG DMU obsession!
Alec

A couple if things I'd like to see in OR.

A Recorder.
You make a number of shunting moves and they are recorded.
Then they are played back as AI in an activity.

Freight animations that animate.
A better name would be secondary shapes.

You could have couplings that swing up or down triggered by the coupling sound trigger.
and brake levers that move when you apply them.

On the initial points; as long as we have to use the MSTS Activity Editor; activities for OR will pretty much be bound by what MSTS is capable of.

It is possible to pseudo-randomise some actions for the player service; however what I believe is needed is for events to be able to be tied into the AI services so that if, for instance you are running a little bit behind schedule at a specific point that an event is activated for the AI service to either hold it somewhere or kick it into life.

I have high hopes for OR when it reaches maturity; however before we launch into a "wishlist" of what we'd like it to do; I'd like it to do what MSTS does at present and then consider how to enhance the editors to provide additional features.

rickloader wrote:Mendes, usually the OR team are very helpful about investigating reported problems. OR makes more efficient use of resources than MSTS, so I`m surprised it doesn`t run well for you. If you post your computer specs, I`m sure someone will suggest a solution.
Just released is an experimental version of OR, giving major advances in signalling.

I will try the experimental one when I get a moment. MSTS must be one of the worst written programs ever, or maybe all game programs are like this!

I think the killer point with my machine is that I only have 1GB of memory, I've been meaning to get some more for years, but as it is now over 5 years old I'll wait for something to go seriously wrong and scrap it.

The problem with "flipped" steam locos was quite some time ago and for all I know may have been fixed. I reported the error and was sent a reply saying that there wasn't a fault. I replied with the diesel shunter comparison which to me proved it was wrong and didn't receive any response.

mendes wrote:
I think the killer point with my machine is that I only have 1GB of memory, I've been meaning to get some more for years, but as it is now over 5 years old I'll wait for something to go seriously wrong and scrap it.

I would think that is almost certainly the problem.
My old machine was an XP based, 5 year old machine. 2GB of ram, a Nvidea GTX6600 graphics card, and a not very powerful processor. OR would start but was impossible to run with frame rates in single figures.

I decided to replace it with a laptop promoted as a 'gaming' quality machine which now runs OR whether i choose to use the integrated graphics or the Nvidea card built into the machine. Now the problem: the machine will run MSTS and OR equally well re frame rates. OR slightly wins the battle on the graphics side, but the difference isn't spectacular.
I'm actually quite impressed with MSTS.

I think it was Rick that said that OR wasn't particularly demanding to run, but my laptop, or rather my left thigh, tells me different with an enormous amount of heat generated in quite a short time compared to being able to run a 2 hour activity in MSTS with only slight warming. I have a cooling tray now that, hopefully, will control the heat generation when i choose to run OR .

The developers have worked hard to develop OR to this point, but I agree with Geoffrey that when (if) OR can do what MSTS does now, it may be viable as an alternative and can have things added to improve the basic simulator. Until then, I will continue to build things for MSTS with any compatability with OR: luck rather than design.
Cheers
Clive

Here are the results of 2 test activities with player train crossing approaching AI on single track with passing loops midway.
Test 1) New Forest route. Lymington Branch
MSTS Player train ran through crossing loop then held at red on single line. AI train did not start as held at red. Standoff. Result FAIL
OPEN RAILS Player train held correctly at crossing loop red, until AI train arrived, then signal cleared. Result PASS
Test2) S&D Route Blandford - Sturminster, crossing at Shillingstone loop
MSTS Player train given green right through. AI held at red. could not start. no crossing Result FAIL
OPEN RAILS Player admitted to Shillingstone, where AI was already waiting at sig. Both trains crossed in loop as planned Result PASS
Conclusion. Open Rails correctly handles opposing traffic (meets) on single track. MSTS does not.
It looks as if the OR team don`t need my suggestions! But I do like Ian`s ideas.
Regarding performance, on a 2003 Dell 8400 P4 1GB ram with AGP nvidia (7800??) MSTS 10-15 FPS same activity in OR15-18 FPS.
Maybe there is some other limiting factor in a laptop?
Rick

I must admit I find Rick's experiments with OR totally fascinating. To me the only route that handled single line working properly is the Cam 2 and the reason for that is that the main part of the route was signalled to force MSTS into making it work rather than any sort of realism.

I really must download the experimental version and see what happens on the Bala Hub!

I'm still struggling to get my WIP route NWEv3 to 'perform' in OR

It's pretty demanding in terms of route size, and if there is an OR guru out there who is willing to take a look to try and fathom out what the issues are, I'd be more than happy to provide a copy of the route 'as is'.
(What happens in activities regarding AI in msts, doesn't happen in OR on my system... XP pro, 2.4Ghz quad processer, 3.25 Ghz free RAM)
Please drop me a PM.
Cheers,
T

A couple of points from someone on the OR team:

WRT compatibility... the intent is to reach a point of compatibility where trains move and sound as they do in MSTS -- or better...up to a reasonable degree of compatibility. That activities work the same... up to a reasonable degree of compatibility.

And so the issue is what is a reasonable degree of compatibility? To answer I have to digress briefly: we do not have access to the MSTS source code and so there are large areas of functionality where all we can do is guess about what MSTS was actually doing. Sometimes our guess is pretty good... other times it's not. Second, there is no sense in repeating what is understood to be done poorly relative to what hardware & software can do today. Obvious examples are the appearance of water and sky, shadows, etc. More subtle is rolling resistance... KUJU tried to do something a bit like the Davis Formula... OR simply coded in the Davis Formula. Same for using multiple threads... modern PC's usually have multiple cores. Last example is with Signalling. MSTS did many things well, others poorly. We took a look at the problems and concluded we'd be better off scrapping our early attempts at mimicking MSTS and starting over. Our last official release was (I think) 0.8.V1251; Current is something like 0.8.V1505. The difference is largely that the Signalling code has been replaced. If you are still running 0.8.V1251, may I suggest you try the latest "beta".

So to return to the question... the most "correct" answer I can provide is that to date we didn't intend on breaking any MSTS functionality but we knew we would rely on modern hardware and software and that in some situations we could (1) do something better w/o causing problems to MSTS content and/or (2) do as well as we could figure out what MSTS was doing and hope people would understand and accept why it was different.

Perfect compatibility isn't possible, nor would it be desirable.

When we get to 1.0Vnnnn we'll have reached the end of trying to match how MSTS does things and we'll turn our attention to trying to provide new functionality. One of those areas we want to turn to rather quickly will be in activities (we've developed a list of new events that activity writers can use, right along with the old ones) and that will likely mean the old AE software won't be useful. That fact will mean there's a need for a new Activity Editor... it might also mean the need for a new set of Activity files. It does not mean we'll rip out the old stuff (tho bug fixes for the old ways may decline in numbers). So it will be at this point that OR begins to diverge from MSTS. AFAIK the objective is not to rip out any code that older MSTS content would use... but do feature changes will be additive to total functionality, not replacement that breaks MSTS content. Hopefully we'll be able to stick to that plan.

V2... off in the sky somewhere out by the horizon, will likely see a replacement to .s file. I cannot recall now whether the replacement route editor is expect in the 1.0 family or in 2.0. Same forgetfulness (sad to say) WRT .XNA and .NET software that OR uses to interact w/ the hardware (both obsoleted by Metro/Win . They'll have to be replaced eventually and that may or may not have significance for the hardware people use.

Hope that clears up a few of questions posted earlier.

Many thanks for that most useful update of what is happening and is likely to happen with OR. I very much hope that you can continue to provide us with updates in particular the compatibility between MSTS and OR.
As I've said before I welcome with open arms anything that extends the life of MSTS.
However I would be interested to hear how OR works under the Windows 8 operating system, bearing in mind the reported difficulties that some are encountering with MSTS and W8?
Alec

Hi Genma,

Welcome to the forum, we are glad to have you on board.

I do have 2 questions with regards to OpenRails.
Is the OpenRails team going to be implementing the unused pickup functions that MSTS has (i.e. mail bag pickup)? I have not long figured out the correct code setup within MSTS to enable a 'mail bag' to be picked up at speed, but there is no known "animation" function for this. I have experimented with using the MSTS bin patch operating doors function but the doors will only work whilst the train is stationary. Would OpenRails be eventually having opening doors that aren’t speed restricted to enable the realistic mail bag pickup to be achieved?

Justin

Metro/Win 8 does not seem to be a concerns of the programmers... at least not at present.

WRT pickup items and/or doors, I don't recall any team discussions on that subject at all, but I have seen them mentioned in bug reports.

Based on the lack of discussion I would not expect those features to be addressed any time soon, certainly not between today and V0.9. and we're I to place a bet I'd pick a date well off in the future. Same w/ hazards.

Hi Dave,

Thanks for clearing that up for us.
I wasn't expecting the pickup/doors to be adressed til later if at all, but I thought I'd just check anyway.

Justin

Hi guys,

I've only just installed OR having had too many dramas with my machines and MSTS in the initial development years.

Having worked on MEP I had also missed out on some excellent US routes, my interest in Railroads being as great as on Railways.

I have to say that a good few US routes (payware and freeware) seem to run very well in the Latest Version of OR but it still seems to have some really irritating little bugs that rather spoil the experience.  One being that if you hit the 4 (trackside-cam) button it sometimes applies the emergency brakes!!!!  

The Superelevation and Cab Wobble are good and even better is the ability to vary each.  The Cab wobble is a tads too great in longitudinal wobble and needs more latitudinal movement IMO?

I particularly like the ability run MST in correct aspect ratio in 16x9 too.  

There's no doubt that there's a lot needed yet but as I don't intend to spend another penny on "the other sim", and still like a lot of the payware produced for MSTS (still flourishing in the US & Canada) I'm pinning my TrainSim future on OR.  Trying to move house right now so by the time I've pulled that off it'll probably be a finished Sim?!   

Geoff

Nice to hear from you Geoff, and it's always of interest to hear about OR experience. I still enjoy the "MSTS experience", and perhaps if I can persuade the chancellor (SWMBO) to let me upgrade my hardware I may be able to use OR. It will all depend how much they change things to take advantage of the latest hardware!