Linux openbve invisible signal problem [solved?]

View previous topic View next topic Go down

Linux openbve invisible signal problem [solved?]

Post by MadMartian on Tue May 19, 2015 6:21 am

Hello,

I'm a long-time lurker in various BVE and OpenBVE forums.  I'm also a long time Linux user who used OpenBVE for a long time before realizing that I wasn't seeing signals on most of the downloaded routes. How was I to know what I wasn't seeing?  It took a few times getting "You have passed a red signal..." before I was convinced that it wasn't just me not seeing something.

See also these very old threads in this forum that only partially explained possible solutions:

OpenBVE signal problem
Signals not visible? My experiment.

[I didn't want to necro ancient threads, but I did want to get a solution posted somewhere close to them.]

I've just recently confirmed a solution and have a little theory as to the cause of the problem.

My symptoms: The default Japanese signals built-in to OpenBVE worked on any route that used them.  And signals using animated objects also worked. Only signals loaded with "Signal(SignalIndex).Load SignalFileWithoutExtension; GlowFileWithoutExtension" were not loading.

I dug through the source for 1.4.3.0 and noticed that each of these three types of signals [built-in, animated and SignalFileWithoutExtension] are loaded with different code.

I was contemplating a solution like that suggested in the second thread above, replacing SignalFileWithoutExtension signals with animated signals where I could find similar animated signals, but I was having no luck making my own animated signals.

Then I stumbled across one route that had SignalFileWithoutExtension signals that were working.  So now I knew that Linux OpenBVE can load some of that type of signal.

After some testing, I came to my final answer, which was suggested but not confirmed in the first thread above. I am theorizing that the code used to load SignalFileWithoutExtension signals is not properly case insensitive and is also sensitive to backward versus forward slashes.

I never really suspected that because the vast majority of the objects listed in route files were being found and loaded just fine despite many differences in case and slashes shown in the route files and in the filesystem on disk.  Only signal files and in fact only SignalFileWithoutExtension type cared about case and slashes.

Using the same Birmingham Cross City South route as the second thread above as my own test case, I got the existing signals to work by changing "\" to "/" and making sure that the path names matched the case used in the Object folder for this route.  Both case and slashes had to be changed to work.

So I changed this:
Code:
Signal(4).Load Bham_X-City_South\BrSigs\night\signal4yg; Bham_X-City_South\BrSigs\night\glow4yg

to this:
Code:
Signal(4).Load Bham_X-City_South/BrSigs/Night/signal4yg; Bham_X-City_South/BrSigs/Night/glow4yg


I have found that the filename itself does not appear to be case sensitive.  In other words, "signal4yg.x" doesn't need to match case, but the folder path "Bham_X-City_South/BrSigs/Night/" has to be exact to work.  In fact, the texture files, like "Signal4yg0.bmp" and "signal4YG4.bmp" don't even need to match each other's case.  Which is good because I have seen cases where one or more of the texture filenames do have different case in the object folders.  The Cross City South BrSigs files are pretty uniform, but even there the "Signal2gy.x" file is different from its textures, "signal2gy0.bmp".

I used this to get signals on 3 or 4 route files in addition to modifying all of the route files in Cross City South, so I'm starting to be fairly confident that it is going to work consistently.

I have only tested this on Ubuntu 14.04 LTS, but I suspect that it would fix this same problem on MacOS if it is happening there.

I still have to edit downloaded route files to make signals work, but this is a lot easier than finding or creating an animated equivalent for the large variety of .x, .csv, and .b3d signals.

MadMartian

MadMartian

Posts : 3
Join date : 2015-05-19

Back to top Go down

Re: Linux openbve invisible signal problem [solved?]

Post by Locomotion on Thu May 28, 2015 10:35 pm

Thanks for posting this and doing the research. I'd noticed the same problem. I'm running Linux Mint (which is based on Ubuntu), just needed to change the \ for a / and now the signals are visible!

Odd that all the other file paths seem to work fine with \, just the signal files...

Very Happy

Locomotion

Posts : 15
Join date : 2015-05-28

Back to top Go down

Re: Linux openbve invisible signal problem [solved?]

Post by MadMartian on Fri May 29, 2015 5:43 am

I did a little further digging on the cause.

The code which loads SignalFileWithoutExtension signals is the only place in SourceCode/openBVE/OpenBve/OldParsers/CsvRwRouteParser.cs which uses direct calls to System.IO.Path.Combine

The rest of the route parser code uses a wrapped call from SourceCode/openBVE/OpenBveApi/Path.cs, either OpenBveApi.Path.CombineDirectory or OpenBveApi.Path.CombineFile.  Both of these wrapped functions handle "/" and "\" for path separators and try to use case insensitive access.

I wish I had a .Net/Mono build system ready on Ubuntu to try patching this in the source to openbve.

MadMartian

MadMartian

Posts : 3
Join date : 2015-05-19

Back to top Go down

Re: Linux openbve invisible signal problem [solved?]

Post by jsiren on Thu Jul 23, 2015 11:46 pm

Thanks for the debugging, I'll have to try this myself!

jsiren

Posts : 106
Join date : 2012-09-16

Back to top Go down

Re: Linux openbve invisible signal problem [solved?]

Post by Sponsored content


Sponsored content


Back to top Go down

View previous topic View next topic Back to top


 
Permissions in this forum:
You cannot reply to topics in this forum