openBVE 1.5.0 RC1 - BUGS

If I open package.xml in Gedit, it shows this character, not the "ő".

Has \r\n been used only for the last 1-2 weeks? Were new lines created without it before?

phontanka wrote:If I open package.xml in Gedit, it shows this character, not the "ő".

Has \r\n been used only for the last 1-2 weeks? Were new lines created without it before?

\r\n should have been there from the beginning.

I'll take a proper look at what's happening with your accented character tomorrow or Mon, but Mono appears to be a little buggy with very odd unicode strings.

Not sure if it's fixable until I've had a fiddle; I know this sounds like a very stupid question, but exactly how 'important' is the accent?
I know that these can change the meaning of some words in certain languages, but I know nothing about Hungarian....
(If all else fails, blacklisting broken characters is a horrendous hack of a solution...)

OK, have worked around it. Today's daily build should now work with your characters.

Not a particularly nice hack, but this looks to have affected Asian language characters under Mono too so should be worthwhile

I went over to Windows 10 to create packages, but I'll test it on Ubuntu as soon as I can. On Windows there are no problems. By the way, all the routes on BVE Klub are now openBVE packages (the trains are on my to do list). An awesome feature of the sim.

MattD6R wrote:Unselecting "Load in Advance" does reduce the issue but does still happen to a lower extent. I will give it some more testing later to make sure. I gave it go with the class 25 on Cheltenham and it was 15 seconds late the first time with a derailed route interval train. On subsequent loads it was only 1 second late every time with no derailing. Similar with the HST on your route though I didn't check for the derailed train but arrived 30 seconds late and around 10 seconds on subsequent loads. Also late on my WIP route by the same amount as it was previously which was 4 seconds late but on subsequent loads it arrived 2 seconds after the expected time but no message for that as that might not be late.

OK, I've found a combination which actually produces the late arrival on this machine.

I think the current daily build (27th December) should now have this issue solved, but would appreciate you testing, as I've only found one combination, and that's 2s late on the first load only, which makes it rather hard to test reliably!

I been meaning to report what I have found as I haven't much time lately for anything Openbve related. I changed/did a few things and the machine runs as best I can get it. I found that CPU and memory usage was quite modest also when running routes without any other processes using excessive resources.

I also updated the graphics drivers which made no difference both thorough the graphics control panel and Device Manager. I only updated the driver for the Intel graphics through Device Manager as it an manufacturer custom driver for this machine. I don't get any of these issues using 1.4.3 or 1.4.3a. When I loaded one of your early builds I do get that slight stuttering but not the lateness.

Your current builds does seem to have mostly sorted the late arrival issue. On some loads it is a second or two late but only on the first load. I also couldn't get the derailing to happen so that might also be solved but I will double check that to make sure. The slight stuttering I am still getting and it is only minor but I don't get that on 1.4.3. That might just be something strange with Windows 10. Thanks for looking into this and your work on the program. 

Short answer as to why the early builds work OK, is that I've been gradually replacing much of the internal plumbing over the last 18 months.
Michelle's last builds worked just fine most of the time, but had a lot of very obscure bugs, and absolutely atrocious code structuring.

Absolutely brilliant programmer, but unfortunately too much stuff lived within her head and wasn't documented.
I'm slowly changing that, and re-writing to 'proper' programming conventions, but sometimes we run up against odd issues


Whilst it's not visible to the end-user, in the long run things should be much improved.

Not sure about stuttering, I can't reproduce anything except in areas I know about already from 1.4.3. (Laira depot and various places on First Brno Track)

Thanks for explaining that. The stuttering is very slight and is not like the stuttering that you get when you have excessive objects that have to be loaded. It happens on any route and doesn't have to be highly detailed for it to happen. It is a regular (around every 2 to 3 seconds) very slight stutter that mainly visible at low speed. Occasionally there is also brief more major stuttering.

Sir Chris Lees
I do find your openBVE version latest of 4 January does operate well,
with 2 trivial errors that do not interfer, unless when
click on the programs "Report Problem" or "About" hyperlink
have the error "Unhandled Windows Form Exception"
and the programs then crashing to a close.

Good day and night for you
Hijau

Fixed for the 7th of January build, my apologies- Very specific bug concerning auto-generated builds only, hence why I hadn't seen it.

My apologies

(Some upgrades & improvements were made to the build system at the end of December)

Cheers

Sir Chris Lees
Your openBVE version latest 7 January does operate well
and the 2 trivial errors of "Report Problem" or "About" hyperlinks
do now not error nor crash as before.  Repair is good.

Good day and night for you
Hijau

Crash logs.

OK, I believe that one should be fixed- Please try the 10th of January build.

It was attempting to load the in-game route map whilst another was still drawing, and GDI Plus isn't thread-safe...
Somewhat of an edge case, I think you must have selected a very large route followed by this one in quick succession, but needed fixing

CrashData.Build 2017-01-20
https://www.dropbox.com/s/cf4o1hkj7vjymiy/OpenBVE-2017-01-20_SysVR_CrashData.7z?dl=1

leez, are you sure that the car index has been added to PlaySound? I'm currently checking the API on GitHub and I'm finding nothing.  I kinda need for odakyufanats, and that sound would be weird if it was playing only from the driver's cab.

Ooops, you're entirely right....
The plumbing was implemented in the main program, but not the API, as I think I must have discovered that altering the existing delegate was a backwards incompatible change & promptly forgotten about it.
Have added an appropriate new delegate to get around this, so the latest daily build (Probably complete in ~10 mins or so) should now work.

To use:
Your plugin needs to add a delegate callback function to PlayCarSoundDelegate, in exactly the same was as the current PlaySoundDelegate. It's easier to link to BVEC_ATS as it's on Github, but the delegates and sound manager should be pretty much the same & you'll get the idea:

https://github.com/leezer3/bvec_ats/blob/master/Functions/Sounds.cs#L20

Add a PlayCarSoundDelegate here.

https://github.com/leezer3/bvec_ats/blob/master/Functions/Sounds.cs#L27

Add this to the initialization function. (This is called from Plugin.cs, replicate the existing call to PlaySoundDelegate)

https://github.com/leezer3/bvec_ats/blob/master/Functions/Sounds.cs#L43
The PlaySound function needs modifying a little.

As you should be able to see, it calls the PlaySoundDelegate in a couple of places, which then generates/ alters the sound attached to the driver's car.
Either add an overload function which takes the car index and passes it on appropriately or however else you see fit

Note:
I'm currently working around the sound manager with regards to animated objects and some other stuff, but this has been briefly tested.

Cheers

A couple of changes of note in today's nightly build.

1. Loading sway is now optional. This is controlled by a checkbox in the Options ('Enable loading sway'), and is disabled by default. When trains get looked at properly, there will be a per-train option for this, but for the minute this should help with those people who don't like this effect
   
2. A couple of small changes have been made so that these builds co-exist by default with prior versions on the same machine. Specifically, it'll create a subfolder named 1.5.0 in the settings directory, and search this first for the options.cfg and controls.cfg files. If you've been using one of my prior builds and wish to revert to a 'stock' version, you'll need to delete the controls.cfg file, but going forwards both versions should co-exist.
   

Cheers

RouteViewer in the latest daily builds has an issue: the 4, 6, 2 and 8 keys on the numpad don't work. Neither do the arrow keys.

phontanka wrote:RouteViewer in the latest daily builds has an issue: the 4, 6, 2 and 8 keys on the numpad don't work. Neither do the arrow keys.

Oops, I know what's happened here.
I added mouse based camera motion/ rotation, which works just fine. The arrow keys and numpad also work *until* the mouse motion is used, at which point they stick....

Will fix shortly


Edit:
Fixed for the 13th February build.

After starting a route I got this message:

Warning: 0 compatibility objects were used.

I don't really understand the point of this, why did I get this message?

This happens with the February 14 version of openBVE.

phontanka wrote:After starting a route I got this message:

Warning: 0 compatibility objects were used.

I don't really understand the point of this, why did I get this message?

This happens with the February 14 version of openBVE.

It's counting the number of compatibility objects used

BVE2 came with a bunch of 'default' objects, which were used by a lot of early routes.
Michelle implemented some (catenary poles, the default Japanese transponders and some others I'm not sure of off the top of my head), and I've relatively recently added all of the others apart for the people (No suitably licenced images)

The message is harmless and mainly provided for info, although it shouldn't be showing with zero of these in use...

If you'd point me to examples of what those legacy people look like, I could see if I find adequate images.

I remember fondly what legacy people look like, low poly, indentity-less, all same, blue ish suited people standing in flocks, though 暴VE 1 didn't have any IIRC. The original BVE 2 and 4's are still available at bvets.net/old/ver2.html and bvets.net/old/ver4.html bundled with the original programs.

Attached is Mackoy's original people image

(There are a some single variants also, but they're in the main image)
You'll probably recognize them if you've played any route from somewhere around 2001 -2004 or so...

Not certain whether they were available in BVE1, but I strongly suspect so.


Adequate images isn't so much the problem as licensing. The openBVE site is running at 50 - 100 hits a day from Google alone, and as the one who is hosting/ developing things, I need to be squeaky clean on copyright etc.

Edit: The error should now also be gone unless compatibility objects are in use.

Something like this: https://pixabay.com/de/st%C3%A4dtischen-menschen-menge-b%C3%BCrger-438393/ could be an adequate source image. It is, as everything on Pixabay, licensed as CC-0 (which roughly translates as "I release this into public domain; where this isn't possible, I grant you all rights I am legally allowed to grant you").