Elvas Tower: Odometer: Count Up/Down not taking effect until Reset - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Odometer: Count Up/Down not taking effect until Reset Is this intentional? Rate Topic: -----

#1 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 01 February 2025 - 11:13 AM

When the Odomoeter count direction is changed (Shift-Ctrl-Z), the change does not take effect until the counter is reset (Ctrl-Z). Is this intentional?
If it is not intentional, what would be the desired behaviour?
  • Show the value appropriate for the reference point associated with the count direction. For example, with a train of 4000 feet length, when switching from up to down at the count of 1000 (travelled), the value changes to 3000 (still to go).
  • Reset the counter (to zero when switching to count-up, to the length of the train when switching to count-down).
  • Continue from the value the counter was when Shift-Ctrl-Z was pressed.



#2 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 04 February 2025 - 04:07 PM

I have a PR up: https://github.com/o...rails/pull/1040

The main thing that was bugging me was that I reset the counter to clear a switch, then notice that it is counting up (and I don't remember the train length). With the PR, the direction-toggle can be done after the reset, and the counter will adjust, so that when it reaches zero, the train is clear of the switch.

PS: The odometer has a direction (based on the reverser at the time of the reset). Thus it can be used when running in reverse (without transposing numbers).

#3 User is offline   hehl 

  • Apprentice
  • Group: Posts: Active Member
  • Posts: 32
  • Joined: 09-January 24
  • Gender:Male
  • Simulator:ORTS
  • Country:

Posted 05 May 2025 - 06:18 AM

When a reversal point is reached, the odometer is automatically reset to zero, is that intentional?

I don't think this is the best solution in any case.

If the train passes through two track reversals using two RP, the information about the distance traveled is lost.

#4 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 10 May 2025 - 02:45 PM

View Posthehl, on 05 May 2025 - 06:18 AM, said:

When a reversal point is reached, the odometer is automatically reset to zero, is that intentional?


I did not test such a scenario, neither before nor after my change. I will have a look at it and report back.

#5 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 25 May 2025 - 03:44 PM

View Posthehl, on 05 May 2025 - 06:18 AM, said:

When a reversal point is reached, the odometer is automatically reset to zero, is that intentional?

I don't think this is the best solution in any case.

If the train passes through two track reversals using two RP, the information about the distance traveled is lost.


Thanks for pointing this out. I never thought of the reversal point scenario. That the odometer resets is definitely wrong. It should keep the value. BTW, in my scenario (Mullan Ash Grove Switching), the odometer resets to the train-length, not zero.

I am familiar with the North American use. There it is not an odometer, but a distance counter. It is used to determine when the train clears a switch, speed restriction, etc. Thus it is reset whenever it becomes of interest. For such scenarios, the counter should reduce when the train moves towards the reset point.

If the odometer is intended as a distance travelled count, then the odometer should always increase when the train travels in its forward direction. That seems to be the original behaviour. I will aim to restore this.

#6 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 28 May 2025 - 03:54 PM

View Posthehl, on 05 May 2025 - 06:18 AM, said:

When a reversal point is reached, the odometer is automatically reset to zero, is that intentional?


This also seems to be the behaviour before my changes (though I am observing that the odometer is reset to the train length, not zero).

I tried with the commit immediately before my change, and with the 1.5.1 release. In all cases, the odometer got reset to the train length at the reversal point (when stopped).

The odometer change is actually caused by a change in Train.DistanceTravelledM, not by anything in the odometer (MSTSLocomotive class). I have not yet found where or why Train.DistanceTravelledM is changed at the reversal point.

@hehl: What behaviour have you observed before my change to the odometer code?

Thanks...

Roger

#7 User is offline   C44-9W 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 133
  • Joined: 18-March 23
  • Gender:Male
  • Simulator:Openrails
  • Country:

Posted 04 June 2025 - 03:26 PM

I am not planning to make any additional changes. While the behaviour of the odometer at the reversal point is not as expected, the behaviour is unchanged and has been like that since at least 2014.

For future reference, here is the code that changes the Train.DistanceTravelledM variable.Why it is done this way (last change in 2013) I don't know. Method UpdateRouteActions(), file Train.cs, line 7454 (7319 in 1.5.1):

  if (oldDirection != nextRoute[newIndex].Direction)
  {
   
  	// set new train positions and reset distance travelled
      
  	TCPosition tempPosition = new TCPosition();
  	PresentPosition[0].CopyTo(ref tempPosition);
  	PresentPosition[1].CopyTo(ref PresentPosition[0]);
  	tempPosition.CopyTo(ref PresentPosition[1]);
      
  	PresentPosition[0].Reverse(ValidRoute[0][PresentPosition[0].RouteListIndex].Direction, nextRoute, Length, signalRef);
  	PresentPosition[0].CopyTo(ref PreviousPosition[0]);
  	PresentPosition[1].Reverse(ValidRoute[0][PresentPosition[1].RouteListIndex].Direction, nextRoute, 0.0f, signalRef);
  }
  else
  {
  	PresentPosition[0].RouteListIndex = nextRoute.GetRouteIndex(PresentPosition[0].TCSectionIndex, 0);
  	PresentPosition[1].RouteListIndex = nextRoute.GetRouteIndex(PresentPosition[1].TCSectionIndex, 0);
  	PresentPosition[0].CopyTo(ref PreviousPosition[0]);
  }
   
  DistanceTravelledM = PresentPosition[0].DistanceTravelledM;


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users