MonoDevelop sayed on line 136 in Program.cs "System.IO.DirectoryNotFoundException".
I pressed 'Show details', unchecked 'Only my code', 'Copy', and CTRL+V here:

System.IO.DirectoryNotFoundException: Directory '/home/v/compile/OpenBVE/openBVE/OpenBve/bin/Debug/Data/Languages' not found.
at System.IO.Directory.ValidateDirectoryListing (System.String path, System.String searchPattern, System.Boolean& stop) [0x00081] in /tmp/buildd/mono-4.2.2.30/mcs/class/corlib/System.IO/Directory.cs:470
at System.IO.Directory.GetFileSystemEntries (System.String path, System.String searchPattern, FileAttributes mask, FileAttributes attrs) [0x00023] in /tmp/buildd/mono-4.2.2.30/mcs/class/corlib/System.IO/Directory.cs:489
at System.IO.Directory.GetFiles (System.String path, System.String searchPattern) [0x00000] in /tmp/buildd/mono-4.2.2.30/mcs/class/corlib/System.IO/Directory.cs:296
at OpenBve.Program.Main (System.String[] args) [0x00239] in /home/v/compile/OpenBVE/openBVE/OpenBve/System/Program.cs:136

Found sladen's old repository here - https://github.com/sladen/openbve2

When returning a spring-loaded joystick axis rapidly to zero, it tends to get stuck on some low value.

To reproduce: map the SINGLE_FULLAXIS, POWER_HALFAXIS, and BRAKE_HALFAXIS controls to spring-loaded joystick axes. Start driving normally. First increase power, then center the power axis rapidly. The power is often left on (P1) instead of returning to neutral. The same happens with brake. With rapid manipulation of the handle, it is possible to have the controller in the centre position, and the brake and power simultaneously on, even if the train has a combined handle (class 323).

There is an easy workaround: return power and brake to the centre slowly, one step at a time. Also, if either does get stuck, slowly move the controller to the affected direction and back.

This may to be a bug in Michelle's code, since it already appeared in older versions even before the OpenTK port. I thought it was a mechanical fault in my joystick, a dirty optical sensor or something to that effect, but jstest does register zero reliably every time. Nevertheless, I'm willing to accept the possibility of a mechanical failure. Also, rapid motions are slightly unrealistic anyway.

Since the recent changes in language management, some strings appear as "missing char" empty rectangles; the most evident are:

• Power and brake indicators in the bottom left corner if value is 0 ("Pn" and "Bn" for n != 0 are displayed correctly)
• Door indicators in the bottom centre

The debugger shows that the programme is attempting to display Chinese characters (rendered as "missing character" empty rectangles on my system).

Apparently, the programme is using the last language added with the AddLanguage() function in System/Translations/LanguageFile.cs which, on my system, happens to be zh-TW.cfg.

If relevant, please note that the function LoadLanguage() in the same file is never executed.

Just for reference, the system language of my machine is English (Ireland). The language set in openBVE options is English (US).

I'll try to gather more details but, perhaps, this might ring some bell already...

Daily auto-generated builds available from here as of now-
http://vps.bvecornwall.co.uk/OpenBVE/Builds/

The builds are listed oldest first. Can they appear newest first please?

Maybe also have a link to the most recent or stable build somewhere too.

As per OpenTK documentation, a joystick axis should vary between -1 and +1, 0 being the neutral or center position. Any controls assigned to a joystick axis seem to only have the 0 and +1 positions. The negative side is completely dead, and the positive side goes to +1 as soon as the axis deviates from zero. To verify: add the following line to controls.cfg and try driving any train with a combined power/brake handle (UK examples classes 323, 220):

SINGLE_FULLAXIS, joystick, 0, axis, 1, 1

Manual editing is required because of #4

I recently downloaded and installed openBVE 1.5.0.4 on Windows 8.1. At several places throughout the installation process my firewall (Comodo) was convinced that I was installing trojans and/or general malware. Here's one of the messages I got a screenie of.

http://imgur.com/8Sxwv8S

I eventually got it installed and used it to test a few routes and packages I made on my main BVE installation, but then decided to uninstall and reinstall the program. (I wanted to put it in a different directory and also get more screenshots of the malware detection.) I uninstalled it successfully, but when I try to reinstall it I get an error and the installation stops.

http://imgur.com/O63uXFo

This is unrelated to any of the above bugs, but I also had the issue of package content being installed into a location different from everything else, and IMHO it would be best to have a separate folder within the openBVE folder called "Downloaded packages" or something like that where all the automatically installed packages would be placed. They could also be chosen to play from a new tab alongside the one for choosing manually installed content, or even straight from the existing Package Management tab.

Some stuff I've been thinking about, marginally related to #89

Lighting at the moment is defined by the Route.DirectionalLight and Route.AmbientLight commands, and is fixed for the duration of a run without using tricks.
Whilst it can be altered to an extent by using the Brightness command, this isn't good for changing between radically different lighting. (A true night- dawn- day route for example)

What this requires, is to link the brightness to the time of day.
A brief synopsis of how this should work:
Brightness definitions need to be moved into a completely separate file.

This requires the following data structure:
A time, ambient light and directional light value must be defined for the following datum points:

Solar midnight
Dawn
Solar noon
Dusk

A sample XML:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <Brightness>
    <Midnight>
        <Time>12:00</Time>
        <AmbientLight>100,100,100</AmbientLight>
        <DirectionalLight>55,55,55</DirectionalLight>
        <LightDirection>40,230</LightDirection>
    </Midnight>
  </Brightness>
</openBVE>

The current lighting condition can then be relatively easily interpolated on a per-frame basis.

Routefile commands to override the ambient and directional light values would also be desirable, but this increases the compatibility divergance.

Hi,
I've seen this feature in TRS 2006 and I'd be happy to see it in openBVE. Example: you can use mouse drag to increase brake pressure. I understand that this is virtually impossible to implement with current train format, so I suggest it as a feature for eventual new format.

Best regards and thanks for continuing openBVE development,
Jakub Vaněk
Note: as I read documents in #34, I read Michelle has also thought of this, see "The potential future"

After using BVE and OpenBVE for a long time and developing routes, I have always wondered why the .Cycle option is limited to .Ground objects. It is a good option to avoid repeating the same grass texture each block, but extending it to .Rail objects would basically add the possibility of ignoring the legacy block sytem while retaining compatibility with existing addons. Let me explain the concept.

The legacy BVE block system limits the placement of track-dependant objects to positions that must be a multiple of 25. OpenBVE took a major step forward by allowing the user to choose a custom block length; short blocks can be used to achieve accurate track geometry in a similar way to what BVE5 does. However, a smaller repeating distance means that rails and track-dependant objects (walls, dikes, etc.) must be shorter, so long and realistic textures are impossible. Also, if the user wants to place an object every 20 metres with a block length of 5 metres, for example, the only solution is to type hundreds of lines of .FreeObj commands or to use the .Pole command (which has its own limitations).

Enabling the option to cycle through rail objects not only would make development easier and faster, but better results could be achieved. For example, let's say an addon developer wants to repeat a long track ballast texture every 25 metres while using 5-metre blocks. With a .Cycle option, the developer could split a 25-metre rail object into five 5-metre objects, each with one part of the texture, and make OpenBVE cycle through them to get the same result. Needless to say, it would be extremely simple to create a curve with these textures without the need to create a specific curved object.

However, the possibilities could expand even more if we defined the length and the span of the cycle. This would produce interesting results in curved tracks. 'Length' refers to the actual object length, and 'span' to the repetition distance. If a cycle had a 'span' of 100, each new object would be placed 100 metres after the previous one (think of the current .Pole command). 'Length' would be used to apply rotation to the object so that its end is correctly centered on the track position where the next object of the cycle is placed (the same rotation already used to connect blocks in curves but expanded beyond the current block length). This new option would be on par with the .Repeater command used in BVE5. Of course, we all know 'rails' in BVE are used for more things than just tracks (overhead wires, trees, etc).

The current CSV route format has a specific namespace for .Cycle structures that already handles ground cycles, but it is only used for Cycle.Ground. 'Cycle.Rail' could be easily defined without breaking compatibility with existing addons. A simple cycle option without 'length' or 'span' would be pretty much straightforward, but the two additional option would not be too difficult to add either (it is just some additional calculations). A rail cycle definition could look like this:

Cycle.Rail(0;length;span) 0;1;2,

Sorry if the explanation is a bit confusing, the concept is a bit complicated without real examples. Maybe some pictures could make it clearer? I will keep digging in the code to see how far can be OpenBVE pushed to its 'block' limits.

Regards,

See this video: https://www.youtube.com/watch?v=g7XV7cUfhW8
I just look around using arrow keys. Then I keep the right arrow pressed a bit longer and the camera starts rotating on its own (all physical keys are released). The same problem repeats with F1 at the end of the video (info flood). I don't know whether this is a bug in openBVE, OpenTK or the X11/SDL2 backend but it makes the game unplayable for me.
OS: Xubuntu 14.04.3 LTS
OpenTK version: 1.1.2188.6217
openBVE up-to-date at master branch

Hi all. For those who don't know, I am involved with the operation of openBVE at the NY Transit Museum, which has grown to be a very popular weekend event that draws an at-capacity crowd most days. I consulted with several operations employees at the MTA, and came up with a few suggestions that could substantially increase the realism and quality of the simulation.

Currently, even modestly complex signal behavior (specifically approach-controlled (timer) signalling) must be implemented through a combination of animated objects, beacons, and train plugins. (If there is a simpler way to implement it, aside from the invisible stations trick which clogs up the timetable, I’d love to know about it.) There is no guarantee that these are compatible between routes and trains from different developers, in spite of the recommended standards. Approach-controlled signalling is used by systems around the world, so IMHO it is common enough for openBVE to have built-in support for it. I’m envisioning a variation of the Track.Section command where each aspect the section can bear would be associated with a distance-to-start-the-timer and a time-to-hold-at-this-aspect. I understand if you’d consider this scope creep because of the almost unlimited number of signal systems in use around the world, but I think basic elements like this would greatly help route/train developers if they were included.

... Brake thoughts split ...
#80

Thank you so much for all your hard work and dedication to this program. You have countless higher ups on this side of the pond who are in awe of your work.

Tracking issue, split from discussion at the end of #81

WIP branch is here: https://github.com/leezer3/OpenBVE/tree/BVE5

What I've got at the minute is very much based upon Michelle's original parser, just adapted to the BVE5 syntax, although I'm also using it as a testbed for the cleanup I'm intending to do in the original parser.
In essence, each routefile command is split into it's own function, which are contained in the file openBVE/OpenBve/Parsers/Bve5ScenarioParser.Commands.cs

For testing, I've primarily been using a copy of Aln Valley (Simple single-track RouteBuilder route).
This is what's currently working:

• Basic route parser
• Legacy curves
• Signalling
• Stations

Partially working:

• Repeaters (25m block length only)
• Structure placements

Not implemented, planned:

• Beacons
• Secondary rails
• Gradient
• Train formats (Shouldn't be too hard, they appear to be BVE4 trains split up into multiple files)

I try to build all OpenBVE develop tools (TrainEditor, RouteViewer and other), but it's impossible.
Object Blender: "Invalid configuration mapping" error in project tree and in build output "Error: /home/v/compile/OpenBVE/ObjectBender/ObjectBender.csproj: /home/v/compile/OpenBVE/ObjectBender/ObjectBender.csproj could not import "$(MSBuildBinPath)\Microsoft.CSharp.Targets" (ObjectBender)"
Object Viewer: "/usr/lib/mono/4.5/Microsoft.Common.targets: Warning: Reference 'OpenBveApi' not resolved (ObjectViewer)" and "/home/v/compile/OpenBVE/ObjectViewer/CSC: Error CS2001: Source file `formOptions.designer.cs' could not be found (CS2001) (ObjectViewer)" in buld output.
Route Vewer: so many errors about "OpenBveApi not resolved".
Train Editor: "Error: /home/v/compile/OpenBVE/TrainEditor/TrainEditor.csproj: /home/v/compile/OpenBVE/TrainEditor/TrainEditor.csproj could not import "$(MSBuildBinPath)\Microsoft.CSharp.targets" (TrainEditor)" in build output.

Hi,
I have this problem: vanilla OpenBve.csproj is not working with xbuild. I'm going to create new PR for solution of other problems but I have problem with this:

  <PropertyGroup>
    <PreBuildEvent>set textTemplatingPath="%25CommonProgramFiles(x86)%25\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\texttransform.exe"
if %25textTemplatingPath%25=="\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\texttransform.exe" set textTemplatingPath="%25CommonProgramFiles%25\Microsoft Shared\TextTemplating\$(VisualStudioVersion)\texttransform.exe"
%25textTemplatingPath%25 "$(ProjectDir)\Properties\AssemblyInfo.tt"</PreBuildEvent>
  </PropertyGroup>

TextTransform.exe is provided by MonoDevelop. It usually resides at /usr/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe and I don't know how to make the path configurable. Switching between OSes shouldn't be a problem, see Mono Wiki. Could you please help me?
Thanks

OpenBVE's main form is rather glitchy when running the program with Mono (at least on Linux, Ubuntu 15.10 in my case).

The most noticeable glitch is related to the .png images displayed as a placeholder when a route or train doesn't have a custom image. If I'm not mistaken, these images were recompressed some time ago to fix a related bug. However, I tried replacing them with the files from the last "official" build by OdakyufanAts, and those seem to work. Here's how the glitch looks like:

Another important glitch happens when selecting some routes and switching tabs to see the map and gradient profile. I thought it was related to the first glitch, but apparently not, it's quite random. Some of the Chashinai Railway routes display the map, while others don't. The in-game route briefing window is unaffected and always works correctly.

Finally, during the last 2-3 days, the main form keeps reappearing after exiting the simulation. It didn't happen before, so it's surely related to a recent change. Also, the main form doesn't close when starting the simulation, but that has always happened and I think it's an old bug from the original builds.

Hi to all. I've been developing EMU's for OpenBVE for quite a while now, and there is a feature that it doesn't have: Continuous motor sounds. What i'm talking about is a feature where the motor sounds will still play even if the combined-throttle is at neutral. Most EMUs in real-life have a sounding motor even when no power or no brake is applied. I was wondering if there is possible to make this feature available, and to be added to Train Editor as a checkbox to let train developers choose whether to have a sounding motor when no brake or power is applied or not. Also, it would be nice if Train Editor and OpenBVE would allow more than 2 sounds to be played simultaneously on power or brake so that we can create even more realistic motor sounds.

Have you seen this? It looks really interesting.
http://railsimroutes.net/blog/?p=891
http://web.archive.org/web/20101129142153/http://openbve.trainsimcentral.co.uk/openbve2.html
(https://github.com/sladen/openbve2 ?)
Jakub Vaněk

OpenBVE already supports textual X objects using templates, which enables compatibility with BVE5 X objects. While most converted objects work, X objects designed from scratch have some variations which prevent them from being loaded correctly.

The issue comes up when an X object defines names for meshes and materials, and then makes references to them using that name. I am attaching two objects to show you the difference (they are part of the Fuji line for BVE5).

BG.zip

BG04 is loaded correctly by OpenBVE, because the materials are defined inside the 'Mesh' template. In BG05, however, the materials are defined outside of the mesh and then referenced using a name. The rest of the content is the same you would find in a 'normal' X object. It is a bit difficult to explain here, but it will be clear if you compare the files.

Hi!
I want to ask where I can obtain new Data folder. When I'm trying to start openBVE with old Data folder, the only thing that happens is a bunch of MessageBoxes informing me that controls.cfg format has changed.
This is the part of code causing the flood:

LoadControls(string FileOrNull, out Control[] Controls){
...
//We've discovered a SDL keybinding is present, so reset the loading process with the default keyconfig & show an appropriate error message
Thread Message = new Thread(() => MessageBox.Show("An older key-configuration file was found." + Environment.NewLine + "The current key-configuration has been reset to default.", Application.ProductName, MessageBoxButtons.OK, MessageBoxIcon.Hand));
Message.Start();
LoadControls(OpenBveApi.Path.CombineFile(Program.FileSystem.GetDataFolder("Controls"), "Default keyboard assignment.controls"), out CurrentControls);
return;
...
}

I have the old default keyboard controls assignment file, which causes infinite recursion. There should be some test if it's not loading default, if so, use some inbuilt default. And could you please provide a link to download actual Data folder?
Thanks,
JakubVanek

I posted a possible solution on following thread, sadly it's waiting for moderation: http://forums.uktrainsim.com/viewtopic.php?f=66&t=143351&st=0&sk=t&sd=a&start=30

MonoDevelop said:
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. Parameter name: button at OpenTK.Input.JoystickState.SetButton (JoystickButton button, Boolean value) [0x0000b] in <filename unknown>:0 at OpenTK.Platform.SDL2.Sdl2JoystickDriver.OpenTK.Input.IJoystickDriver2.GetState (Int32 index) [0x00070] in <filename unknown>:0 at OpenTK.Input.Joystick.GetState (Int32 index) [0x00000] in <filename unknown>:0 at OpenBve.Joysticks.Initialize () [0x00013] in /home/v/compile/OpenBVE/openBVE/OpenBve/System/Input/Joysticks.cs:49 at OpenBve.Program.Main (System.String[] args) [0x005d7] in /home/v/compile/OpenBVE/openBVE/OpenBve/System/Program.cs:224
My joystcik in lsusb output:
Bus 005 Device 003: ID 11c0:5603

Somwehere on an old disc I may have the sources/ x86 (32 bit) binary for the text editor Michelle wrote.

If you could let me have a current e-mail i can send you the zip, as I don't have GIT on Win32 to upload to the repository.

If controls.cfg contains the line
SECURITY_A1, joystick, 0, button, 8
AWS acknowledges itself, i.e. displays the sunflower, without sounding the horn (beep). The bell indicating a clear signal does sound, however. If the SECURITY_A1 control is configured for the keyboard, AWS works as normal.

Tested up to build 1.4.5.1429, Ubuntu 14.04 LTS, Mono 3.2.8, with the Class 323 (unrefurb) OpenBVE and UkTrainSys.dll.

Hello, plugins from openBVE 1.4.2 do not seem backwards compatible with openBVE 1.5 RC5.

I was looking forward to using 1.5's features for my routes, but the loading screen sends me back to the main menu.

Tried a line with the latest build:

mono OpenBve.exe
Stacktrace:
Native stacktrace:
mono() [0x4b73d8]
mono() [0x50f13b]
mono() [0x423d22]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x10340) [0x7f4488cc8340]
/usr/lib/nvidia-340-updates/libGL.so.1(+0xd7c09) [0x7f4466b7fc09]
Debug info from gdb:
Could not attach to process. If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user. For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
No threads.

Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.

Aborted

Combination of the following:
Route: OpenBVE Northern Line. Edgware - Morden via Bank 1998
Train: 1992TS

Trying that route with another train, or that train with another route, both work fine.

Same problem in both fullscreen and windowed mode. After pressing start, the splash screen shows and the progress bar fills. Once full bar, the application quits.

Should I use tabs or spaces to indent code? Actual indentation is chaotic.

We probably need a short dialog/ series of dialogs when the program is first launched in order to configure the installation directories for packages content, where you actually store your routes and trains, and so-on.

Required stuff:

• The dialog.
• Store somewhere whether the options have been set (New line in the options.cfg ? )
• What needs to go in the dialog? Installation directories are obvious, possibly language and simulation mode. A setting for resolution & 'best' medium and 'fastest' graphics performance also seems like quite a good idea for someting like this.

Legacy BVE Trains, had 640x480 to 1024x768 (bmp) textured Panels.

OpenBVE versions prior to 1.5.*, used to resize these panel textures, to the window size, even in the "Full Screen" view on higher resolution displays, so, this tiny panels from old trains have been resized to meet the screen size and no "transparent edges" were found around the control panel of the cockpit

However, I use a "homemade" train with a 1024 x 768 resolution panel base, but the 1.5 series of OpenBVE put the panel at the window center and the space around seems to be transparent from the driver's eye.

noTextureResize = false

1024x768 train panel / 1600x900 display:

Continued from Updated Build for Ubuntu & Further Development from @sladen's repo:

Daily auto-generated builds available from here as of now-
http://vps.bvecornwall.co.uk/OpenBVE/Builds/

On my son's computer (running Linux Mint 17.3 with Nvidia graphics - I think it's the nvidia-304 branch), OpenBVE-2016-03-07.tar.gz does not run correctly in full screen mode. I get a small windows top left of the screen with graphics, the other 70% of the screen is black. Trying to exit full-screen generates an error message which I shall post when I can get to his to his system. Windowed mode is working well.

Are there any logs that may be useful to you?

Also, one of the things that openBVE does not simulate is brake control systems in which the brakes be released fully pneumatically or electro-pneumatically based on the position of the brake handle.

On the NYC subway (and many other metros and commuter rail lines), there are two "release" positions on the brake handle, "running" release and "full" release. Running release is releasing the brakes with electrical synchronization, while full release is releasing the brakes fully pneumatically. In real life, train operators are encouraged to use the running release position, as a full release is slower (since it is fully pneumatic). At least on american equipment, the brake handle range is (Full release)-(running release)-(service brake range)-(emergency brake)

I am aware that this arrangement is present on many westinghouse and NYAB equipped cars throughout the Americas, as well as on equipment based on this technology in other countries (Moscow metro for example). Perhaps there should be an option in the train.dat file to provide this functionality. Both of these options exist as separate options already (Trains can be programmed to have either electrically synchronized braking, or pneumatically-synchronized braking, but not have an option for both that is dependent on brake handle position)

On certain Mono systems (OSX, and possibly Linux), it appears possible to run out of available memory.

Mono error log from OSX:
Unhandled Exception: OutOfMemoryException [ERROR] FATAL UNHANDLED EXCEPTION: System.OutOfMemoryException: Out of memory at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_gc_alloc_vector (intptr,intptr,intptr) at (wrapper alloc) System.Object:AllocVector (intptr,intptr) at OpenBve.Textures.LoadTexture (OpenBve.Texture handle, OpenGlTextureWrapMode wrap) <0xf49b790 + 0x0049b> in <filename unknown>:0 at OpenBve.Renderer.ShowObject (Int32 ObjectIndex, ObjectType Type) <0xf9e67e8 + 0x004b3> in <filename unknown>:0 at OpenBve.ObjectManager.UpdateVisibility (Double TrackPosition) <0xbbe38288 + 0x002ff> in <filename unknown>:0 at OpenBve.OpenBVEGame.OnRenderFrame (OpenTK.FrameEventArgs e) <0xd01f04a8 + 0x001eb> in <filename unknown>:0 at OpenTK.GameWindow.OnRenderFrameInternal (OpenTK.FrameEventArgs e) <0xd01f0460 + 0x00037> in <filename unknown>:0 at OpenTK.GameWindow.RaiseRenderFrame (Double elapsed, System.Double& timestamp) <0xd01f03a8 + 0x0003b> in <filename unknown>:0 at OpenTK.GameWindow.DispatchUpdateAndRenderFrame (System.Object sender, System.EventArgs e) <0xbbe3e960 + 0x001e3> in <filename unknown>:0 at OpenTK.GameWindow.Run (Double updates_per_second, Double frames_per_second) <0xab820c0 + 0x0027f> in <filename unknown>:0 at OpenTK.GameWindow.Run () <0xab82080 + 0x0001f> in <filename unknown>:0 at OpenBve.MainLoop.StartLoopEx (MainDialogResult result) <0x95acaf0 + 0x0054b> in <filename unknown>:0 at OpenBve.Program.Main (System.String[] args) <0x73de20 + 0x00ec7> in <filename unknown>:0

The sim is attempting to load a texture into memory, and the system fails to allocate any additional memory.

This commit unloads unused textures dynamically, but causes texture bugs:
8f9b44d

Work in progress......

At present, the Travis-CI builds have ~90 begin compiler warnings, which are mostly missing XML doc comments.

https://travis-ci.org/leezer3/OpenBVE/jobs/122372936

Fixing these is good manners if nothing else.
Have made a basic start here:
70e656c

WIP 👍

There are various small issues with plugins:

1. No centralised plugin repository (Many copies of plugins)
2. No mechanism to update problematic plugins
3. No mechanism to blacklist plugins (See above) DONE
4. No way to use anything other than the default ATS/ ATC if loading of a plugin fails.

This essentially requires a centralised storage and version management system for plugins.
It should also offer the ability to replace a Windows only plugin with a compatible cross-platform version if available (UKTrainsys for some UKDT / UKMU trains, BVEC_ATS for most OS_ATS based stuff)

#85

Cross posted from: http://bveworldwide.unlimitedboard.com/t1229p400-new-openbve-build-testers-please#14393

Heads up, the Mac download link for openBVE RC4 on http://openbve-project.net/ leads to a 404 error page.

Also, im getting this error when i try to make a package:

http://i.imgur.com/w56BoiR.png

Additionally, packages seem to be installing in the wrong place. Aren't they supposed to install to either the directory where one has previously been loading routes/trains from (for existing installations)? This directory is in a hidden folder and is different from the legacycontent directory inside of the .App.

http://i.imgur.com/mzX7dV1.png

Perhaps a solution to this issue would be to have separate "Content Packages" and "Manually added content" selection tabs on the "start new game" dialog.

Thanks for all your help!!

Animated objects can access the distance of the closest train carriage, using TrackDistance and TrackDistance[Car] for a specific train car.

Needs checking & clarifying in the documentation as to whether this counts AI PreTrains, or only refers to the player train.

It then should be separated into specific checks for the player train and PreTrains.
(This allows us to trigger per-train animations much better, and is a also going to be necessary if we want to implement proper trains running on secondary tracks)

The 'Compatibility' folder contains the default Japanese signals, catenary etc.
This currently isn't included in the source code management, and probably should be.

It may also be an idea to include BRSigs, BRSigs_Open etc. into the main source tree, as they'd then always be present in the default installation.

Under Linux and OSX, for OpenTK to work correctly, the file OpenTK.dll.configis required. The file is present in the Dependencies folder, but it is not deployed.

If I set interpolation to anisotropic in the options screen, I receive a GL_INVALID_VALUE exception as soon as the simulation starts (the first frame is shown, though). Note that it seems not possible to set the anisotropic level to anything but 0.

This happens with all the routes and all the trains I have tried (about 4/5 of each). All other interpolation settings work fine. As a reference, on my system, version 1.4.3 runs fine with anisotropic interpolation (level 16) on those same routes/trains.

OS: Linux Mint 17.3; graphic adapter: AMD/ATI Radeon HD 5770, driver xserver-xorg-video-ati version 1:7.3.0-1ubuntu3.1 (the latest and recommended driver for my distro).

This is the MonoDevelop debugger report:

• System.InvalidOperationException: MainLoop: GL_INVALID_VALUE
• at OpenBve.MainLoop.CheckForOpenGlError (System.String Location) [0x000dc] in /home/mmg/Documents/projects/openBVE/leezer3/openBVE/OpenBve/OldCode/MainLoop.cs:485
• at OpenBve.OpenBVEGame.OnRenderFrame (OpenTK.FrameEventArgs e) [0x0021b] in /home/mmg/Documents/projects/openBVE/leezer3/openBVE/OpenBve/OldCode/NewCode/GameWindow.cs:143
• at OpenTK.GameWindow.OnRenderFrameInternal (OpenTK.FrameEventArgs e) [0x00010] in :0
• at OpenTK.GameWindow.RaiseRenderFrame (Double elapsed, System.Double& timestamp) [0x0000c] in :0
• at OpenTK.GameWindow.DispatchUpdateAndRenderFrame (System.Object sender, System.EventArgs e) [0x000d5] in :0
• at OpenTK.GameWindow.Run (Double updates_per_second, Double frames_per_second) [0x000c6] in :0
• at OpenTK.GameWindow.Run () [0x00000] in :0
• at OpenBve.MainLoop.StartLoopEx (MainDialogResult result) [0x0021e] in /home/mmg/Documents/projects/openBVE/leezer3/openBVE/OpenBve/OldCode/MainLoop.cs:97
• at OpenBve.Program.Main (System.String[] args) [0x00605] in /home/mmg/Documents/projects/openBVE/leezer3/openBVE/OpenBve/System/Program.cs:230

If more data are needed, I assume I can provide them (with proper instructions?). Thanks!

This is not a bug report, but rather the start of a discussion about how to remove a little dev complication (if there is a better place for this kind of things, please tell me!).

A sort of a little conundrum here:

1. AssemblyInfo.tt relies on an existing AssemblyInfo.cs for the major and minor version numbers (and for the build number, but more about this later)
2. => AssemblyInfo.cs must be under version control (to make major and minor version numbers known)
3. It generates a new AssemblyInfo.cs each time it is run
4. => AssemblyInfo.cs is better left out of version control, or merge conflicts may arise.

(Note: I do have a merge conflict on each update I fetch from upstream, unless I remember to revert any local automatic changes to AssemblyInfo.cs before merging it; so the case is not purely hypothetical).

Is there a strong reason not to store the major and minor version numbers directly in AssemblyInfo.tt and get rid of its dependency upon AssemblyInfo.cs? This would allow to remove the latter from version control and avoid any merge conflict.

Agreed, this would not be a standard place to store source data for version numbers and would puzzle the 'casual developer' (like myself!). But, admittedly, changing the version number is not an operation for the 'casual developer', it is usually the domain of a project manager.

The only remaining point is the build number and the test AssemblyIfo.tt performs on the previous one to make sure it is not greater. It looks a wise thing to do, but is it really necessary? How probable is that the system clock of develoepr A and/or the system clock of developer B are so wildly off time that developer B fetches a commit from developer A to discover that it has been made tomorrow?

Whilst the main user interface components are translated, a lot of strings in the program are not fully translatable.

It's good manners to provide translations for everything wherever possible.

Custom speed units can now be set via Route.DisplaySpeed but these are not reflected in the review screen.

Requires changing.

The recent addition of the ability to display messages from train plugins offers a lot of potential. However, since that was implemented, I have been getting messages related to beacons on many routes, no matter which plugin is used at the time.

I am not sure whether this was intended or not, but I suppose probably not, since some routes make an extensive usage of beacons and the screen becomes quickly cluttered with messages.

Maybe this was supposed to get displayed in the debug (F10) screen and somehow managed to appear in the main screen?

In window mode (build 1.4.5.1429), working with the mousegrab camera control in window mode, with default window size, route Birmingham Cross-City South OpenBVE, train Class 323 unrefurb OpenBVE (3D cab). Right-click on the center of the speedo, the camera rotates right and down, so that the top of the horn lever comes into view. Check both cab door windows once. Check both cab door windows again, the motion range is no longer sufficient to get the right-hand side window completely into view. The third time it's no longer possible to view the offside window at all, only the driver's side. Restore the default view by eye, right-click to end the capture, and start again by right-clicking on the center of the speedo; the view now shifts to the power/brake handle.

The expectation is for the view to either remain still or center on the right-click point. Also the camera motions should be consistent and repeatable.

Sometime between 1.4.1 and 1.5.0.4 it has become possible for the train to arrive late at the first station along the line.

(Screenie: http://imgur.com/CjNhdOe )

Ultimately this is completely inconsequential, but I still thought I'd bring this to your attention. Thanks for the amazing work on the program btw!

When a single joystick is plugged in, it does appear in the controls configuration screen as number 1, but doesn't react to axis motions or button presses; therefore controls cannot be assigned to it. However, when controls.cfg is manually edited to include lines for joystick n, they appear as assignments for joystick number n+1.

See also #3

I have come up with a possible way of implementing consists using the current train format.

Currently the train format only allows to have a single consist per train. If we wanted to have different liveries of the same train, or double consists, for example, we would have to create a new train for each. Some developers have been using subfolders to group these consists (Chashinai Railway is the best example probably), but it is not the best solution,

The idea is quite simple. Using a new "consists.cfg" file placed in the train folder, we define the consists:

[Consist0]
Name = Default

[Consist1]
Name = Custom Consist 1
Folder = con1

etc.

Each [Consist] section defines a different consist. 'Name' defines a name for the consist (so it can be shown in a list in a new tab in the train selection menu, for example), and 'Folder' sets the consist subfolder relative to that train's folder. Each consist may have custom train files (Train.dat, extensions.cfg, etc), but it is not necessary to have all of them (in case there is no Train.dat in the subfolder, for instance, the default one in the 'root' folder is used). This keeps the new file simple yet powerful.

Backwards-compatibility should not be an issue, as old versions of the program would simply ignore the new file. [Consist0] would not have a 'Folder' setting because it would always use the standard files in the 'root' folder (so old versions openBVE just read it as a normal train). As far as routes are concerned, adding a new parameter to the Train.Folder command would be enough to tell the game if a custom consist is used. Say you want to use [Consist4] of the LT1995 train, for example. It would look like this:

Train.Folder(LT1995;4)

I have tested this in the current build of openBVE and the ';4' part is simply ignored with no warnings or errors, so a future implementation would be 100% painless.

I have some C# skills and I could even code this myself, but I want to know first if you think it is a good idea, or if there is any part of it that could be improved. Thank you!

I expect this suggestion to be frowned upon by the expert drivers! But nobody is born expert, and even the expert might stumble upon the route he is unfamiliar with...

While learning a yet unknown (to me) route, I often would like a kind of HUD with a number of info, clearly displayed and easy to spot, possibly not too far away from the track view. For instance:

• current speed (already there, but hard to read while keeping an eye on the track)
• current clock (same as above)
• current track / signal speed limit
• distance to next speed limit post (and maybe the limit itself)
• distance to next station (with name? with ETA?)
• distance to next non-green signal?

I understand that this would be a sort of 'gamification' of the simulator, but simulators running on PC lack a great part of the 'look and feel' of real-life operations (having spent twenty years in flight simulation, I am rather confident about this) and some 'bridge' might be useful while learning and/or could attract more users. Of course, nobody would be forced to use it!

At the same time, I propose to rename the "Arcade mode" into "Novice mode" (or whatever other English term seems suited to native English speakers), in which this HUD would be the default.

Comments? Indecent? Way off? Tolerable? Useful?

While developing a route with dark ambient and directional lights, I have discovered what looks like an unintended effect related to lights.

The commands .AmbientLight and .DirectionalLight affect how the world polygons are illuminated. Their behaviour is the same for BVE4/5 and OpenBVE. However, BVE4/5 and OpenBVE handle cab brightness differently. While BVE4/5 cabs are not affected by the world light (and thus it is possible to have a bright cab with a 0,0,0 ambient light), OpenBVE applies the world light to the cab too. In a route with a 0,0,0 ambient light, this makes the cab always dark (even if the brightness is set to 255). Exterior views are affected too, as they are linked to the cab.

I guess this may be a side effect of exterior views. They look natural when affected by the world light, but back when the feature was added probably nobody thought that they were linked to cabs (most routes are outdoors and daytime and the effect becomes invisible). Odakyufan had problems with this too in the nighttime routes of Chashinai Railway, and tricked OpenBVE by calculating brightness values according to the ambient light (more details here: [http://web.archive.org/web/20111128233147/http://odakyufan.zxq.net/tips.html#tunnelsandcabbrightness] ). Obviously this is not the ideal solution, as this only hides the side effect in a very limited way.

The solution would be to have cabs and exterior views affected by the world light, but override it a similar way to how SetEmissiveColor color works. At 255 the cab/exterior would not be affected at all by the world light, and at 0 the cab/exterior would be fully affected.