Wish List -2

* UI: "Kiosk" Mode - Render Engine, rout position can be reset by scripts without need to restart program, Intended to support Museum usage.

* API: for interfacing to external control hardware (The hope here is that if the sim can be linked with real cab instrumentation it could be used in a 'proffessional' capacity'

*API: 'Marker' Overhaul - The current system is based on marker Icons of a specific size and positioning.. With the advent of true 3D, it may be more appropriate to implement some kind of 'popup' data API.

*API: Extend the Black Box/Logging API , so plugins can write data to it, This is so that things like TPWS activations (which get recorded in real Black boxes) . ( Detalied log analysis is beyond the realm of the simulator though.)

*Parser (Objects) : (By option setting) Parse numbers of the form 3'6'', 18'' doing appropriate conversions where a numeric value is required.
*Parser (Objects) : (By option setting) Treat all numbers as mm (Partially implemented in existing code).

* Parser (Routes)/Platform(Track) : Implement a means to have pre-defined track models. In reading some UK Railway Group Standards,
it seems there are only a few basic track geometry models, the parameters of which are fixed. As getting the track correct is
one of the more time consuming aspects of developing, it would be nice to have a way of generating without having to do too much math.

*Parser (Routes)- Implement TunnelL/R(x) object types as distinct from walls, mainly intended for Metro/tube routes...
*Parser (Routes)-
.ObjectList(x)=freeobj1;(x1,y1,z1,...)(,freeobj2;(x1,y1,z1,...) ... - Creates a list/group of objects
Track.avenue Objlist;track;x;y;z;ro;phi - Place object group -
Intent is to allow predefined sequences of repeating objects like trees, hedges etc, which is more flexible than Wall(x), Ground(x) ..

*Parser (Routes)- Implement TunnelL/R(x) object types as distinct from walls, mainly intended for Metro/tube routes...

This is only meant to make a developers life easier or does it serve more purposes than that? (for instance, curved walls)

alex_farlie wrote:

• UI: "Kiosk" Mode - Render Engine, rout position can be reset by scripts without need to restart program, Intended to support Museum usage.
  
  
• API: for interfacing to external control hardware (The hope here is that if the sim can be linked with real cab instrumentation it could be used in a 'proffessional' capacity'

These two would be great, especially if it would be possible to ingerate from a second workstation while the sim is running: Throw back a signal etc. That would be usable both for signal box simulation and educational usage; for all I know, there is no system* nowhere in the world which would allow trainee-train drivers and trainee-signal(wo)men interact in a realistic simulation; but it would immensly increase mutual understanding and be great for realistic communications training.

*Apart from, of course, the theoretical and very expensive, thus afaik not used possibility to build a narrow gauge network (5" would be enough already) for training usage; and also why this could be done 100% realistic for signal box personnel, it can not for train personnel; while an OpenBVE-based simulation would be highly realistic for both.

Drag0nflamez wrote:

*Parser (Routes)- Implement TunnelL/R(x) object types as distinct from walls, mainly intended for Metro/tube routes...

This is only meant to make a developers life easier or does it serve more purposes than that? (for instance, curved walls)

This was intended to be used as a developer convenience. In Engine terms it's not that different from a Wall., the intent in time was to have something whereby tunnels auto-scaled based on the number of tracks and so forth, on the basis of a geometric model adjustment, but that's
going to be a LONG time in consultation to get right.

Quork wrote:

alex_farlie wrote:

• UI: "Kiosk" Mode - Render Engine, rout position can be reset by scripts without need to restart program, Intended to support Museum usage.
  
  
• API: for interfacing to external control hardware (The hope here is that if the sim can be linked with real cab instrumentation it could be used in a 'proffessional' capacity'

These two would be great, especially if it would be possible to ingerate from a second workstation while the sim is running: Throw back a signal etc. That would be usable both for signal box simulation and educational usage; for all I know, there is no system* nowhere in the world which would allow trainee-train drivers and trainee-signal(wo)men interact in a realistic simulation; but it would immensly increase mutual understanding and be great for realistic communications training.

Quork, I would agree with you on this, about implementing a 'second-workstation' or console options.. - Nearly all of the pro level training sims I've encountered, have a number of displays. Further modularisation of 'PlatformTwo' should consider having 'multi-head' and 'console'
which could be located on other displays/workstations. Further consultation would be needed as to what additional workstation/console would need in UI/API terms. Perhaps once you've completed the PZB Guide, you'd be willing to undertake a technical evaluation of simulation options in use?

*Apart from, of course, the theoretical and very expensive, thus afaik not used possibility to build a narrow gauge network (5" would be enough already) for training usage; and also why this could be done 100% realistic for signal box personnel, it can not for train personnel; while an OpenBVE-based simulation would be highly realistic for both.

Use of a 'model' or 'miniature' railway for training purposes is NOT unknown, IIRC The British Armed Forces maintained a 'model' railway for training purposes until very recently. London Underground also used to have a model railway it used for training..
(On a tangent, in the video footage I've seen about Minatur Wonderland, -http://www.miniatur-wunderland.com/ the control system
looks remarkably advanced for a model railway. I could easily mistake thier control room for a genuine signal cabin! )

alex_farlie wrote:Further consultation would be needed as to what additional workstation/console would need in UI/API terms. Perhaps once you've completed the PZB Guide, you'd be willing to undertake a technical evaluation of simulation options in use?

I'm not sure if I got it right what you propose - an analyse what options would be necessary, what strongly suggested and what nice to have for OpenBVE to become suitable for educational purpose? Yeah I could do that, I'd interview the teacher-drivers and higher levels, I'm quite sure I'd receive enough feedback to make a good overview.

Quork wrote:

alex_farlie wrote:Further consultation would be needed as to what additional workstation/console would need in UI/API terms. Perhaps once you've completed the PZB Guide, you'd be willing to undertake a technical evaluation of simulation options in use?

I'm not sure if I got it right what you propose - an analyse what options would be necessary, what strongly suggested and what nice to have for OpenBVE to become suitable for educational purpose? Yeah I could do that, I'd interview the teacher-drivers and higher levels, I'm quite sure I'd receive enough feedback to make a good overview.

I will assume that being an active employee of DB you are familiar with technical writing.

What I was suggesting was a 'short' technical report, which could be used to form a more detailed technical 'spec' on what 'PlatfomTwo'
would need to cope with, and which could be used be the program developers (whoever they may become.). Your comments above suggest you have understand my suggestions perfectly.

My current thinking is that such a report would have at least 4 basic sections being :-

i) What the requirement of 'cab' simulators in railway applications were.
ii) How the existing solutions, such as for example , professional hi-end simulators met those requirments.
iii) How programs aimed at the enthusiast market on desktop sytems compare in practical terms
iv) How features present in 'professional' simulators, could be implemented in 'desktop' simulators within practical limits.

As well as looking at OpenBVE you might want to look at a simulator called LokSim , which was developed in Germany (and has
a much closer implementation of various German systems..)

I was a LokSim3D-user and -content-dev for long years and quit it for various reasons. Part of them also disqualify LokSim3D for use in this context. Above all, the licensing.

One thing has to be clarified already now; OpenBVE won't be able to replace the professional high-end simulators. These have the exact computer hardware and exact software their real counterparts have, they have tons of certificates and are used for a good deal of official exams. There's a reason why they cost millions. Hardware, even including the movement system, makes only a part of the costs. They have to act exactly as the real thing under any condition, how unlikely it might be. An educational usage of OpenBVE would rather be suited at filling a niche which is completely empty; that's the rather basic operational knowledge like signals etc. It would add to the now mostly theoretic lessons. As such, comparing OpenBVE to the professional simulators is only sensible within certain limits.
Another aspect I mentioned is communications between train drivers and signal(wo)men. This is something of interest for the vocational schools rather than DB or other railway companies due to organizational aspects, so a sector even less comparable to the present-day field of application of simulators.

With those points clarified, I think nothing is in the way to do such a paper.

[quote="Quork"]I was a LokSim3D-user and -content-dev for long years and quit it for various reasons. Part of them also disqualify LokSim3D for use in this context. Above all, the licensing.

One thing has to be clarified already now; OpenBVE won't be able to replace the professional high-end simulators. These have the exact computer hardware and exact software their real counterparts have, they have tons of certificates and are used for a good deal of official exams. There's a reason why they cost millions. Hardware, even including the movement system, makes only a part of the costs. They have to act exactly as the real thing under any condition, how unlikely it might be.[quote]

That's a very well argued point, so most of my comments above don't really apply.

An educational usage of OpenBVE would rather be suited at filling a niche which is completely empty; that's the rather basic operational knowledge like signals etc. It would add to the now mostly theoretic lessons. As such, comparing OpenBVE to the professional simulators is only sensible within certain limits.

Noted.

Another aspect I mentioned is communications between train drivers and signal(wo)men. This is something of interest for the vocational schools rather than DB or other railway companies due to organizational aspects, so a sector even less comparable to the present-day field of application of simulators.

With those points clarified, I think nothing is in the way to do such a paper.

Well one use case I had in mind was 'museums' use, where for the practical reason you mention, it's not possible to build a full cab sim of the professional design..

The London Transport Museum already makes some use of OpenBVE, and I hope that it can also make use of the CSLR route under development by others on this forum. ( Side note to the developers of that route, that the LTM Archive may reveal some original plans
that may aid development.)

Maybe I should clarify one more point, the vocational schools I mentioned.

Professional training of train drivers is done in a system called "Duale Ausbildung", you can look it up on english Wikipedia as dual education system. The profession is taught in two places; one is the company, which is the employer (in my case: DB Fernverkehr), the other is the public vocational school. In theory, the company provides the practical knowledge and the school theoretical knowledge and general education. Obviously, this system comes from crafting professions and is not exactly applicable at a profession as operational railway staff; the company has to teach most of the theory while the school rather covers the overall knowledge which isn't strictly operational but rather offers background knowledge; that's railway history, railway legislation, technical basics et cetera. So when I mentioned above interdisciplinary (train driver <-> signalbox personnel) usage of OpenBVE to be rather a topic for vocational schools, this doesn't mean this would be outside professional training, it is only another sub-environment of train driver education than the classic field of use of simulators.

Shortly put: An OpenBVE-based system would be way simpler than the big simulators and aimed at far earlier use, more at the beginners, a first step into practical application of newly acquired knowledge at a stage where today there is no way to test the knowledge in any more realistic way than on a H0 or N scale model railroad.