I will place some calculations on route creation here. Should you have any particular request, let me know. Once there is enough valuable content, it can be converted to PDF and put to our "College of Knowledge"...

Well that depends on what the clock is for. For a station clock, you'd want a refresh rate of 1sec for everything; these formulae are used in my gothic building bricks for the church clock, which isn't necessarily highly accurate, that's why I purposedly took those high values. But thank you for pointing it out explicitely!

I think Buckysam related to Gray's and mine posts about clocks, since he asks about clocks...

@ Buckysam: As both Graymac's and mine formulae are describing rotations, with each being 60 times slower than the next quicker one, chances are big, it's about analog clocks, isn't it? It might prove valuable to try and analyse a formula before trying to find usages for it

@ Manuel: You use "distance" wrongly. Please check back on the documentation for what the value of "distance" is. When used in a cab, it always will be 0, no matter how far you drive. What you try to do is a tough one... Problem is, you have no possibility to save a value in a variable. The only thing you can do is access the last value of the function; but since you use a digital metre and thus stateFunction, the value is always rounded, so with every calculation you lose more accuracy, in an unpredictable way; the faster a computer is, the lower the value will be (or even won't ever leave "0"), since the faster it is, the more often the stateFunction is calculated, the bigger chances are values get down- and not uprounded. If you start, and the computer calculates you've done 0.4metres since the last evaluation, the value won't change, as the 0.4 will be downrounded to 0 again. "value + delta * speedometer" best describes the distance travelled; but I have no idea how to put this in a way for digital display. It would be possible to have an analogue metre, as there you don't need rounding and can keep exact values all the time. That might be an idea though... I see you're even (a bit) younger than me, but maybe you still remember MC recorders nonetheless? They often had an analogue digit display. Also I think there have been such clocks. They work as follows:For each digit, you have one ring with all 10 ciffers on it. And every digit moves ten times slower than the one right to it. So when the 1m digit rotates ten times, the 10m digit rotates once; when the 10m digit rotates ten times, the 100m digit rotates once; and so on. So this might do the trick:

You can make a speedometer as an animated obj in a 3D cab. A odometer (distance read-out) is not possible, as far as I can tell. (see functions, below, from OpenBVE guide)

● Trains (general)Variable Descriptioncars The number of cars the train has.speed The signed actual speed of the current car in m/s. Is positive when the train travels forward, and negative when the train travels backward.speed[carIndex] The signed actual speed of the car carIndex in m/s. Is positive when the train travels forward, and negative when the train travels backward.speedometer The signed perceived speed of the current car in m/s as it would appear to a speedometer on wheel slip and wheel lock.speedometer[carIndex] The signed perceived speed of the car carIndex in m/s as it would appear to a speedometer on wheel slip and wheel lock.acceleration The actual acceleration of the current car in m/s².acceleration[carIndex] The actual acceleration of the car carIndex in m/s².accelerationMotor The acceleration which the motor of the first motor car currently generates in m/s².accelerationMotor[carIndex] The acceleration which the motor of the car carIndex currently generates in m/s².distance The non-negative cartesian distance measured from the object to the closest car in meters. Only meaningful for scenery objects.distance[carIndex] The non-negative cartesian distance measured from the object to the car carIndex in meters, or 0 if the car does not exist. Only meaningful for scenery objects.trackDistance The signed track distance measured from the object to the closest end of the train in meters. Is positive when the train is in front of the object, negative when behind, and zero when the object lies between the ends of the train. Only meaningful for scenery objects. Deprecated. The behavior of this variable may change in future versions of openBVE.trackDistance[carIndex] The signed track distance measured from the object to the car carIndex in meters. Is positive when the center of the car is in front of the object, and negative if behind. Returns 0 if the car does not exist. Only meaningful for scenery objects. Deprecated. The behavior of this variable may change in future versions of openBVE.

Quork wrote:I think Buckysam related to Gray's and mine posts about clocks, since he asks about clocks...

@ Buckysam: As both Graymac's and mine formulae are describing rotations, with each being 60 times slower than the next quicker one, chances are big, it's about analog clocks, isn't it? It might prove valuable to try and analyse a formula before trying to find usages for it

Mainly, it's about digital clocks. Most trains I've used already have a digital clock in the cab, but it's just a static object. I want to try adding a working digital clock in them so i don't have to use the function to display the clock. There is a train I have that the digital clock in the cab is fully working. I want to replicate that in other trains.

Well I do understand you, Buckysam, but the formulae presented here are pretty obviously ones for analog clocks. A digital clock isn't hard to do, it's a simple matter of state functions and cycling through 10 objects for each digit.

Graymac, don't you think my idea for the odometre would work? It isn't 100% accurate, that's obvious, but it should work nonetheless. Or is there an error in my thoughts?

Quork wrote:I think Buckysam related to Gray's and mine posts about clocks, since he asks about clocks...

@ Buckysam: As both Graymac's and mine formulae are describing rotations, with each being 60 times slower than the next quicker one, chances are big, it's about analog clocks, isn't it? It might prove valuable to try and analyse a formula before trying to find usages for it

Mainly, it's about digital clocks. Most trains I've used already have a digital clock in the cab, but it's just a static object. I want to try adding a working digital clock in them so i don't have to use the function to display the clock. There is a train I have that the digital clock in the cab is fully working. I want to replicate that in other trains.

Graymac, don't you think my idea for the odometre would work? It isn't 100% accurate, that's obvious, but it should work nonetheless. Or is there an error in my thoughts?

I think you know more about this subject than I do. Trainbuilding's not my speciality, plus I only know the panel2 cab method. As for animated format, my animated objects are nearly all based on "found items" like the examples in the OpenBVE demo route. You would have to try your theory to see if it works or not.

So... I have played with the clock formula from the original documentation and unfortunately the hour thingy is not very satisfactory. The screen below actually shows 1:51... this thing needs to be polished. Other than that, the clock is already animated in my route.

I use an animated analog clock in Kilmagranny. The coding for this is taken from the example in the former official OpenBVE Demo route with the textures being unique to the route.Always ask yourself how much time it is worth spending on minor details before wasting it. Unless any object is seen close enough and for long enough it may be possible to allow some inaccuracy or a little less detail in order to get on with the job.

Wise man yerself, graymac. You might indeed be correct it would be a waste of time. I might look into that in a bit of spare time (ala never ). If I find a modification, I am sure, you will use it as well...