Elvas Tower: starting with u2019.09.24 no force in dynamics - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

starting with u2019.09.24 no force in dynamics Rate Topic: -----

#11 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,889
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 15 October 2019 - 04:06 PM

Hi Steve,

View PostEldorado.Railroad, on 15 October 2019 - 05:45 AM, said:

May I very politely suggest that you consult your users before making changes like this. It saves your valuable time by not doing anything until you find that either nobody cares!(go ahead and make that change) or you have found out that indeed it does affect users who depend on certain things NOT changing.

New, and additional features are always welcome, changes due to ones personal preferences may not be as welcomed, especially if users are not consulted about them.

Thanks for your feedback and suggestions.

To set the record straight, the OR code is very complex, and is poorly documented in terms of the of where items (or functionality) might be logically related or linked. Hence when making changes it is quite possible to make a change in one location, which can then impact the operation in another area of the program. This is the reason that an Unstable version is used so that any bugs that might appear can be identified and corrected as appropriate.

A change was introduced to improve the code by clearly separating motiveforce and dynamicbrakeforce values, and thus make it easier for developers to interpret and read the code functionality. As a result it introduced a change in another part of the program that was not identified when the code was amended.

As can be seen from earlier in this thread a potential problem was identified, and raised. I then expressed my personal opinion (as is my right as a community member) as to whether it was felt necessary by other members that it needed to be corrected back to the previous functionality. The feedback and consensus was that it should be, and consequently it has now been restored to the previous operational functionality.

So in this case, the change was not introduced as a personal preference, and a consultative review process was undertaken.

In order to ensure that OR is continually improving, I believe that it is important from time to time to review the functionality and confirm that it is either still appropriate, or alternatively it needs to change. This thread has demonstrated this process in action.

Thanks again for your input.

  • 2 Pages +
  • 1
  • 2
  • 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