New Feature: Destination Events

There are three types of Irish dmu currently available. And about a dozen possible destinations for them within all the Irish routes. I would like, somehow, for the correct "destination" to be displayed on the train by whichever chosen route when it's loaded, (obviously without the need to have a duplicated  train of each class and variation for each and every possible destination in the "Train" folder, which is the only way I can see to do it at present). 
Destination signs (static or scrolling, front, side and interior) on CTS trains are mostly already separate items called for within the .ANIMATED file (as container for elements) of each car.

The .csv route file currently has a code line for selecting default train, could a new line for selecting "destination" allow sign objs to be added to the car(s)?

graymac wrote:There are three types of Irish dmu currently available. And about a dozen possible destinations for them within all the Irish routes. I would like, somehow, for the correct "destination" to be displayed on the train by whichever chosen route when it's loaded, (obviously without the need to have a duplicated  train of each class and variation for each and every possible destination in the "Train" folder, which is the only way I can see to do it at present). 
Destination signs (static or scrolling, front, side and interior) on CTS trains are mostly already separate items called for within the .ANIMATED file (as container for elements) of each car.

The .csv route file currently has a code line for selecting default train, could a new line for selecting "destination" allow sign objs to be added to the car(s)?

That's actually more complicated than it looks.

The .animated format has no concept of a string as a variable (Everything is numeric under the hood), so names per-se wouldn't work.

I suppose we could add a numeric destination variable which could be read by animated files?
Doing something like that would also want a 'beacon' equivilant to trigger it when we pass a point in the track.

The other (backwards compatible) solution would be to use a plugin reading a beacon to set the destination. That's used by most existing stuff, but specific train/ route/ plugin combos must be setup, and it's nowhere near generic.

Let me know what you think?

Would be interested if anyone has clever ideas on using names in animated files too

I didn't think it would be simple.

I suppose we could add a numeric destination variable which could be read by animated files?
Doing something like that would also want a 'beacon' equivalent to trigger it when we pass a point in the track.

That looks like a possible way forward. Would that make it possible to update passenger info signage on (and in) the car? For example, to change the object texture to show "next station [name] . . . " as the train proceeds along the route. Some Irish trains do that in reality.

OK, I've now implemented a working prototype for this

https://github.com/leezer3/OpenBVE/pull/222

It'll make it's way into the daily builds, probably tomorrow or Thursday.

Routefile Code:

Train.Destination(InitialDestination)

InitialDestination should be an integer, representing the initial destination displayed by the train at the first stop

---

Track.Destination(Type , BeaconStructureIndex , NextDestination , PreviousDestination , TriggerOnce , X , Y , Yaw , Pitch , Roll)

Type should be one of the following: -1 : AI trains only 0 : All trains 1 : Player train only
BeaconStructureIndex should be the index of any beacon object previously declared, or -1 to show no visible marker.
NextDestination represents the destination to change to when passing over this beacon forwards, or -1 to not change.
PreviousDestination represents the destination to change to when passing over this beacon in reverse, or -1 to not change.
X, Y , Z, Pitch , Roll control the positioning of the associated object (if in use)

Object Code:

All this does is to introduce a single new variable: destination
This reads the destination set above, and can be used as desired in state changes, texture shifts etc.

Looks like just what's needed. I'd like to see a working example in a routefile to understand it and properly apply it.

Routefile sample:

Code:

WithTrain
.Folder TestTrain
.Destination(0)

....... SNIPPED......

WithTrack

1000,  .Destination(0;0;1;0;0)
2000,  .Destination(0;0;4;1;0)
3000,  .Destination(0;0;3;4;0)

Object sample:

Code:

[Object]
States=Destination0.b3d, Destination1.b3d, Destination2.b3d, Destination3.b3d,Destination4.b3d
StateFunction=destination

Should now be in today's build.
Dead simple, as you can hopefully see, the variable starts at zero (Assume that our route starts at 0), and changes at 1km, 2km and 3km.

If the train is reversed, the destination will automatically roll backwards. (Disable this by setting the 4th number to -1)

This example applies to all trains, and will trigger repeatedly.

I'll play with that later. I'm on train to Dublin, hoping to shoot a green 29000 with a loaded Nikon!!!

Chris, you're nothing less than a genius! I just knocked up a rough implementation on my "test track" and it's all working great. If I can use it then any auld eejit can!

I'll be tidying up the train exterior file structure to keep it tidy. I'll have a few place names to photoshop! Passengers won't be catching the wrong trains ever again 

This was one of the simpler additions :p

I'd suggest you pick a completely random starting point for your numbering (not 123), bit it should work fine in either case.

There's currently 33 stations throughout all the Irish Routes. I'm going to try allocating each of them an integer that will be common in all diagrams. Should be fun implementing all that! It's a great feature added to the program.

I've fitted the 22000 units on the website with the apparatus to start the route with the correct dest displayed. BWR2015 routes & KMG2016 (on the website) now have the .Destination(n) line inserted. This 2800 has been fitted, and is following a sequence of changes using the instruction in WithTrack,

Just a quick note on this update graymac. I've noticed you're using the current date as a version number for the package. Not sure that's how it's supposed to be done. Perhaps it'd be better to use the conventional method of updating major and minor version number increments as it would allow the system to recognize a new version as such.

Please correct me and completely ignore me if I'm wrong here chris.

I can never keep track of arbitrary version numbers for all my stuff. At least the date is a true indication of how recent it is. Otherwise it's always going to be v. 0.0.0 every time.

CAF Mk4 cars have been upgraded with auto destination panels. Also 3D wheels. On the website now (don't forget, you must download the (updated) route as well for it to work.
22000 units are also updated for destination feature.

What a great feature!! I also want to try this tonight.

Hi all. I'm new here, but I've successfully implemented the feature in one of my personal projects, and I've gotta say it's a blast. There's just one thing: when I open the doors my destination signs go away. Intentional, or just another bug that needs to be flattened? Any help appreciated!

MockingbirdX wrote:Hi all. I'm new here, but I've successfully implemented the feature in one of my personal projects, and I've gotta say it's a blast. There's just one thing: when I open the doors my destination signs go away. Intentional, or just another bug that needs to be flattened? Any help appreciated!

I can't reproduce this.

Graymacs IWR stuff (good test as I didn't write it ) works just fine when the doors are open or closed.

Need to see the code for the function, and possibly the object as well to tell what's going on.