leezer3/OpenBVE#272

Earlier you said you were re-writing an engine from the ground up, I'm noting something I put in respect of the main repository:-

leezer3/OpenBVE#98

As a 'motion platform' simulator for rides would need a different engine, would you consider parallel development of a simulation engine for building 'dark-rides'?

No more needs to be said.

The following link is YouTube footage of a funicular railway: https://www.youtube.com/watch?v=2-jreSblE_c

Generally in Open BVE currently a "flat" track is assumed and graident changes are made with pitch commands..

Would it be possible to have an engine tweak that lets you define a 'ruling' pitch for something like a funicular, making intermediate pitch changes relative? This could possible be done by allowing the nominal 'z-' direction to be redefined perhaps?.

If this sort of change could be locally applied to sections of a route file, it may also be also possible to simulate something like - https://www.youtube.com/watch?v=7pXSSLZpdW4 but that would need a new route file format..

Currently Open BVE has a single render pathway, Whilst for most applications this is for performance reasons highly desirable, for others it is a limitation.

Some use cases for having more than one render pathway have been identified.

Currently Open BVE renders either a cab view, or various tracked external views dependent on user choice, on a single display device.

1. In some applications such as the London Transport Museum 'cab' simulations, it would be advantageous to have more than one output screen, representing views from different cab windows.

2. Proffesional simulators , tend to have multiple screens, in addition to those in the simulator for "instructor" and third party viewing of the simulation.

3. A 'composited' texture in the cab-view which could be enabled to simulate an on-train CCTV system, (like that on modern metro stock).

I'm not sure if any of these use cases could be easily supported in the forked version you are developing.

Currently OpenBVE assumes that it is being run directly by a user.

Whilst for it's uses to date, this is reasonable, for other uses it would be reasonable to have a 'kiosk' mode that could be enabled for uses cases where a single route would be loaded/rendered and run many times.

The London Transport Musum useage of OpenBVE would for example benefit from "kisok/cabinet" mode.

An AI driver is already present in OpenBVE, albiet it needs routes/trains to support it.

"Kisosk" mode, would also need:

• Resest time-outs. The route resets , invokes the AI mode or enters a demonstration mode after a certain definable timeout.
• "Operator" PIN to enter a maintenance mode, (which is effectively the non kiosk mode of the progam)
  and so on.. (will add more to this if I think of things)

I appreciate you are re-writing the engine for modern OpenGL techniques..
I noted this:-
http://hexus.net/tech/news/graphics/90491-raspberry-pi-2-gets-hardware-accelerated-opengl-support/

It would be nice if feasible to be able to have an OpenBVE derived engine that could run on a Pi3, which is cheaper than many desktop systems.

The thought here is museum/heratige attractions use., rather than use in the railway sector.

I'd noted this older repository on the main OpenBVE one:-
leezer3/OpenBVE#93

Noting an open issue on the main repositry here as well:-

leezer3/OpenBVE#99

leezer3/OpenBVE#284