openBVE feature requests

Chris, I'd like to request a feature for package management. Right now there are three types of packages, route, train and other. What I would like is a combination of route and train. That is, I'd like to package the train together with the route.

The idea came up while I was converting routes to package format and made a specialised version of a train for a route which is only really usable on that route and would be of no use anywhere else. In this situation it would be great if I could add this train to the route package.

Is there a fix for the glitch(I think) where an object would disappear when you move the camera at a certain angle?

Simcentral wrote:Is there a fix for the glitch(I think) where an object would disappear when you move the camera at a certain angle?

Whilst I've fixed a bug with object visibility, I haven't come across this one (I don't think).
Any chance of a link to something that does this, and a description of how to replicate?

Can certainly have a look, but I make no promises.

I know it from older routes. Dunno what they did different than today, but there many (especially big) objects tend to disappear once you've passed their geometric centre.

leezer3 wrote:

Simcentral wrote:Is there a fix for the glitch(I think) where an object would disappear when you move the camera at a certain angle?

Any chance of a link to something that does this, and a description of how to replicate?

Can certainly have a look, but I make no promises.

I can't post a link until 7 days pass, but the object is pretty big and i made an animated file with a bunch of buildings and trees to simulate an outdoor section

Quork wrote:I know it from older routes. Dunno what they did different than today, but there many (especially big) objects tend to disappear once you've passed their geometric centre.

It's not the geometric center, but the 25m block in which the object is placed. (e.g. an object placed at 24m will disappear when the camera position passes 25.01m, no matter if it extends past this point)
The following option will change that:

Options.ObjectVisibility 1

It's not set by default, as some BVE4 routes use this as an animation trick

Simcentral's bug sounds different though if it's triggered by rotating the camera.

Could it be possible to modify the brake pipe charging rate via train.dat? The current unchangeable value is too high, not only for a long freight train, but also for a locomotive pulled passenger train or EMU.

Thanks,

Jorge

jorgecerezo wrote:Could it be possible to modify the brake pipe charging rate via train.dat? The current unchangeable value is too high, not only for a long freight train, but also for a locomotive pulled passenger train or EMU.

Thanks,

Jorge

The train format is on the list for being re-done, and my instinct is not to add new features to the existing formats unless they can be clearly defined, and are unlikely to be mis-interpreted by prior versions, which this isn't really.

I'll add it to the list, but unless it's urgent, I'd rather not hack it into the train.dat

Cheers

I was trying to recreate some Japanese trains and I bumped into a major problem of openbve - I can't define which cars within train are motored or not, bve just sticks to its own pattern and there's no way to change that. Maybe it was already requested, I only have a little suggestion how to realize that: a tag in extensions.cfg which defines type of a car.
(M - motor, T - trailer)

Code:

[Car0]
Object = train/7000Mc.animated
Axles = -6.5,6.5
Type = M

[Car1]
Object = train/7000T1.animated
Axles = -6.5,6.5
Type = T


If those are set, info about motor and trailer cars from train.dat is ignored, it's only summed to define how many cars the train has.

Speaking of file formats, train.dat still has 2 unused parameters 

Short answer is that the train.dat & extensions.cfg pairing are high on my list of things to be replaced soon, at which point stuff like this is very much on the list of things to be be implemented.

Whilst I could hack this into the extensions.cfg with very little trouble, I'm trying to avoid adding major new features to existing file formats, in favor of completely rebuilding things from the ground up.
How 'urgent' is this?

Is it necessary to have the motor cars in the exact arrangement? (What about pantographs and car numberings, though) Are you working for Tokyo Metro or something? lol

I'd like an option to disable stop overrun and delay penalty, namely because platform doors, where you have to restrict the stop position when simulating (braking the train just enough so the train doors are just within range of the home doors is fine in real life) and disable delay penalty for the sake of being complete. This is not urgent in anyway as there seems to be very low demand for home door equipped / ATO lines in Bve / OpenBVE.

leezer3 wrote:How 'urgent' is this?

It's not a big and mighty need, thanks, just a bit strange when a car which is supposed to be a trailer has motor and compressor sounds. But I appreciate your user-oriented approach   

The train I'm modelling now (fictional one, though, intended to test all the 1.5.0 features) has a formation matching what openbve suggests for 5M10T with first car motored, so it's not a problem for now. But I'm planning to reproduce something like Tokyo Metro 7000 series later, and those have quite an interesting formation, it's their quite remarkable feature which can't be rendered now. But that's not coming soon.

If you want to implement a new train data format, you may want to look at what BVE5 uses, it's quite flexible

That'll need some more thought, considering how modern EMU have their stuff distributed along the whole train. Just take the 7car ICE-T (DB class 411):
transformer car - converter car - traction motor car - middle car - traction motor car - converter car - transformer car
Second, third, fith and sixth car have traction motors with corresponding sounds; first and last car have a pantograph (of which usually only the rear one is used) and a main switch (both are used; there's a high voltage 15kV line connecting both transformer cars) with corresponding sounds; first, last and (except in first series) middle car have compressors with corresponding sounds.

So I think the most sensible way would be to have the train creator define all sounds independently from each other. I'm thinking along the lines of the sim offering a buch of possible triggers/controls (e.g. train.mainconnector, train.motor, track.OHLneutral, track.switch etc. etc. etc.) to which the train creator can assign sounds in each car independently. Though it still wouldn't make defining which cars are actually powered unnecessary, since adhesion, weight force on axle etc. are relevant to the effective traction force.

Exactly, it's not only a problem of sounds. I noticed that as couplers within bve train are slightly flexible, you can see that motor cars do traction, trailers don't. Openbve definitely works differently with them in terms of physics as well.
I think the best way to reflect the properties of each car is to have something like train.dat for every car in train, where you can specify what it has.

Delsin wrote:I think the best way to reflect the properties of each car is to have something like train.dat for every car in train, where you can specify what it has.

What about the nightmare of a Yokosuka Line E217 with 10+5 cars? or a freight train with dozens more?
I think that, while this solution is easier on computing power, seek carN.dat for the Nth car, it would be very time consuming to do separate train.dat-s even if the train author knew every single detail. It's better to put it on extensions.cfg or extensions.txt with Bve 5 format, or an xml file just to indicate the differences, as these are much more noticeable than unique features in my opinion.

Glory! koshikii wrote:

Delsin wrote:I think the best way to reflect the properties of each car is to have something like train.dat for every car in train, where you can specify what it has.

What about the nightmare of a Yokosuka Line E217 with 10+5 cars? or a freight train with dozens more?
I think that, while this solution is easier on computing power, seek carN.dat for the Nth car, it would be very time consuming to do separate train.dat-s even if the train author knew every single detail. It's better to put it on extensions.cfg or extensions.txt with Bve 5 format, or an xml file just to indicate the differences, as these are much more noticeable than unique features in my opinion.

I'm actually doing a train based on E231-1000 which is 10+5 too (https://youtu.be/H0oFtpaZPiU if interested, it's a super-early test, lots of stuff is missing)
Well that was just an idea. Probably a smaller config for each car (even in 1 file) is enough - it sets only car type (M/T) and defines if it has pantograph (no, 1, 2, 3, 4), compressor, batteries, etc. Also a setting to synchronize compressors within train in train.dat's successor is very handy, as, for example, 1992 stock or 81-717 doesn't start only one compressor somewhere in consist.

Hmm, a separate setting for interior lights, similar to headlight, would be good too...

It's definitely awkward but funny to see a modern train with an old looking face. 
Honestly, interior lights aren't something that the driver really manages in Japan, unless a wanman, one-man line. If anything, the train arrives at the station, the conductor or train guard checks the destination indicator, the taillights, the interior lights and then he opens the doors. I'd love to work on your train though.

Delsin wrote:

leezer3 wrote:How 'urgent' is this?

It's not a big and mighty need, thanks, just a bit strange when a car which is supposed to be a trailer has motor and compressor sounds. But I appreciate your user-oriented approach   

The train I'm modelling now (fictional one, though, intended to test all the 1.5.0 features) has a formation matching what openbve suggests for 5M10T with first car motored, so it's not a problem for now. But I'm planning to reproduce something like Tokyo Metro 7000 series later, and those have quite an interesting formation, it's their quite remarkable feature which can't be rendered now. But that's not coming soon.

If you want to implement a new train data format, you may want to look at what BVE5 uses, it's quite flexible

BVE5's train data format is mildly interesting, but it's only really a rehash of the train.dat format into a set of key/value pair files, plus separating out the motor noise and performance tables

There's nothing wrong with that per-se, but it doesn't handle configurations on a per-car basis, which will be the target for any new format.
It's also still very much designed around the MU model, and doesn't handle other things very well.

I favour XML (Well structured, easy to understand, widespread), and this is a barebones draft of what I'm looking to implement:

Code:


<openBVE>
<Train>
    <DisplayName>
        <EN>Example Name</EN>
        <DE>Example Translated Name</DE>
    </DisplayName>
    <Car>
    <GUID>123456789</GUID>
        <Physics>
            <Mass>
                <Tons>12.5</Tons>
            </Mass>
            <StaticFriction>0.25</StaticFriction>
            <RollingResistance>0.0025</RollingResistance>
        </Physics>
    <MotorCar>true</MotorCar>
.............
</Car>
</openBVE>

As an alternative, it should also be possible to use a relative reference to a car file, e.g.

Code:

<Car>
    <XML>..\Car.xml</XML>
</Car>

A lot of the internal plumbing for this sort of thing is already there, just needs hooking up.

Glory! koshikii wrote:It's definitely awkward but funny to see a modern train with an old looking face. 
Honestly, interior lights aren't something that the driver really manages in Japan, unless a wanman, one-man line. If anything, the train arrives at the station, the conductor or train guard checks the destination indicator, the taillights, the interior lights and then he opens the doors. I'd love to work on your train though.

I just wanted to do something long and with "green cars", but E231's front was too boring. And I like the design of 113/115/413/415/711/717, so that happened  it was 2 years ago already...
Anyway, I started re-building it from scratch only recently.

Speaking of interior lights, on some trains they're operated by driver. I don't really know much about Japanese trains, but what I can say for sure is that on metro trains here (81-717) this is done from the front cab.

leezer3 wrote:

Delsin wrote:

leezer3 wrote:How 'urgent' is this?

It's not a big and mighty need, thanks, just a bit strange when a car which is supposed to be a trailer has motor and compressor sounds. But I appreciate your user-oriented approach   

The train I'm modelling now (fictional one, though, intended to test all the 1.5.0 features) has a formation matching what openbve suggests for 5M10T with first car motored, so it's not a problem for now. But I'm planning to reproduce something like Tokyo Metro 7000 series later, and those have quite an interesting formation, it's their quite remarkable feature which can't be rendered now. But that's not coming soon.

If you want to implement a new train data format, you may want to look at what BVE5 uses, it's quite flexible

BVE5's train data format is mildly interesting, but it's only really a rehash of the train.dat format into a set of key/value pair files, plus separating out the motor noise and performance tables

There's nothing wrong with that per-se, but it doesn't handle configurations on a per-car basis, which will be the target for any new format.
It's also still very much designed around the MU model, and doesn't handle other things very well.

I favour XML (Well structured, easy to understand, widespread), and this is a barebones draft of what I'm looking to implement:

Code:


<openBVE>
<Train>
    <DisplayName>
        <EN>Example Name</EN>
        <DE>Example Translated Name</DE>
    </DisplayName>
    <Car>
    <GUID>123456789</GUID>
        <Physics>
            <Mass>
                <Tons>12.5</Tons>
            </Mass>
            <StaticFriction>0.25</StaticFriction>
            <RollingResistance>0.0025</RollingResistance>
        </Physics>
    <MotorCar>true</MotorCar>
.............
</Car>
</openBVE>

As an alternative, it should also be possible to use a relative reference to a car file, e.g.

Code:

<Car>
    <XML>..\Car.xml</XML>
</Car>

A lot of the internal plumbing for this sort of thing is already there, just needs hooking up.

Seems like a good choice so far. Can also bring back some developers who were discouraged by some of inflexibilities inherited from bve2/4.
Btw, I thought that having separate run sounds for some cars is needed sometimes.

Can be sound "stopping" (for example, when you close doors and right after you do it, you push F5/F6 button again, door opening sound keeps playing in openbve, but stops in BVE5) reproduced in openbve?

Also "three-part" horn sounds (i.e. it's separated into start, loop and end part in the same way as the compressor sounds) would be very useful.

Delsin wrote:Can be sound "stopping" (for example, when you close doors and right after you do it, you push F5/F6 button again, door opening sound keeps playing in openbve, but stops in BVE5) reproduced in openbve?

Also "three-part" horn sounds (i.e. it's separated into start, loop and end part in the same way as the compressor sounds) would be very useful.

I think both of those would really need to be implemented as part of the 'new' format, simply because it's a quite radical change of behaviour.
There are also cases where the sound *should* keep playing if the button is pressed for a second time (Speech based annoucement?) which we need to handle appropriately

Let me think about it for a while.....

Three part horn sounds are now supported in the current nightly (12th of March)

Code:

[Horn]
PrimaryStart = PrimaryStart.wav
Primary = PrimaryHorn.wav
PrimaryEnd = PrimaryEnd.wav

A similar structure is supported for Secondary and Music.
The alternate spelling of PrimaryLoop etc. is also accepted.

Technical details:
The file defined by PrimaryStart will be played once at 100% pitch and volume when the horn key is first depressed.
The file defined by Primary will then be played in a continous loop at 100% pitch and volume.
When the horn key is released, the looped sound will stop, and the PrimaryEnd will play once at 100% pitch and volume.

• If a horn sound has a start or end sound defined, it will use the new looped behaviour.
  
• If a primary/ secondary horn sound has NO start or end sounds defined, it will use the legacy behaviour. (The sound is triggered approximately once a frame giving a semblance of a loop)
  

Other Changes:
The following variables are now supported for use in panel2.cfg based trains:

klaxon - Returns the index of the lowest currently playing horn. (Primary = 0, secondary = 1, music = 2)
primaryklaxon - Returns 1 if the primary horn is currently playing.
secondaryklaxon - Returns 1 if the secondary horn is currently playing.
musicklaxon - Returns 1 if the music horn is currently playing.

primaryklaxon, secondaryklaxon and musicklaxon have also been added to the available animation subjects. (klaxon had already been implemented previously for these)

• Note that klaxon may be replaced with horn in these commands if you so prefer
  

Future:
When the new format is implemented, the location of the horn within the car and the pitch and volume will be controllable.
I'd quite like speed dependant horn tones too, but I'm thinking on that one.....

Sir Chris Lees
I did download and run test of your new version of 13 March 2017 today
and did find these new errors in the Sound.cfg
[horn]
primary=klaxon1.wav      is wrong, too short abbreviated from proper time
secondary=klaxon2.wav  is wrong, too short abbreviated from proper time
music=klaxon3.wav        is wrong, too short abbreviated from proper time and not looping

Your version of the 5 March 2017 does not error with these sounds
and does run good for me

Good day and night for you
Hijau

Hmm...
I can't hear or see any difference with a quick selection of test trains:

• 81xx
  
• 613-133-7v4 (Dexter's)
  
• Class 153 DMU
  
• Class 104 DMU
  

Can you link me to a misbehaving train please?


Music Horn:
As far as I can tell, there are no changes between the builds from the 5th and the 13th.
However, what the music horn does seems somewhat inconsistent with what the documentation states it should....

According to the documentation, the music horn should play in a constant loop, but it's actually repeatedly triggering the sound.
I've also gone back to 1.4.3 and 1.4.2 and observed the same behaviour, so I'm a tad puzzled as to this.

Other Horns:
The documentation is rather odd on these too....
It states this:

Played once when the primary horn is applied.

This is clearly not the case on either 1.4.3, 1.4.2 or my builds: A horn sound is repeatedly triggered whilst the key is held down, giving an approximately constant tone....


I've changed the behavior of the music horn to match the documentation, and I think that the other two should probably be changed too.
I'd like to take a look at one of the trains which you're testing with though to see if I can reproduce your problem.

Edit:
Anyone else with thoughts?
Someone who can hear a difference too would be good