In my initial roadmap, creating support for 3D cabs was the next step to be done after version 1.0. Unfortunately, my plans to revamp the entire architecture would ultimately delay this by half or a full year. Therefore, I am considering a quick solution to introduce 3D cabs with minimal effort. But it depends on what you think and how exactly it should be done.

The solution with least effort would be to recycle the animated object system, and therefore use a single animated object file to represent the cab, such as cab.animated (having precedence over panel2.cfg and panel.cfg). There would need to be a series of new variables to query all relevant states of the train, e.g. reverser, power notch, brake notch, etc. Introducing these variables would be one requirement, but there might be more considerations.

The camera would be able to rotate freely in the cab, thus no camera restriction is required. The driver's eye location could be sufficiently determined via the train.dat (#CAB or #COCKPIT section). Sounds would be left the way they are for now. While I will ultimately introduce the functionality to place sounds freely in each car, it would be some sort of a wasted effort to do this for the BVE-style trains now.

I would like you to consider the usefulness of 3D cabs with existing trains, to think of the list of required variables, and for anything else that would be necessary for 3D cabs and I have missed to mention or consider.

---

List of variables that need to be introduced (may not be complete):

reverserNotch: Queries the state of the reverser, i.e. -1 (B), 0 (N) or 1 (F).
powerNotch: The current power notch.
powerNotches: The amount of power notches.
brakeNotch: The current brake notch, or 0 (REL) / 1 (LAP) / 2 (SRV) for trains with automatic air brake.
brakeNotches: The amount of brake notches, or 2 for trains with automatic air brake.
brakeNotchLinear: The current brake notch plus hold brake plus emergency brake, e.g. 0 (B0), 1 (HLD), 2 (B1), 3 (B2), 4 (B3), 5 (EMG), or 0 (REL) / 1 (LAP) / 2 (SRV) / 3 (EMG) for trains with automatic air brake.
brakeNotchesLinear: The amount of brake notches plus hold brake plus emergency brake, or 3 for trains with automatic air brake.
emergencyBrake: Whether the emergency brake is currently active (1) or not (0).
hasAirBrake: Whether the train has the automatic air brake (1) or not (0).
holdBrake: Whether the hold brake is currently active (1) or not (0).
hasHoldBrake: Whether the train has the hold brake (1) or not (0).
constSpeed: Whether the const speed system is currently active (1) or not (0).
hasConstSpeed: Whether the train has the const speed sytem (1) or not (0).

brakeCylinder: The pressure in the brake cylinder in Pa.
brakePipe: The pressure in the brake pipe in Pa.
emergencyReservoir: The pressure in the emergency reservoir in Pa.
mainReservoir: The pressure in the main resevoir in Pa.

doors: The state of the doors in all cars, i.e. between 0 (closed) and 1 (open) [already available]
doors[carIndex]: The state of the doors in a particular car, i.e. between 0 (closed) and 1 (open)
leftDoors: The state of the left doors in all cars, i.e. between 0 (closed) and 1 (open)
leftDoors[carIndex]: The state of the left doors in a particular car, i.e. between 0 (closed) and 1 (open) [already available]
rightDoors: The state of the right doors in all cars, i.e. between 0 (closed) and 1 (open)
rightDoors[carIndex]: The state of the right doors in a particular car, i.e. between 0 (closed) and 1 (open) [already available]
leftDoorsTarget: The target state of the left doors in all cars, i.e. 0 (closed) or 1 (open) [already available]
leftDoorsTarget[carIndex]: The target state of the left doors in a particular car, i.e. 0 (closed) or 1 (open)
rightDoorsTarget: The target state of the right doors in all cars, i.e. 0 (closed) or 1 (open) [already available]
rightDoorsTarget[carIndex]: The target state of the right doors in a particular car, i.e. 0 (closed) or 1 (open)

ats: The ATS lamp, i.e. inactive (0) or active (1)
atsRun: The ATS RUN lamp, i.e. inactive (0), lit (1), or flashing (2)
pPower: The P POWER lamp, i.e. inactive (0) or active (1)
ptnApproach: The PTN APPROACH lamp, i.e. inactive (0) or active (1)
brakeRelease: The BRAKE RELEASE lamp, i.e. inactive (0) or active (1)
atsP: The ATS P lamp, i.e. inactive (0) or active (1)
failure: The FAILURE lamp, i.e. inactive (0) or active (1)
atc: The ATC lamp, i.e. inactive (0) or active (1)
atcPower: The ATC POWER lamp, i.e. inactive (0) or active (1)
atcSrv: The ATC SRV lamp, i.e. inactive (0) or active (1)
atcEmg: The ATC EMG lamp, i.e. inactive (0) or active (1)
atcState: The current state of ATC, i.e. 0 (X), 1 (0 km/h), 2 (15 km/h), 3 (25 km/h), ..., 9 (100 km/h), 10 (110 km/h), 11 (120 km/h), 12 (ATS)

Something that I have dreamt of when I though about 3D cabs was the added realism. The driver should be able to freely look around, watch all the instruments and levers, and interact with them accordingly. Personally, I feel it to be unnecessary to maintain the reverser/power/brake indicators, as well as the door indicators, which are currently displayed as part of the UI, and instead would want to ask developers to include those things as part of the train. For example, even trains using panel.cfg/panel2.cfg can include animated handles, but many don't, therefore it's necessary to include those readouts as part of the UI. Here, however, we have the chance to change this from the beginning. I don't know that you think of this, but I would favor abandoning all non-realistic UI elements in favor of actual cab components.

Likewise, the default safety systems (ATS/ATC) play currently a special role in that they receive readouts as part of the UI instead of as part of the cab. In my above post, I have already indicated that the developer should be able to display these indicators as part of the cab where they belong. I have proposed variables to query the default safety systems, but I would like to revise that. Currently, ATS/ATC are built-in, but for openBVE 2, this will change, and they will be plugin-based just as any other safety system. As such, I don't think that adding variables exclusively for it is a good idea, definately not a consistent one. How would current plugins need to be queried? Right, using the pluginstate[index] variable. The same thing should be done, for consistency, with the default security systems. As such, I think the built-in ATS/ATC systems should instead be read out by querying the pluginstate[index] variable, with the following mapping (for example):

0: ATS
1: ATS RUN
2: P POWER
3: PTN APPROACH
4: BRAKE RELEASE
5: BRAKE OPERATION
6: ATS P
7: FAILURE
8: ATC
9: ATC POWER
10: ATC SRV
11: ATC EMG
12: CONST SPEED
13: EB
14: current ATC speed indicator state

---

I have thought about how developers would get along writing an animated object for a 3D cab, and I think it's obvious that Object Viewer will need to be expanded to load animated objects, albeit without having any of the train contexts, thus most variables queried would be zero, for example. There are other things that might slow down developers otherwise. Here are some I have encountered.

First of all, the ANIMATED object format is a format that tells how to manipulate other objects (B3D/CSV/X). Even for very simple objects, like rectangles which have a simple texture on it (I assume you will have plenty of them in a cab), you will still need to write a lot of code.

For example, even to create a simple textured rectangle, this is the CSV code you need:

Code: Select all

AddVertex, -3, -1
AddVertex, -3, 1
AddVertex, 3, 1
AddVertex, 3, -1
AddFace, 0, 1, 2, 3
SetTextureCoordinates, 0, 0, 1
SetTextureCoordinates, 1, 0, 0
SetTextureCoordinates, 2, 1, 0
SetTextureCoordinates, 3, 1, 1
LoadTexture, apple.png

To create simple rectangles, I proprose a short-cut command similar to Cube and Cylinder, of the following form:
Rectangle, X, Y

In the above, X is the total width and Y the total height. The object would be placed in the XY-plane at Z=0, centered around the origin. The command would be equivalent to the following code:

Code: Select all

AddVertex, -X/2, -Y/2
AddVertex, -X/2, Y/2
AddVertex, X/2, Y/2
AddVertex, X/2, -Y/2
AddFace, 0, 1, 2, 3
SetTextureCoordinates, 0, 0, 1
SetTextureCoordinates, 1, 0, 0
SetTextureCoordinates, 2, 1, 0
SetTextureCoordinates, 3, 1, 1

Therefore, my above rectangle example could be simply written as:

Code: Select all

Rectangle, 6, 2
LoadTexture, apple.png

---

Second of all, every ANIMATED object requires you to reference other objects (B3D/CSV/X), and that even if the contained code would be just as short as above. Therefore, I have thought about an option to inline B3D and CSV content directly into the ANIMATED format, for example like this:

Code: Select all

[b3d APPLE]
   rectangle 6, 2
   load apple.png
[/b3d]

[object]
states = APPLE
translatexfunction = mod[time, 60]


I am not quite sure how to do it, but in my above example, a section of B3D code was created with the name of APPLE, and this then later referenced in the states parameter instead of giving a file name. I assume that inlining small code might speed up development, although I also assume that it could be done differently and potentially more efficiently than in my example. A potentially shorter way would be removing the states parameter for inlining code and replacing it with something like this:

Code: Select all

[object]
b3d:
   rectangle 6, 2
   load apple.png
csv:
   rectangle, 3, 6
   loadtexture, banana.png
end:
statefunction = mod[time, 2]

It's currently just the idea that counts, not how to implement it. I am open for comments on all the things I have proposed, and beyond.

Abandoning the power/brake/reverser and door indicators would not be a good idea. We will be using BVE-style trains for a long time and they need those indicators. Hiding them with an option to turn them on in-game would be OK, but still not necessary, I think.

I was not referring to abandoning the indicators for trains using panel.cfg/panel2.cfg, but for those using 3D cabs as I want them to have animated counterparts.

How about adding more variables?

distanceToNextStop
distanceToStop[i]
nextStopIndex
stopDistance[i]
stopIndexAtDistance[distance]
trainOverRun

We can make trains specified to a route.

I have also thought about station-related variables, and they have been proposed before, however, without specifying the behavior. And this is where I see a problem. While it is straight-forward to think about having a variable that gives the distance to the next stop point, what should happen once the train has come to a stop at the station, or when it departs? Should any variable return the distance to the next anticipated stop point (which might change once the train is about to depart), or should it return the distance to the closest stop point (which might change in the midst of the route)? Presumably, some variation is good, but I currently fail to imagine usage examples.

There should... must have a Train Cab Object Viewer.
There should be an user-interface, where we can alter different variables, like

doors-related
distance-related
speed-related
plugin-related
route-related
something else...


Surely, it must be difficult to make aa user-interface without a GUI IDE like Visual Basic does.
(Or is it my problem that Visual C# also have GUI?)



ADDED--------
The Viewer should also have ability to load exterior train object.

I thought about that too, though I'd rather integrate this functionality directly into Object Viewer, instead of having an additional program.
My idea would be having some kind of dialog like this one (this doesn't mean it has to look or work exactly like this one, but a picture is worth a thousand words):

The drop down box contains all possible animation variables, but is also editable, so you can select the pluginstate variable you want to use. Then you can enter the desired values into the min and max boxes (I think somethink is needed for the step size, too, because in the above example, 0.1 per step would suffice, but if you use 0 - 1 to test door control, you're going to need finer steps) and then play around with the slider, and watch the animated object moving/turning/whatever around. The check boxes are pretty self explaing, or so I hope.
Finally, just to repeat it, this is only a rough idea and there might be a far better way to implement this.

@alvinwong: As far as Visual Studio is concerned, the Visual Basic and C# versions are pretty similar and both have and use the same GUI editor.

Thanks for your rough idea, Jan.
However, I think the dialog box should contains all variables, not a drop down combo box.
The doors related variables should be able to change together.
Also, provide door opening and closing.

If everything is right, I will try to make one base on Route Viewer.


If the openBVE have ability to reload route, everything would be easier.

michelle wrote:I don't know that you think of this, but I would favor abandoning all non-realistic UI elements in favor of actual cab components.

It sounds intriguing, but I'm not convinced it will work well in practice. Certainly, a real-life driver does not have UI readouts projectes on his retinas. However, that driver views his enviroment in a 'higher resolution' than even a high-quality openBVE cab will offer; he can get a non-visual reading by touching the handles; and he's very familiar with the train he drives, which openBVE users frequently are not. Train developers can try to get around these problems, but some will not, and the results may not be superior to the standard UI readouts. Therefore, I think that at the very least, the UI readouts should be available for those who wish them - preferably not linked to the choice of arcade/normal/expert mode or even as an option in the menu, but toggled via keystroke.

I agree. The tactile "readout" you get in reality cannot be reproduced in a simulator, unless you have that kind of controls at hand, which most player's don't. Anyone who wishes to disable the readouts can do so by pressing F10.

Same here