openBVE 1.5.0 RC1 - BUGS

Please post any bugs found in the 1.5.0 RC1 version here.....

It is not exactly a bug, but there are around 30 strings that are not translated due to them being hardcoded in English into the program.

I have already made the changes to the code to fix it, but I will create the pull request after adding the extra strings to each language file.

Regards,

Marc

Marc Riera wrote:It is not exactly a bug, but there are around 30 strings that are not translated due to them being hardcoded in English into the program.

I have already made the changes to the code to fix it, but I will create the pull request after adding the extra strings to each language file.

Regards,

Marc

Much appreciated.

It's actually a real pain that VS doesn't really have any automatic way to assign translations to strings.
You can use resource files, but that doesn't allow users to edit them without technical knowledge, and they require the whole thing recompiling which isn't great.....

Cheers

Finished, check GitHub for the pull request. In the end it was not as tedious as I thought it would be, but I agree VS should have better support for localization. I once used resource files for a small program and it was awful. If I ever start making a another program, I am sure I will not be using those.

Regards,

Hi,
when I launch this RC version, the following error appears: "an error occurred whilst attempting to load the default language file".

Could you explain how I can solve this problem?
Thank you in advance.

Hi,
I don't know if it's only me, but when I go create a package replacing the only one I have installed, it errors out with "Unhandled Windows Forms Exception" and then closes.
Running it on Mono Runtime 3.0 in Xubuntu 16.04.
Thank you for your time.

Glory! koshikii wrote:Hi,
I don't know if it's only me, but when I go create a package replacing the only one I have installed, it errors out with "Unhandled Windows Forms Exception" and then closes.
Running it on Mono Runtime 3.0 in Xubuntu 16.04.
Thank you for your time.

Packages haven't been tested as much on Linux though, so I'd suspect a platform specific bug.
I've definitely managed to create replacement packages on Windows, and this would appear to be working at the moment.

You should also be able to use the 'Report Problem' link in the bottom left to view/ save the most recent crash log. This might be interesting
The package type would also be helpful.

Edit:
I've found and fixed the probable cause.
I've also fixed a couple more minor issues. I'm still looking for issues, so will post another RC in a couple of days.

All current changes from the RC branch have also been merged back into the master development branch, so it should generate a new nightly build shortly, which will hopefully fix this issue.

Cheers

fas wrote:Hi,
when I launch this RC version, the following error appears: "an error occurred whilst attempting to load the default language file".

Could you explain how I can solve this problem?
Thank you in advance.

This means it either can't find the Data\Languages folder, or an exception was caught whilst trying to load the languages.
Not sure what's going on here though, as this looks and works OK at this end

Deleting the file C:\Users\**YOU**\Roaming\openBVE\Settings may help.
I'll have to try some testing and see if I can get this reproduced.

I have followed your instructions and now it works! Thank you.

I get an "Unhandled Windows Forms Error" when I click the website link of the Yuriya Railway 110 Type Train package (https://1drv.ms/u/s!AqFam7y5UM4sg1pRP3VLtfEUl4rV). I have clicked on the link before installing the package. Other packages may be affected too.

Regards

Marc Riera wrote:I get an "Unhandled Windows Forms Error" when I click the website link of the Yuriya Railway 110 Type Train package (https://1drv.ms/u/s!AqFam7y5UM4sg1pRP3VLtfEUl4rV). I have clicked on the link before installing the package. Other packages may be affected too.

Regards

Fixed, plus added a little more validation in there (It wasn't automatically being recognised as a URL due to the missing http:// )

A check that the URL exists would also be nice, but probably overkill.....

Have posted RC4 with the following fixes:

• Selecting package dependancies could crash in some cases.
  
• It was possible to get the installer stuck in an unresolved state when a version conflict occured.
  
• The bug report dialog wasn't working properly on Linux due to path issues.
  
• Package websites missing the http:// would cause a crash when clicked on.
  

(Mac build will be up as soon as TravisCI builds it, Windows and tar.gz builds are already there)

Cheers

I have found two additional bugs (both related to new features added recently).

The first one is just a minor bug in the route preprocessor. The command .Route.LoadingScreen is recognised by the parser and works as expected, but it has not been added to the preprocessor. The warning/error system uses the preprocessor to output messages, so a false warning appears when loading a route with the command.

The other bug is unfortunately more serious. There is something wrong going on with the Package Management section, specially when using dependancies (have not tested recommendations). I found this out while trying to create packages for two trains and a route using them, so I will use those three as an example.

I created the trains first (no dependancies required for them), and found no problems. I tried installing and uninstalling them and everything works fine. I noticed, however, that the internal XML file in both packages had two blank tags (here is the interesting part of the file):

Code:

<package>
   [...]
   <PackageVersion>1.2.0.0</PackageVersion>
   <MinimumVersion />
   <MaximumVersion />
</package>

Why are there tags related to dependancies in the package? Even if the tags are blank, they should not be there, as it makes no sense for a package to define the max and min versions for itself.

I did not give importance to those tags, and decided to create the package for the route. I set the two previous packages as dependancies, and in the version prompt I wrote 2.0.0.0 in the upper box and 1.0.0.0 in the lower box. The package builds fine, but exploring the internal XML I discover more interesting things:

Code:

<Dependancies>
   <Package>
     [...]
     <PackageVersion>1.2.0.0</PackageVersion>
     <MinimumVersion>2.0.0.0</MinimumVersion>
     <MaximumVersion>1.0.0.0</MaximumVersion>
   </Package>
</Dependancies>

The max and min version values have been switched over, and a "package version" equal to the then installed version of that dependancy has been recorded too (again, it does not make sense to store this). Obviously, it was impossible to install this new route package without overriding the dependancies, so I manually changed the version requirements to what they should have been. Not enough to make it work, OpenBVE again asks for dependancies.

Finally, I decided to update one of the train packages. Same as before, no dependancies, but remember the blank tags? This time they had numbers in them, and they were the same I had previously selected for the route package. Maybe some internal values in OpenBVE are not correctly cleared after a package is installed/created? I gave up after this.

I do not want to sound catastrophic, but something is very broken here. You have worked very hard on this alone and I admire you, Chris, but I think a decent package management system is too much work for a single person. The package management UI is sometimes a bit buggy too (from my experience when translating it) and needs intense work. It may sound crazy, but I will try to tidy both the UI and the code. OpenBVE is a great project and I want to contribute with my knowledge. Together we can make it even better!

Having said all this, even if the bug is huge, I am sure we will manage to get a very decent stable build (maybe the most stable OpenBVE ever, haha).

Regards

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

Also, I'm getting this error when I try to make a package:



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 legacy content directory inside of the .App.



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

Thanks for all your help!!

Dj Hammers-
TravisCI kicked hard, and we now have a Mac build
Where to store the package files is actually a big question mark.
I've made some comments on your Github bug report, but my basic thoughts on the matter are that at least for the moment, files installed by a package and hand-installed files should be separate, not least because this isn't stable at the minute!

Marc-
Most of what you're seeing is because the XML is being auto-generated. They *should* be harmless. (Famous last words!)

In a root package, the MinimumVersion and MaximumVersion tags should always be ignored if present.
In a dependancy or reccomendation, the MinimumVersion and MaximumVersion tags are used, and the PackageVersion tags are ignored.

Whilst it's rather long to explain, if you serialize a class to XML using the default serializer, *all* members contained within it will always be written.
There are some hacky ways around it, but I'd rather leave that sort of thing until this is stable.....


However, I've fixed/ improved some stuff based upon your post:

• The minimum and maximum versions for dependencies had got reversed.
  
• Reccomendations weren't being checked at all.
  
• Added labels to the version window for dependencies and recommendations.
  
• The PackageVersion is not stored in a dependancy (Cosmetic, but still.....)
  

Note:
No new version just yet, please build from the Release branch if you require one.
I need to do some testing on Mac, and I get the nasty suspicion there's a threading issue somewhere I haven't caught.....

Cheers

Hi Chris, Having loaded the new version i get the following messages......errors_controls_oldversion...and errors_controls_reset...tried removing all of the old versions of obve, incedentally the window containing this message is only removable by device manager/exit...regards

mobile1 wrote:Hi Chris, Having loaded the new version i get the following messages......errors_controls_oldversion...and errors_controls_reset...tried removing all of the old versions of obve, incedentally the window containing this message is only removable by device manager/exit...regards

Looks like it's trying to load it's datafiles from an old (Non-existant) openBVE folder.
The error messages should just say that the controls.cfg file is in an older format, and hence the control confguration has been reset to default

You need to delete the file C:\Users\YOU\AppData\openBVE\Filesystem.cfg and it should sort itself out.

This is on my list of things to try and sort out properly, as it's not really user friendly at the minute.

Definitely not a bug, just a thought: wouldn't the original OpenBVE logo (the one in OpenBVE 1.4.3) look better in the OpenBVE window? The one in the RC has antialiasing problems and just doesn't feel as professional as the original one.

Again, not a bug, just cosmetics that I bumped into while working on the Hungarian translation (also see image).

1. On the Options page the Other section does not align with the other option boxes above it. (screenshot 1, #1)

2. Also on the Options page Timetable mode misses a colon. All other options have a colon, but not Timetable mode. Also, Timetable mode should be right aligned, but is not properly aligned with the options above it. One more thing here: the timetable mode dropdown could use a bit more padding at the bottom, the bottom of the box is too close to it compared to the top and other boxes above. (screenshot 1, #2)

3. I can't seem to be able to translate Unload unused textures into Hungarian so that it fit in the space provided. Can you possibly move it to the bottom (if there is enough space) or move the whole Advanced options section to Options page 2 to provide more space? (screenshot 1, #3)

4. The package management progress dialogue looks a bit out of place, well, at least, doesn't really fit the UI and is a bit misaligned, the letters are too big and most file names don't fit in the window. It might be worth considering to make it look more like other text elements in the UI and use nicer alignment. (screenshot 2)

Chris, these are just minor things and you are doing a great job!

I just made myself chuckle when I realised from the screenshot above that the Hungarian for Hungarian isn't actually Hungarian!

A lot gets lost in translation!!   Interesting things, languages.

My main PC went tits up last week (RIP) and I have a new machine running Win7 Pro 64bit. I've installed the 1.5.0.6 program files and it mostly seems to work fine. However, I found it crashed under the following circumstances, with

Unhandled Exception:
InvalidArgument=Value of '0' is not valid for 'index'
Parameter name: index

Route: Waterville to Knockmore 7B.csv
Train: (default in routefile) 2700.2_hi-res

When the default train was selected the route and train loaded and performed properly.
When an alternative train was chosen manually in the startup box (29000IE) the program crashed with above error message.

Same thing happened with Kilmagranny route when trying to choose a different train from the route default.

Hmm, they both work here....

I've fixed/ worked around several bugs in the BVE2/4 routefile parser over the last few days, but nothing that should affect that.

Can you try it again and let me have the crash log please? (Bottom left of the main screen- Report Problem)
That tells me exactly where it's crashed, which from that error could be just about anywhere

Sent via the report probs button
Its a new machine with a clean installation. I also have v1.4.3.0 available and that did load routes with alternative train to default. Too complicated for me, you're doing a great job, Chris !!

graymac wrote:Sent via the report probs button
Its a new machine with a clean installation. I also have v1.4.3.0 available and that did load routes with alternative train to default. Too complicated for me, you're doing a great job, Chris !!

Small note:
It doesn't send directly, but *should* create a ZIP file on your desktop containing the logs etc.


(Sending directly means all sorts of trouble with firewalls and so-on....)