openBVE feature requests

I gotta test that, thanks!

I personally prefer "horn", but there should be "klaxon" supported for backwards compatibility. Also "PrimaryRelease" instead of "PrimaryEnd" so it's same as BVE5 standard to minimize confusion for developers if they work both with it and openBVE.
Have you specified any behaviour if there is a start and loop file, but no end? Some trains have only these two.

Delsin wrote:I gotta test that, thanks!

I personally prefer "horn", but there should be "klaxon" supported for backwards compatibility. Also "PrimaryRelease" instead of "PrimaryEnd" so it's same as BVE5 standard to minimize confusion for developers if they work both with it and openBVE.
Have you specified any behaviour if there is a start and loop file, but no end? Some trains have only these two.

PrimaryRelease, SecondaryRelease and MusicRelease are now supported as alternate spellings
(18th March build)




Exact Behavior:

Primary & Secondary:

• If no start or end files are present, the sound will play once.
  
• If start or end files AND a loop file is present, the start/ end sound(s) will be played and the loop sound will loop.
  

Music:

• If no start or end files are present, the sound will play looped.
  
• If start or end files AND a loop file is present, the start/ end sound(s) will be played and the loop sound will loop.
  

Note:
The behavior for primary & secondary files has now also been reverted to match the documentation.

Sir Chris Lees
I did download and run test of your new version of 25 March 2017
and did not hear the errors of versions recent in the Sound.cfg [horn] primary and secondary and music
as they do operate corrected for me now.
This is good

Good day and night for you
Hijau

I can make the framerate and the train speed appear in the lower left, but I'd like to suggest that the current distance from 0, and the speed limit, would also be nice to have there.

Thanks,

Ed G

edgreenberg wrote:I can make the framerate and the train speed appear in the lower left, but I'd like to suggest that the current distance from 0, and the speed limit, would also be nice to have there.

Thanks,

Ed G

These can probably be added without too much trouble, will see what I can do.

Why did you want the current distance from zero though?
IIRC this is available in the F10 debug overlay, and if you just want to know the current train position, the map in the Route Information overlay might serve you better.

(When signalling gets 'done', the intention is to add another pane to the route information overlay containing the current signal aspect, speed limit etc, but signalling isn't top of my list at the minute....)

leezer3 wrote:

edgreenberg wrote:I can make the framerate and the train speed appear in the lower left, but I'd like to suggest that the current distance from 0, and the speed limit, would also be nice to have there.

Thanks,

Ed G

These can probably be added without too much trouble, will see what I can do.

If you were tinkering down that part of the screen anyway- does the speed need to be to two decimal places?  One at most, and possibly a whole number would suffice?

Fixed speed boards are part of your route knowledge and if any changes are made they have to appear in the Daily, Weekly and Monthly notices.

Temporary can appear or be taken away at almost any time but again they should be shown in the notices.  Set distances are set for the Warning boards, albeit this may be lengthened to suit the first sighting depending on the terrain. You should always get a warning board and know the distances involved and be able to work out your braking distance. At the moment there is no cab signaling to guide you on this but many locomotives have a train length gauge, which is typed into the computer when taking over a locomotive. You set the train length and as you approach the warning board set the train length to countdown. This lets you know when your tail end has cleared the termination board and start excellaration again.

without a countdown you simply know the check is there and knowing the route and your train, drive accordingly.

In bve it would be nice to have an exteral camera that follows the end of the train that you could use to see your train pass the termination board.

Mind that's UK an UK-style railways you describe. In central Europe, things are different. Every main signal and every restrictive (i.e. lower than before) speed signal has its distant signal standing before it. In some countries like in Germany, that's a fixed, route-specific distance (400m (≤60km/h routes), 700m, 1000m (most common) or 1200m), in others, like in Austria, it's slope-dependant and can vary quite a bit. Also you have your working timetable containing all permanent speeds, and the weekly "La" (list of all TSR and other noteworthy stuff like spots without GSM-R coverage) and the daily La corrections, all of which you are to lay open before you all the time. If using the electronic version on a screen, you have to stop immediately if it turns off. And TSR on short notice must be announced at least 48h in advance; if it's less time, every train is stopped before and gets a written order, until all are noticed/48h have passed since it was added to the La or La corrections.

Mind we have much more routes to know than you. My route knowledge is for roughly 1200km and that's still a really small bunch of routes, it'll be way more. You can't memorise that on the same detail level as is usual in the UK, where, afaik, 1000km is something you'd reach after years and years of driving.

leezer3 wrote:

edgreenberg wrote:I can make the framerate and the train speed appear in the lower left, but I'd like to suggest that the current distance from 0, and the speed limit, would also be nice to have there.

Thanks,

Ed G

These can probably be added without too much trouble, will see what I can do.

Why did you want the current distance from zero though?
IIRC this is available in the F10 debug overlay, and if you just want to know the current train position, the map in the Route Information overlay might serve you better.

(When signalling gets 'done', the intention is to add another pane to the route information overlay containing the current signal aspect, speed limit etc, but signalling isn't top of my list at the minute....)

OK, I found all the info I neeed in the debug overlay, so I'm happy and withdraw my request.   I wanted the distance so that, if I observed a bug while driving, I could note it down for either fixing, or for a bug report.

BillEWS wrote:Fixed speed boards are part of your route knowledge and if any changes are made they have to appear in the Daily, Weekly and Monthly notices.

Temporary can appear or be taken away at almost any time but again they should be shown in the notices.  Set distances are set for the Warning boards, albeit this may be lengthened to suit the first sighting depending on the terrain. You should always get a warning board and know the distances involved and be able to work out your braking distance. At the moment there is no cab signaling to guide you on this but many locomotives have a train length gauge, which is typed into the computer when taking over a locomotive. You set the train length and as you approach the warning board set the train length to countdown. This lets you know when your tail end has cleared the termination board and start excellaration again.

without a countdown you simply know the check is there and knowing the route and your train, drive accordingly.

Bill, what you say is correct.  All this info should be part of route knowledge, but remember that users of OpenBVE are not trained railroaders. Also, we run many more routes, on many more systems, with many more trains, than any pro railroader.  We also don't get trained on every route. 

Also, consider that the quality of the routes varies dramatically.  I've been driving along on one of the NYC Subway routes and hit a red without a preceding yellow. Or a series of Grade Time signals with no sign introducing them. Nobody trains us on these routes, as is done in real life.  IRL you go out with a trainer for several runs until you are either signed off as competent or fired .  So we need all the help we can get.

BillEWS wrote:In bve it would be nice to have an exteral camera that follows the end of the train that you could use to see your train pass the termination board.

We do , actually, at least in OpenBVE. I set my free camera to point back from the last car, and I can see the back of the speed board when I pass it by, and I know that it's OK to speed up.

I've been doing a bit of work on one of the routes that I like, to add speed boards, speed warning boards, mileposts and some visual indication of where the stop points at the stations are. I was fortunate enough to find an employee timetable on line.  I do not think that I'll be able to release this work since the original builder has not responded to me for permission.

BillEWS wrote:In bve it would be nice to have an exteral camera that follows the end of the train that you could use to see your train pass the termination board.

Assuming you're using my builds, switch to external camera.
Then hit Previous POI to move the camera car down the train.
Next POI moves the camera car back up again.

(Numpad 7 and Numpad 1 by default)

When you unrestrict the cab view, could re-restricting it remember how you left it if you move to other camera positions and back again?

Is it possible to use some point of a neighboring car as an "axle" in extensions.cfg? So it makes configurations like http://transphoto.ru/photo/02/48/65/248654.jpg possible? (rear part of the first section is connected to the front of the middle section, not to any bogie)

Also, won't it be too hard to introduce a motor/trailer car type selector in extensions.cfg as a temporary measure? I know this feature has been postponed till the introduction of the new train data format, but it's so hard to get a right car configuration sometimes now

I've gone one better (This has been in the works for a while, just needed to sort it out into a working build.....)

Today's build contains an updated version of the CarXmlConvertor application, which now generates a train.xml file.
This replaces the extensions.cfg file, and also allows setting of motor cars, per-car mass and per-car widths/ heights.

Complete generated/ working sample from D1015:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Train>
<Car>
<Length>20.8</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>True</MotorCar>
<Mass>80000</Mass>
<FrontAxle>6.5</FrontAxle>
<RearAxle>-6.5</RearAxle>
<Object>External\D1015.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>External\bogie_f.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>External\bogie_f.animated</Object>
<Reversed>True</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\mk1_bck_choc.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>True</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_so_ccm.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_so_ccm.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_rmb_ccm.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_fk_choc.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_fk_choc.animated</Object>
<Reversed>False</Reversed>
<!-- <FrontBogie> -->
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_fk_choc.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_r.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
<Car>
<Length>19.9</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>False</MotorCar>
<Mass>25000</Mass>
<FrontAxle>7.3</FrontAxle>
<RearAxle>-7.3</RearAxle>
<Object>Stock\MK1_bck_choc.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>Stock\bogie_f.animated</Object>
<Reversed>False</Reversed>
</RearBogie>
</Car>
</Train>
</openBVE>

Please note that this format is a WIP, and will probably crash with malformed XML files & / or produce completely un-anticpated results.
The next step is to allow the sections to be split into separate XML files, so we can add a single car quickly and easily to multiple trains, e.g a Train.xml file as per this:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Train>
<Car>D1015.xml</Car>
.....
</Train>
</openBVE>

and D1015.xml as per this:

Code:

<?xml version="1.0" encoding="utf-8"?>
<openBVE xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Car>
<Length>20.8</Length>
<Width>2.6</Width>
<Height>3.6</Height>
<MotorCar>True</MotorCar>
<Mass>80000</Mass>
<FrontAxle>6.5</FrontAxle>
<RearAxle>-6.5</RearAxle>
<Object>External\D1015.animated</Object>
<Reversed>False</Reversed>
<FrontBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>External\bogie_f.animated</Object>
<Reversed>False</Reversed>
</FrontBogie>
<RearBogie>
<FrontAxle>1.85</FrontAxle>
<RearAxle>-1.85</RearAxle>
<Object>External\bogie_f.animated</Object>
<Reversed>True</Reversed>
</RearBogie>
</Car>
</openBVE>


I don't anticipate making any structural changes to the format, but please don't release anything based upon this without at least letting me know first

Other stuff which needs to be done is to sort out allowing units in the lengths/ weights, but this is minor.

Looks very promising 
The only thing that slightly confuses me is that train data files become even more over-verbose than .csv compared to .b3d. Is it really required to use that format instead of some sort of "special for BVE" XML which is more compact, like below:

Code:

<Train>
<Car>
Length = 20.8
Width = 2.6
Height = 3.6
Motor = true
Mass = 80000
AxleFront = 6.5
AxleRear = -6.5
Units = Metric

(Actually, using "pure" XML with full syntax makes sense if there are plans to use browser or something like this to edit train data instead of a special app (like TrainEditor now))

Half of our current problems come from the fact that BVE uses a very inconsistent set of home-grown formats, and that BVE2 / BVE4's interpretation is often odd

I know XML is a little more verbose than what we've got at the minute, but I've chosen it as a format with a complete set of external standards, which I haven't set.
This way, I can just hook into the .Net XML reader & guarantee that I can parse it's output quickly and simply.

Taking your example for a minute, a parser for this needs to take into account the following (Off the top of my head, probably more):

• Splitting the argument and the key at the correct place
  
• Trimming excess spaces off the argument/ key as appropriate
  
• Handling non-supported key values etc. (With XML, we know exactly what the structure is and can simply traverse what we understand
  

At some stage, the Train Editor will be being updated to output the 'new' formats, but as noted at present, they're definitely experimental at best, and so manual editing only
(Amongst other things, I strongly suspect that editing car weights will probably expose more stupid assumptions in the physics engine that I haven't found yet)

Oh, now it makes sense for me. I guess it can reduce loading time then too.
Speaking of train editing, are there plans to implement rheostatic control simulation?

I don't know if this is a feature, but it's certainly a request. OpenBve's "Uchibo" compatibility does not include *any* background whatsoever. (That breaks compatibility! So... I've recreated BVE 2's Bg_Fine.bmp in a (much) higher resolution, though I don't know if t's the best result possible. Took me well over an hour, but I'm happy with the result.

I can't upload it because it's 900kB and I also can't hotlink from my homepage here's the link -> http://gutsandglory.web.fc2.com/img/Bg_Fine.png

Hope y'all like it

Hmm, that's a very good point, some stuff refers to the original Uchibo textures.....

That's slightly more complex than simply loading a replacement object, but I'm sure something can be sorted out.

Almost tempted to add a stock background whenever the default is missing too, but I'm sure I'd promptly find that someone has used that to represent tunnels or night or something.....

Would it be possible for the safety plugin to sound / control the train's horn? The big red emergency button in japanese trains forcefully sounds the horn desu.

Glory! koshikii wrote:Would it be possible for the safety plugin to sound / control the train's horn? The big red emergency button in japanese trains forcefully sounds the horn desu.

That sorta-works at the minute.
Add your horn as an ATS sound (or set-of), and you can play it in exactly the same way as any other sound. Marginally roundabout, but there we go


Having said that, can you clarify exactly what you're trying to achieve?
If I implemented your request as-is, any elements on the panel (or train externals) attached to the horn would also animate. This doesn't seem like what you actually intend?
Another (secondary...) thought- Plugins can currently block power/ brake applications (see the virtual handles vs. the actual handles), so would it be of any use to you / others for plugins to have the ability to block horn applications?

Will do some thinking on this though, as plugins with an AI driver implemented really ought to be able to actuate the horn directly in exactly the way I'm describing above.
The initial problem I can see would be backwards compatibility, as the instant immediate place I'd be thinking of putting this would be in the AI handles returned.

leezer3 wrote:Having said that, can you clarify exactly what you're trying to achieve?
If I implemented your request as-is, any elements on the panel (or train externals) attached to the horn would also animate. This doesn't seem like what you actually intend?
Another (secondary...) thought- Plugins can currently block power/ brake applications (see the virtual handles vs. the actual handles), so would it be of any use to you / others for plugins to have the ability to block horn applications?

My idea is to simulate the player hitting the primary or secondary horn key, and sounding the actual horn. What I personally want is to just sound the horn: I'm developing a beacon in odakyufanats that make the AI seem more realistic, turning on cab lights in tunnels and responding to "whistle" signs, so I just ask for a way to just sound the n-ary horn for an x amount of time. I wish that for doors too, Bve Ats'es have to implement virtual doors for driver-operated doors.

I wouldn't find blocking the horn very useful, but I can see its use cases in like a conductor simulator were you control the doors, make the announcements, etc.

As for backward compatibility, just adding new methods won't hurt. But you probably also have to think forward compability: will the current trains (post-conversion) be compatible with the OpenBve 2 spec - if there is any? If not then let's have fun.

leezer3 wrote:Will do some thinking on this though, as plugins with an AI driver implemented really ought to be able to actuate the horn directly in exactly the way I'm describing above.
The initial problem I can see would be backwards compatibility, as the instant immediate place I'd be thinking of putting this would be in the AI handles returned.

But those are virtual horns, no? While in the cab, a virtual horn sounds like an actual horn, it wouldn't be of much use for those who like the external cameras. (But then again, you can hear everything that goes in the cab car from a mile away...)

Side note, me being picky with the name again: if OpenBVE 2 is going to change the game, why not make it OpenExpress or something, YouTube and possibly some people think Bve = OpenBVE.

some more sounds:
- coupler stretch/push sounds, played once from coupler points (exactly between cars) when they reach either fully stretched or compressed state, disabled for coupler N when [couplerN]'s Distances in extensions.cfg (or a similar parameter in train.xml) is set to 0,0. Diffirent sounds for stretch and push
- more "rub" sounds - Rub0, Rub1 and Rub2, 0 works like Rub sounds currently do and when Rub sound is specified in sound.cfg in [Others] like before, it's considered to be Rub0 for backwards compatibility. For newer trains, rub sounds can be set like this:

Code:


[Rub]
0 = sound/Rub0.wav
1 = sound/Rub1.wav
2 = sound/Rub2.wav


Rub1 and Rub2 work differently, Rub1 doesn't change pitch and fades in at some speed (with speeds at which it starts to fade in and at which it stays at 100% volume until the train stops set through car's xml), Rub2 is similar, but fades out as the train slows down (with 100% and 0% speeds set from car xml file as well)

Variable pantograph heights in routes changing in the same fashion as brightness + a corresponding function for .animated files. Thought of that just now and so far seems fairly easy to implement to me. Should be very useful for lots of routes with lower catenary in tunnels or under bridges.

And a couple of other things I found would be useful while playing around with some trains:
- more motor sound graphs so that the total number is 4-5. (MOTOR_P3, MOTOR_P4, etc.) + maximum amount of motor sounds around 30 or more. This is enough for reproducing most motor sounds with a decent realism level.
- an option for animated cabs in panel.animated to be just a camera located in a car specified in DriverCar in some location - the way 3D cabs work now (car 0 and its bogies disappear, instead panel.animated is rendered above any other model with Z-sorting (or how it's called) disregarded) isn't suitable for many trains (for example, when a wall between cab and the rest of the interior has transparent parts or doesn't exist at all)