Wish list.

* Integrate parser for BVE Route Randomiser, the code for BRR.NET was released by it's developer IIRC. If not could consideration be given
to expanding the current csv parser to cope with greater randomisation.

* Continue implementation of TSF API to allow all components (including plugins) to be fully migrated to a cross platform approach.
(* Documentation, Documentation, Documentation!)

* Extend sound 'parser' to cope with sound formats other than RAW wave sample. ( Consult on suitable formats.)
* Physics/control model for Steam Traction as opposed to the hybrid used currently.

* Overhaul of the render engine, so that a full 3D view can be rendered with appropriate optomisations.
* Overhaul of the parsers to support a full 3D environment.

* Overhaul of the track model, I'd like to be able to define a route using 'fixed' styles of switch, and node points rather than fixed block
lengths.

*Track section object generators... That can based on user choice make any switch, at any guage, including check rails etc...
Such a program would have use beyond OpenBVE if well written.

In the long term:
- Route files with all tracks usable and bidirectional, with working points and trains running other ways, other timetables, either by extending the current format or with a new format
- Possibility to independently steer dynamic brake (electric brake, hydraulic brake, retarder, steam brake) and pneumatic brake

In the middle term:
- Train formation variable, by e.g. changing count of carriages on stations
- More influence on brake settings, possibly similar to engine settings; for every brake position and for EB position define a force curve, like with engine, a brake pipe pressure, a cylinder pressure curve
- Text-based object parametrization combined with an internal solution for fonts (for kilometration signs etc.)

In the short term:
- pause sound when simulation is paused
- option "start paused"

-Simplified method for developers to utilize the managed content system

-Flange sound "profiles" incorporated in to route files to prevent flange noise from played on even the slightest curve when not realistic
(ex: Sometimes, flange guards and/or oilers are used to prevent flange noise except under excessive speed, also coning of the wheels prevents flange squealing at lower speeds generating a similar effect)

-More realistic toppling and derailments

ATO built in and enabled by the train.dat - used by having another reverser setting after "F" of "F-A" - all the work already done on AI can be modified to be a bit faster and more decisive, and through the train.dat decide if you need to press start, how to control doors etc

My biggest wish is to have a possibility to to play / stop sound within animated objects...

I really don't buy the idea of BRR. It just simply mess up a normal route.

The Chashinai Railway (http://odakyufan.zxq.net/chashinai/index.html) actually does a very good work to include randomization in the route, at least in a reasonable manner, unlike BRR which simply choose to branch into any "Rails" and mess up the whole journey.

I don't really like the CSV format (neither the RW format) as those preprocessors can be quite messy, but it's not that easy to introduce a well-designed route format.

I think that the original Roadmap written by Michelle is enough for a mid-term development, and can already fulfill half of the items above.

I'd quite like to see OpenBVE make very good use of my system. Would also be nice to have anti-aliasing.

Being able to switch between trains, drive from either end of the locomotive (switching cab), being able to control the points and coupling/uncoupling too would be a fantastic addition.

alvinhochun wrote:I really don't buy the idea of BRR. It just simply mess up a normal route.

The Chashinai Railway (http://odakyufan.zxq.net/chashinai/index.html) actually does a very good work to include randomization in the route, at least in a reasonable manner, unlike BRR which simply choose to branch into any "Rails" and mess up the whole journey.

I don't really like the CSV format (neither the RW format) as those preprocessors can be quite messy, but it's not that easy to introduce a well-designed route format.

I think that the original Roadmap written by Michelle is enough for a mid-term development, and can already fulfill half of the items above.

Why do you not want BRR to work with openBVE?! I mean, its so boring running a route with the exact same signals and the exact same way? One, rarely does that happen in real life (hint openBVE being titled a "simulator") and second, it makes it too easy to know what to expect and doesnt make it as challenging because you would never know what the signal around the curve might say. What do you say to that?

Have you ever tried using BRR?

Have you ever tried using BRR? Do you know how messy the route will be by using BRR?

BRR is stupid as it just randomly "route" you to other tracks, even when those tracks aren't meant to be driven, or is for the opposite line. It may be quite "fun" but is always not realistic.

The best way is for the developer to manually specify what randomization will be included. The best route I've ever come into is the Chashinai Railway, which makes use of all possible commands in openBVE to archive suitable randomization like ending platforms, pretrain frequency, day/night conditions, etc.