➟ Proceed to April 2009.
At least, the new in-game display architecture allows for external configuration files, meaning that custom in-game displays can be created with some limitations. Once the in-game graphics are complete, which might take just a little more time, version 0.9.6 will be released, which will form a release candidate for version 1.0. Basically this means that users can test once again any changes that happened between 0.9.5 and 0.9.6, and if everything works as intended, version 1.0 will be released shortly afterward. Due to time limitations, I will not be able to provide the complete documentation with version 1.0 though, but will eventually finish it over time.
I have departed from using Microsoft Visual Studio 2005 and am using SharpDevelop from now on. Additionally, I will be including both a 32-bit version and a 64-bit version of the openBVE executable from now on. Windows users will only be able to use the 32-bit version as the dependencies (DLL files) are only 32-bit. Linux/Mac users might be in a similar situation, but not necessarily. Currently, as OpenBve.exe is enforced to run as 32-bit, Linux/Mac users with a 64-bit CPU might not get to run the program at all, which will be fixed this way. I discovered some nasty coding mistakes in some route files that greatly affect the way track positions and associated commands are interpreted. For example, code like 0;0;180 might be reminiscent of a Track.FreeObj command, but it resets the track position to 0 in the Loose number parsing model. As resetting the track position to a nonsense values here will basically invalidate the route both at that point (0), as well as on the track position used before, I have decided to use strict parsing for the track positions. As a consequence, expressions like in the above example will from now on be treated as unknown commands, raising a warning message thereby. As requested by some users quite a while ago, the camera settings are now preserved when switching between interior (F1), exterior (F2) and track (F3) views. Furthermore, I noticed that if a route does not have any stations, entering the Jump to station menu crashes the program. This is now fixed by not including the entry in the in-game menu in this scenario.
With what I have planned, the route loader can define point-based events in the route that might be processed by other plugins, e.g. transponders by the safety system plugin. Additionally, there the route loader can define spans, which have a beginning and an end, so that other plugins can query the spans currently in, e.g. to determine the rail type, or flange type, or any other type to play sounds, or to do other things. But this again leads to the question: How many different plugins should there be to make use of these possibilities? Theoretically, there are two choices: First, allow for as many plugins as the route and train desire and leave it to the plugins to decide which one does what. This would provide for the highest degree of freedom, but extensive coordination between plugin developers would be required and the possibility to freely combine plugins would be compromised. For example, one plugin might simulate both physics and brake systems, while with others, this could be separated. What if plugins are combined in a way that makes their roles duplicated? This would not be good. The second choice is to have clearly defined roles. But then again, which ones do we need? Which plugin needs to do what? And what parts should the core engine do itself? One can also ask oneself a simple question: Would a particular plugin that is provided in the Standard Library actually be replaced or complemented by anyone, ever? I think this might be a possibility with the physics plugin, assuming that the default one targets only conventional trains. I don't know much about maglev physics, but there are surely differences. And what about special interests, such as park rides, buses or flight sims? Is it necessary to allow for them? Currently, physics assumes that the Y-axis is the axis of gravitation, as if the Earth was flat. I could imagine that someone wants to use spherical data for the route building process, i.e. using fully 3D coordinates on the Earth. Then, a different physics plugin would be required to do actual vector arithmetics toward the Earth's center. As such, I would want to have a separate physics plugin both to allow for realistic and meaningful things in the future, as well as for potential special interests. And what about brake systems? The air brake is already complicated enough that I never implemented to the extend I wanted to. Ultimately, I want to simulate the geometry of the slide valve inside the brake valve, and its exact position and connections. Arguably, there are a lot more different systems, and using plugins also for the brake systems would allow other people to write code for different systems. Safety systems, I think, do not need much more explanation. There is so much of a variety of systems around the world that there is always one that would not be already covered. This branch needs plugins. Arguably, the brake system and the safety system are not directly related, although one can communicate with the other, e.g. the safety system can activate the brakes. This should illustrate that even with clearly separated plugins, there is still a need for communication between them, and this could make combining plugins harder if they don't use the same "protocol" to communicate with each other. Thus, some initial questions that needs to be answered are:
I will continue trying to answer these questions.
Simulates the signalling, e.g. has a list of all sections, signals and trains, and can then decide which section/signal bears which state. Potential: The ability to simulate signalling in a complexity that surpasses that of the Standard Library, or to integrate with networking in order to allow for multiplayer/signaller operation to some degree.
Tells the core engine where to position each individual car and in which orientation. Simulates gravity, friction, air resistance, air temperature, air pressure, acceleration, etc. Potential: The ability to simulate physics in more detail than provided by the Standard Library (e.g. more realistic collisions, derailments, or vector-based gravity on a 3D sphere), or for special interests (e.g. bus or aircraft simulation).
Engine plugin: For electric trains: Simulates electrical subsystems and plays motor sounds. Could query electrification status of the track at any time to simulate gaps in the electrification or different voltages provided. Electrical brake is also simulated here. Depending on the power notch selected, tells the physics plugin to provide for a certain amount of acceleration. For diesel trains: Additionally simulates fuel consumption and plays diesel motor sounds. Tells the physics plugin to provide a certain amount of acceleration and the change of mass due to fuel consumption. Potential: The ability to simulate a variety of different engines (e.g. electic, diesel, maglev, steam) which are not already provided by the Standard Library, or in more detail. Brake plugin: Simulates physical brake components that are virtually independent of the type of engine used, e.g. the Westinghouse air brake and derivatives, vacuum brakes, etc. Tells the physics plugin to provide for a certain amount of acceleration. Plays any brake-related sounds. Potential: The ability to simulate a variety of different brake systems which are not already provided by the Standard Library, or in more detail. Safety system plugin: Simulates the safety system (train protection system) by querying transponders, analyzing the position of other trains, etc. Tell the engine and brake system plugins to override the power or brake setting. Plays any sound related to the safety system. Potential: The ability to simulate a variety of different safety systems, e.g. ATS, ATC, ATP, AWS, TPWS, ETCS, ATO, etc. Environment plugin: Simulates anything related to the train chassis, e.g. plays run and flange sounds, animates light, wipers, etc., i.e. anything that is not directly related to the operation of the train, but for effects only. Potential: The ability to simulate any kind of effect not included in the Standard Library.
I think that this is a good start, but will require some input by the community (e.g. by train and plugin developers).
Additionally, I was aware of the issue with 32-bit and 64-bit systems for a long time. Assuming that the OpenAL dependencies eventually become available in 64-bit versions, I could change openBVE from 32-bit to AnyCPU. However, then, existing 32-bit safety system DLL files would not work on 64-bit systems, because any process can only load DLLs that target the same processor. The only possible solution I could come up with is to run a proxy in another (32-bit) process which communicates with the DLLs. Inter-process communication between openBVE (or a plugin) and the proxy would then be necessary, but this is a bit tricky within .NET, especially within 2.0 which I am currently targeting. As such, I have created a simple test application using System.Net.Sockets (TCP) which simulates function calls and return values for a synchronous execution (like when making normal DLL calls). First performance analysis shows that I can make about 25,000 such calls per second, which is not particularly fast. Surprisingly, using System.Runtime.Remoting.Channels.Ipc, I only get 10,000 calls per second, even though Remoting is said to be faster than Sockets.
➟ Proceed to April 2009. |