openBVE 1.5.0 RC1 - BUGS

https://www.dropbox.com/s/2kgwcld56it3ahs/Seibu6115test.zip?dl=0
Just picked a working train, opened in TrainEditor, changed nothing, saved and now it doesn't load anywhere.

That loads perfectly in both Train Editor and openBVE here
I think we can discount it interacting with the route based upon the fact that you say Train Editor isn't working either, so it must be something odd.

Can I see a log from openBVE, and a crashlog if it produces one please?
Would also like to know if you're running a non-Western language as default, or something that uses the comma as the decimal separator or something like that.

Have just pushed some improvements to Train Editor:

• You can now choose the loco brake type (Notched or auto air brake), and this enables / disables the other properties as appropriate.
  
• EBHandle behavior duplicate removed.
  
• Fixed a glitch when EBHandle behaviour was not set in Train Editor. (Only produced a harmless error, but still)
  

I don't think this will fix your issues, but may help.
Let me know with those logs.

Haven't found the August 2nd build and what I have (July 31st build) apparently doesn't write logs :/ (found it neither in the game folder nor in Data/UserData and their subfolders)
OpenBVE is set to English (US), but the system language is not English and does have commas as decimal points by default...

[to be updated as soon as the newer build becomes availiable]

Right, I *think* we've found that one.....

https://vps.bvecornwall.co.uk/OpenBVE/Builds/OpenBVE-2018-08-02.zip

There may still be a couple of glitches lurking in the brake systems at the minute, so please keep an eye out for them.
Specifically, I've had a report that it used to be possible with some trains with separate handles to drive in B1 upto the brake control speed.

I'm waiting to hear back with a sample on that one, but I can't find anything in my collection that would do that with prior builds.
Interested to know if you can point me in the direction of a train which will do that.

The Aug 3 build solved the problem with OpenBVE/TrainEditor not loading trains

I'll test the brakes then. I can remember 2 oddities, first is "full" brakes set (compressor, main reservoir, etc) added on the first car even if it's not powered, second is openbve (prior to car/train.xml introduction) ignoring MotorCarCount/TrailerCarCount sometimes and adding an extra motor car while keeping the right total car count. This is pretty rare, but I had this bug with some formations.

I'm also curious how BVE distributes motor cars within the consist when only train.dat is used

https://github.com/leezer3/OpenBVE/blob/master/source/OpenBVE/Parsers/Train/TrainDatParser.cs#L860

Easier to link to the source than anything.

Delsin wrote:first is "full" brakes set (compressor, main reservoir, etc) added on the first car even if it's not powered

I believe the current build will now fix this.

Delsin wrote:, second is openbve (prior to car/train.xml introduction) ignoring MotorCarCount/TrailerCarCount sometimes and adding an extra motor car while keeping the right total car count. This is pretty rare, but I had this bug with some formations.

Need a broken file.
I'm guessing that one of two things is happening here:

• One of the car counts fails to parse correctly.
  
• A rounding error in the calculation I linked in my first post.
  

Couldn't find a train with the error so I think it has something to do with rounding errors...
Will try with some other formations to catch it but it seems like it so far.

Route viewer doesn't recognise the new (ish) ".Destination" feature and returns error message:

Warning        The command Train.Destination is not supported at line 17, column 1 in file C:\Trainsim2016\Railway\Route\Portarlington\Portarlington.csv

It's not exactly a disastrous fault, but it IS bloody annoying!

I converted a train with XML convertor from the Aug 5 build into the "child car XML" format and brakes now won't release, brake cylinders remain full. Removing the section solved it

graymac wrote:Route viewer doesn't recognise the new (ish) ".Destination" feature and returns error message:

Warning        The command Train.Destination is not supported at line 17, column 1 in file C:\Trainsim2016\Railway\Route\Portarlington\Portarlington.csv

It's not exactly a disastrous fault, but it IS bloody annoying!

Fixed.

Delsin wrote:I converted a train with XML convertor from the Aug 5 build into the "child car XML" format and brakes now won't release, brake cylinders remain full. Removing the section solved it

Fixed- Multiplication error.
(Internals work in Pa, but the train.dat works in kPa and this was just transcribing the figure straight across.....)


Adding some sort of unit detection to numbers would be useful; MSTS does this.

Same build, another bug: train.dat from which the train.xml was generated specifies 3.3 km/h/s acceleration, but until I "disabled" (renamed) train.xml, it was much lower in fact.

Can't think of an immediate reason for that one; Acceleration hasn't been touched in any way

Only guess I've got at the minute is that the number of motor cars has changed between the XML and the dat?
Need to see the dat though. Don't need anything else.

https://www.dropbox.com/s/326v7zg7r72yz4u/trta7000.zip?dl=0

both should specify the same formation, 6M4T with the front car powered.

Issue found, going away to beat my head on a wall as usual

Will push out a fix over the next couple of days, just need to think about it & implement some more stuff into Train.xml to support.
This is why train.xml is unfinished, so many things interacting with each other......

TLDR:
Your XML file list changes the formation of the train with regards to the motor car positioning.
This is fair enough, but the acceleration curves are stored as a property of each motor car, as opposed to the train.
The XML then changes the formation, but the curves weren't being moved to suit (yep, oversight, hadn't noticed where they were being storeed....), and so the cars which had been changed from trailer to motor weren't providing any acceleration.

thanks

this brings me to the question: how exactly should the power data be specified? Acceleration is easy to work with, but works only on fixed formations. With openBVE tending to move towards separate cars rather than fixed consists, will this be changed since acceleration varies as the formation changes? BVE5 has shifted to motor currents for every notch instead which works with variable formations (you can change the motors/trailers ratio and feel the train behavior change) and it'll be handy if we ever see coupling and uncoupling in openbve, but it isn't compatible with mechanic/hydraulic transmissions. I think both ways should be implemented, as for electric trains it's much easier to get motor current data than that on force output.
XML power data might also require using csv tables rather than xml file though

For most modern electrical vehicles, power (in kW) and maximum force (in kN) and maybe a correcting exponent would be more than enough.

Only really got around to having a go at this yesterday

I think the current build will now give you the correct acceleration, *assuming* the number of motor cars in the XML / train.dat match.
If the numbers are changed, I take no responsibility for what happens

The next major 'job' in this line of work is to pull in the actual acceleration definitions themselves to the XML file.

Quork wrote:For most modern electrical vehicles, power (in kW) and maximum force (in kN) and maybe a correcting exponent would be more than enough.

When it's a modern (modern is a pretty relative term though, trains with rheostatic control/DC motor reconnection are still being built, complete with spoked wheels ) train with a traction effort control system like AFB, then yes, but things get more complex when you have a few notches on the handle itself and n notches of variable resistance, serial/parallel connection and field weakening. Fundamentally, all these are still power or force or current vs speed with an exponent, but there should be some way of linking handle notches with that of camshaft or whatever is used for switching power steps. There's backwards rotation of the power handle with many two-handled trains as well (in Japanese practice, that enables dynamic brakes without using friction brakes for reducing the wear of the latter, particularly on long slopes. The "hold" notch in brake handle doing that automatically appeared much later. And with many Russian trains it enables dynamic and (below certain speed or when max notch is selected) blends in electro-pneumatic brake, while the actual brake handle controls EPB and automatic air brake only in the same fashion as "REL-LAP-SRV" handle in BVE, driver can choose what to use for slowing the train down), so there's a pretty big room for more flexibility

This may be difficult to nail down. I'm using Windows 7 Professional. After spending time (lots of it!!) using both  the route viewer and object viewer I will go and load the WIP into the game program and I often find, when keying "Esc" to jump to a station, there is no panel popping up to do this. The rest of the program seems to be working normally, it's only this feature that seems to be missing. I never notice it happen when I boot the PC and use the program without having used the tools. A reboot usually works to restore full program features.
Any ideas???

Chris, the release notes say: "Added new commands with an optional parameter for brake and power. These allow a specific power or brake notch to be assigned to a button/ keypress."

How do I use this function? Or where can I find it in the documentation? I looked for it in train.dat, but couldn't really find it. Or is only in train.xml?

This function (POWER_ANY_NOTCH and BRAKE_ANY_NOTCH) is added by https://github.com/leezer3/OpenBVE/pull/279

Assign the command to be added this time to the joystick and connect the contact of the joystick to the master controller.

Connect from each joystick button with wiring code by soldering, to create very easily the real cab's controller, such as power notch, brake notch, or any real buttons.

Having some weird s*** happening with object viewer. Been using it on route objts intensively for last 6 months and no problems at all. So, today I'm going to modify some train bits. Lo, and behold, transparent bits are being rendered as solids.  (example here of 22000 railcar, openings, windows and bits round underframe are solid). I tried different trains and same thing happening. Downloaded latest nightly build and that's the same. Even tried fresh download of train from website and same thing. Yet all the trains are rendered perfectly in the program.
Now, I know my sanity's a bit stretched after 6 months working on a new route, but WTF is happening here??

Something confusing going on here

The root of the issue appears to be in objects with a daytime and a nighttime texture specified, which are then viewed through a transparency on a face with a single texture specified.

Initial guess would be that something is going wrong with the blend, but need to do more digging.