Is current .sta StopDuration able to be received by OpenBveApi?

Hi! I'm fairly a new developer for a train plugin

I was trying to replicate a real life scenario where the train's display would be able to receive a 'dwell' time when at the station.

In game this 'dwell' time is set by the .sta StopDuration feature, but I am not able to get the StopDuration value into the plugin.

Is current .sta StopDuration able to be received by OpenBveApi?

Look in the ElapseData supplied each frame.
You want the Stations from there, and then you'd need to calculate the dwell time from the arrival / departure times.

I don't recall offhand when this was added to the API, but was likely around ~1.6

For maximum compatibility however, you'd need to build against the legacy 1.4 API and supply the dwell time via a beacon in the route.

leezer3 wrote:Look in the ElapseData supplied each frame.
You want the Stations from there, and then you'd need to calculate the dwell time from the arrival / departure times.

I don't recall offhand when this was added to the API, but was likely around ~1.6

For maximum compatibility however, you'd need to build against the legacy 1.4 API and supply the dwell time via a beacon in the route.

Ah thanks! So it's not possible to receive the actual StopDuration value at all, just need to be calculated from arrival/departure times

At first I assumed that Station.StopTime would contain the value

Will use the Beacon data to supply this data then

I appreciate the clarification!

Sorry, you're right, that's what comes of skimming code.

StopTime will contain that value, but that comes with the API version isse noted.

However, now I've read and tested the code it's got some issues that need solving properly:

• This value hasn't got any sense checking at the minute; If you create a station with no set arrival / departure times, this will currently return 0 (*not* the minimum stop time as would be expected)
  
• A station with no arrival time but a departure time will produce a wrong value. (It returns the time representation for the departure as the stop duration)
  
• Similar issue with departure time set but no arrival time. (silly negative numbers)
  
• AllStop seems to break it and sets it to zero.
  

TLDR:
It's broken
I'll try and fix it properly over the weekend, but for maximum compatability and less bugs the beacons are going to be the solution at the minute.

leezer3 wrote:Sorry, you're right, that's what comes of skimming code.

StopTime will contain that value, but that comes with the API version isse noted.

However, now I've read and tested the code it's got some issues that need solving properly:

• This value hasn't got any sense checking at the minute; If you create a station with no set arrival / departure times, this will currently return 0 (*not* the minimum stop time as would be expected)
  
• A station with no arrival time but a departure time will produce a wrong value. (It returns the time representation for the departure as the stop duration)
  
• Similar issue with departure time set but no arrival time. (silly negative numbers)
  
• AllStop seems to break it and sets it to zero.
  

TLDR:
It's broken
I'll try and fix it properly over the weekend, but for maximum compatability and less bugs the beacons are going to be the solution at the minute.

No worries, thank you mate!