openBVE 1.5.0 RC1 - BUGS

Fixed....

I don't think there are any more of these hanging around, but let me know if you spot one.

(TLDR: Michelle was using a horrible hack to get the blue backgrounds. This broke when I actually fixed blue to be a valid color. )

Just noticed a weird thing. For some reason the "southern region fictional route" (http://www.trainsimstuff.org/other-downloads/older-routes) runs at 12fps even with the most basic train I have (no exterior and plugin) and that's a BVE2 era route...

Interesting.

I can see an insanely long load time, but my FPS are OK.

Something seems to be making our start time a massive negative value somehow, and everything throws a complete hissy fit from there.

Will look into it.

Edit:
It's the RunInterval value causing this. This is set to 90000, which equates to over 24 hours before your train, which the sim then simulates (This ought to be faster, but I'm not digging into that just at the minute.....)
Will add a hack to fix this, 24+ hours is not a clever value for a pretrain

https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-20.zip

That now loads at a sensible speed for me, assuming hacks are enabled. I think it'll probably fix your FPS issues too.

Just recently I have been having an issue loading my unreleased WIP route in the last few nightly builds. I have been working on an object which I did temporarily disabled to see if that was cause but the problem still occurs. I tried loading my route three times and crashed each time. Since this issue started I have not used any other routes so I not sure if something with my route but has only started happening recently. I do have some issues with my machine being a bit sluggish and seems to cause some stuttering in the sim. The crash occurs towards the end of the loading when it reach 100% and crashes with 3 errors messages of:

First message:

Code:


The route and train loader encountered the following critical error: Index was outside the bounds of the array.

Second message:

Code:

Unhandled exception:

Cannot load Counter Name data because an invalid index " was read from the registry.

Third message:

Code:


A fatal exception occurred inside the UnhandledExceptionHandler:

The process cannot access the file 'C:\Users\XXXX\AppData\Roaming\openBVE Crash-2017.8.1[13.33]log' because it is being used by another process.

Crash log of second attempt which looks the same as first and third attempt:

Code:

21/08/2017 1:30:47 PM
OpenBVE 1.5.570.1111-travis Crash Log
Program is running on the Windows backend
Current screen resolution is: Windowed 960px X 600px
Current routefile is: C:\openbve\openbve Route and Train Content\Railway\Route\Brisbane Railway Network\[EMU,SMU,IMU] 07.55 Ferny Grove to Roma Street all stations [Ferny Grove to Groverly].csv
Current train is: C:\openbve\openbve Route and Train Content\Train\Test EMU 6 car
Current train plugin is: UKMUt.dll
The current routefile caused the following exception:
System.IndexOutOfRangeException: Index was outside the bounds of the array.
   at OpenBve.PluginManager.Plugin.UpdatePlugin()
   at OpenBve.TrainManager.UpdateSafetySystem(Train Train)
   at OpenBve.TrainManager.UpdateTrainPhysicsAndControls(Train Train, Double TimeElapsed)
   at OpenBve.TrainManager.UpdateTrain(Train Train, Double TimeElapsed)
   at OpenBve.TrainManager.UpdateTrains(Double TimeElapsed)
   at OpenBve.OpenBVEGame.SetupSimulation()
   at OpenBve.OpenBVEGame.LoadingScr

Any ideas?

That strongly sounds as if something has gone wrong with the train, but it must be being triggered by something.
The crash is happening as the sim tries to move the AI trains into position (It essentially just 'runs' them with no graphics)

There were a couple of changes to the exterior load to fix a bug with bogies, but that's all I can immediately think of that should have had an effect.

First try another train, and see if that works OK.
If that crashes as well, can you drop me a PM with the route / train combo uploaded somewhere?
It's much easier to find these things with the crashing combo to test in the debugger.

Cheers

The train in the crash is the Class 323 but with some train.dat and extension.cfg modifications. I tried the cl 158 + Cl 143 Arriva Trains Wales and your Class 52 and both crashed when used on my route.

Trying both on your Cornwall route worked and several other routes didn't give a crash but using both of these trains on Kilmagranny (older version) 0900 route did result in a crash. While I don't really want to share my unfinished route at the moment I will wait to see if you get that crash on Kilmagranny before I PM my route.

Thanks.

Hmm, that indicates it's likely somewhere in the train code rather than the route code

I can't reproduce on Kilmagranny, so this smells timing / FPS related.
Let me do some digging in the train update function before you send me anything, as I strongly suspect that this won't reproduce at my end

Edit:
This build will (probably) not crash-
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-21.zip

It doesn't really get to the bottom of why though, just adds a check in the most likely cause of the symptoms you're experiencing.
Will do some more testing

You know more about this but I would have thought it would be route related because this didn't happen to many routes (but I only tried half a dozen routes) but happened to every train I tried on Kilmagranny and my WIP route. However trying the few pre OpenBVE trains I have the aussie Class 30 didn't crash but the the NSWGR Class 46 did crash.

Trying your latest build still gives the crash on my route but feels to take a bit longer to load.

MattD6R wrote:You know more about this but I would have thought it would be route related because this didn't happen to many routes (but I only tried half a dozen routes) but happened to every train I tried on Kilmagranny and my WIP route. However trying the few pre OpenBVE trains I have the aussie Class 30 didn't crash but the the NSWGR Class 46 did crash.

Trying your latest build still gives the crash on my route but feels to take a bit longer to load.

That's very odd then...

From looking at the function, the most obvious cause of trouble would seem to be an AI train, which is either disposed by a secondary thread or hasn't yet had it's position assigned, but that doesn't seem to be the case, as you're still crashing.
Shouldn't be any noticable increase in load times at all (In the single digit number of milliseconds at most), I think that's just the placebo effect.

Some digest on your messages:
#1: This is the actual crash- Something within the following function https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/OldCode/PluginManager.cs#L63 is attempting to access an array index which doesn't exist.
#2: Essentially irrelevant. When the crash log is written, I attempt to get system info (free memory etc.), and this is failing. Not sure why, but it's nothing much to do with the issue at hand.
Log:  This just tracks back what actually called the error in question. The top line is the error itself, followed by the path it took to get here: Something in the UpdatePlugin function crashed as it tried to read outside the bounds of an array, which was called by the initial loop from the loadingscreen which moves the AI / player trains into position for the start of the sim.

Build has been updated again, with a couple more checks, please let me know if that helps:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-21.zip

OK, now I've found the issue
(KMG original crashes, KMG2016 doesn't, hadn't noticed that....)

https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-21.zip

Will be updated in 5 mins or so once Travis has built.

Attempt #3 at fixing this should now hopefully work OK.

Will leave the other two potentials in there though, as otherwise something there will inevitably come back and bite me.....

Thanks for explaining that. The updated build doesn't work on my WIP route for my modified Class 323, your Class 52 and the previously mentioned Cl158 but doesn't crash with Cl158 2 car East Midlands or Class 323 3 car refurb London Midland. This seems strange but I tried each of the above trains several times to make sure it's not random with the same results every time.

And trying your latest build I still get the same results on my WIP but no crashes anymore on Kilmagranny. On my route I have Route.RunInterval  of 150 if that makes any difference.

Hmm....

Does the build from the 17th crash:
https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-17.zip

The bug above was caused by an addition to the build on the 18th, which adds the distance to the station stop position (as opposed to the station start) to the API lacking a check to see if the station had *any* defined stop points.

If this build doesn't crash, it's related to the way your .Stop commands have been setup with relation to the number of cars in the train somehow, but I can't currently see how
(D1015 has 12 cars, the 158 assuming it's the one I think has 4, and your other two have 2 /3, so presumably trains with over 4 cars crash....)

The build from the 17th doesn't crash on my route using the Cl158 +Cl143 4 car and my modified Class 323 which is 6 car. My stations are based on 3 car and 6 car stops and as far as I can see I have done this right with the stops being where I want them.

If it's any help this is my route code (which contains all the stop points for the route):

Code:

$Include(FG_PT2_to_end.csv),
With Options
.ObjectVisibility 1,
.FogBehavior 1,
With Route
.Comment BRN 07:55 Ferny Grove to Roma Street all stations.
.Timetable BRN 07:55 Ferny Grove to Roma Street all stations. Max Speed 100km/hr.
.Change 1,
.Gauge 1067,
.Signal(2) 120,
.Signal(3) 140,
.Signal(4) 160,
.RunInterval 150,
.Elevation 57,
;.AmbientLight 255;255;255,
;.DirectionalLight 255;250;240,
;.LightDirection 20;180,
.DynamicLight(DynamicLight.xml),
With Train
.Folder Test EMU 6 car,
.Run(1).Set 2,
.Gauge 1067,


With Texture
.Background (0).Load BRN\Common\background_1.png,
.Background (1).Load BRN\Common\background.xml,
.Background (0).X 5,
.Background (1).Aspect 0,

signal(1).Load BRN\Signals\QldSigs_open\3AspectLed_FeatherL.animated
signal(2).Load BRN\Signals\QldSigs_open\3AspectLed.animated
signal(3).Load BRN\Signals\QldSigs_open\station_repeater_left.animated
signal(4).Load BRN\Signals\QldSigs_open\3AspectLed_approach_control.animated
signal(5).Load BRN\Signals\QldSigs_open\3AspectLed_forced_yellow.animated

With Track
400,.Sta Ferny Grove;07.5430;07.5500;;-1;1;;;20;30;;,
496,.Stop ;;;3,
570,.Stop ;;;6,
3027,.Sta Keperra;S:7.5915;07.5945;;1;0;;;20;35;;;
3169,.Stop ;;;3,
3180,.Stop ;;;6,

3806,.Sta Groverly;S:08.0115;08.0145;;-1;;;;20;45;;;
3962,.Stop ;;;6,

Thanks.

Ouch, terminally stupid bug on my part (The station stop point function uses an index not a reference to the station, and that was getting hooked from the train's current station....)

https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2017-08-22.zip

Now should be working as designed.

Brilliant, works correctly with no crashes. Thanks for looking at this. Btw I have been noticing a minor issue when the OpenBVE icon for the program in the taskbar doesn't display. Instead the icon is just blank with just the solid colour. It only sometimes happens but might be something caused by my machine.

No idea on that one I'm afraid, but it sounds like a Windows bug.

I can certainly see reports of it happening on Windows 10 (Not touching that awful mess....) for all sorts of stuff, and all I do is set the icon via a Windows API call on startup.

Thanks anyway but certainly some unusual things do happen in Windows 10. I am certain the stuttering in the sim is caused by Windows and/or the programs and the like I have and/or windows has installed or causing issues. I have added a new user to the machine as a test and when running OpenBVE under this clean slate the sim didn't stutter at all. However I don't get any of this trouble using 1.4.3 version of the sim.

I'm not sure it should be posted here, but anyway. These objects http://www.veb-verkehr.de/betrieb/down/U-Bahn_Berlin-Obj-D_v201.l3dpack don't load in Object Viewer, does BVE support .l3dgrp files for now?

Btw, the start time fix has helped, thanks!

Hmm, those are slightly interesting.....

We've got multiple layers of .ls3dgrp files, which the current parser doesn't handle too well by the looks of things.
I think there's probably some referencing to the base Loksim3D object pack in there too, but I need to do some proper digging to see what exactly is missing on the main box.

Might be Monday or Tuesday before I can do any proper digging, but I'm looking into it.

Edit:
OK, problem largely solved
I've still got some misplaced doors on these, which makes me think that the rotation is not passing down through the nested stack correctly somewhere. (The alternative is that the rotation is passed when it's not supposed to be)

Need to get a look at these in the editor tools on my main PC really.

Keep an eye on this PR though, and hopefully will get into the main builds next week: https://github.com/leezer3/OpenBVE/pull/184

Oddly enough, the VT98 object you've demonstrated in the video doesn't load correctly either and loading time (3 car VT98 set + old simple route in RW format) is super long. So it's not only the problem of the D-train complexity.

Link to the route please?


That smells related to the Blighton- Treston Park issues rather than the train.
Possibly a combination of the two.

I can get a 3-car VT98 running on the Plymouth Route without too many issues. (FPS drops yes, but nothing I wouldn't expect)

leezer3 wrote:Link to the route please?


That smells related to the Blighton- Treston Park issues rather than the train.
Possibly a combination of the two.

I can get a 3-car VT98 running on the Plymouth Route without too many issues. (FPS drops yes, but nothing I wouldn't expect)

It's "Egipte" from http://www.casacota.cat/8/simulador/bve/bve.htm
I often use it for testing trains, it's small and has little tight curves 

Also, thanks for the fixes, I'll test that

That route and a quickly hacked together 3-car VT98 seems just fine here, nothing at all out of the ordinary I can see in the load times.

To do this, I just copied the VT95-98 folder unchanged into the train folder, and left the default Loksim install in the default location (C:\Users\Public)
The only potential issue I can see is if you've only copied the .l3dgrp file into the train folder, and it's attempting to search for the Loksim folder every time it attempts to load a .l3dobj file.

I'll try checking the loksim install, it's in the default location for me (but it selects C:\Users\ when installing the latest version), but I'll double-check it.

Why does the parser need the loksim folder? I think it'd make more sense if it only checked the train folder. 

Edit:
The loksim folder is in C:\Users\Public\Documents\, still model not displayed... will try C:\Users\Public\

Also, the z-sorting issue you've mentioned on github has been present since (at least) 1.4.3, I remember getting it with .x files and complex .csv sometimes, but only in the viewer. It looked fine in the sim. Will find and pack examples shortly

The z-sorting issue is a little odd, but whether I chase it too hard I don't know, as I get the nasty suspicion that it'd involve re-writing the entire renderer (Object Viewer and Route Viewer use a lot of hacks and simplifications compared to the main sim...)

It's definitely only in the viewer, and on faces which use transparencies (These are internally converted to alpha channels)

Other than that, the branch in question at least loads the offending objects now, albeit with a few glitches.

• I can't currently explain why some bits are 'missing' , such as about half the doors (Related to the below I'm sure....)
  
• These use nested visibility options, which isn't currently supported, hence the mess on the doors which are visible.
  

A major problem with complex Loksim3D objects is the visibility system & the show/ hide functions, as this allows developers to in effect attach any custom target to the train. I'm essentially just handling each completely broken case internally as I find it, which isn't really the best method in the world, but there we go

Exactly how far this support ends up going I'm not sure.