[Csantucci]

cesarbl, on 03 January 2022 - 03:30 AM, said:

IIRC ThrottlePercent, DynamicBrakePercent and AccelerationMpSS are more recent than the TCS using the respective Locomotive() calls.

Yes, as well as the hook for CurrentElevationPercent.

[James Ross]

Serana, on 02 January 2022 - 07:10 PM, said:

Until now, for the French TCS scripts, updating has not been a problem: since I started creating the French TCS script, I regularly made updates to the scripts (39 versions since the creation).
Each time, I updated a topic on the ActivitySimulatorWorld forum (the French MSTS/OR community forum) to indicate that a new version was published, with a change log and a link to the ZIP file on Github. I extremely rarely have people mentionning problems during an update.

What about content created using one of your scripts?

Do you honestly expect every single user of derivative content to keep it up to date?

I do not.

Serana, on 02 January 2022 - 07:10 PM, said:

For the future, I am thinking of creating an updater... but the best way would be to have a package manager in Open Rails based on a Github repository (containing only metadata in JSON format which will refer to the real download website).

But that would mean we would have to manage a content metadata repository... or to give write access to trusted maintainers (for example, the manager of a OR content website that we trust).

At that point it might as well be part of Open Rails itself.

roeter, on 03 January 2022 - 12:38 AM, said:

In the call to the TCS scripts, the variable 'locomotive' (type MSTSLocomotive) is passed as parameter. This provides direct access from within the script to all data in that class. But MSTSLocomotive is a child of MSTSWagon, and through MSTSWagon there is access to Train, and through train to Signals.

gpz, on 03 January 2022 - 01:53 AM, said:

This function is a huge mistake!!!

Yes, adding access to anything beyond the scripting interface data structures is a monumentally bad idea for the reasons Rob listed. This should never have happened and I am very disappointed by it.

gpz, on 03 January 2022 - 01:53 AM, said:

EDIT: I created a PR of it, I would like it to be merged ASAP. (It must have been done before v1.4 release actually.)

Thanks so much for doing this, but please can you rebase this onto "release/1.4" and target that branch in the PR, so that we can do 1.4.1 containing this?

cesarbl, on 03 January 2022 - 02:24 AM, said:

I've had a look to publicly available TCS scripts and almost all of them use the Locomotive() function, so removing it would cause ALL of them to stop working. Taking into account that those scripts only do simple calls (reading and writing controller values), maybe an empty hook with the used functions can be created so at least the scripts compile. I don't believe it is nice towards users that every TCS script stops working.

I think it would be valuable if there are a few common things scripts are doing with their Locomotive access. We cannot get everything, and should not even try, because there will be many unknown things broken when we fix this monumentally bad idea.

Csantucci, on 03 January 2022 - 03:33 AM, said:

I've just modified and uploaded all my scripts, in order not to use Locomotive() (I had already removed almost all references). But as I'm against removing that hook, I leave to someone other the responsibility to decide to remove it and to perform the action, and, as already stated, I will keep it in ORNYMG.

Thank you for updating your scripts!

I am very disappointed that you cannot see why this is such a monumentally bad idea in a scripting interface, though.

[Serana]

James Ross, on 03 January 2022 - 08:23 AM, said:

What about content created using one of your scripts?

The scripts are not included in the trains but in a separated directory called common.script. Content creators are telling the users in their installation instructions to download the ZIP file on Github and decompress it in the TRAINSET directory.
So, when you update the scripts, you update them for all trains.

James Ross, on 03 January 2022 - 08:23 AM, said:

Do you honestly expect every single user of derivative content to keep it up to date?

I do not.

That's what is done in the French community. Since the users are well informed, they can update the scripts easily. It's just a ZIP file to decompress in the right directory. That's not difficult and that's probably one of the easiest modding task.

For the French content, it is usual for older locomotives to not include cabviews and sounds. Users are often led to install them with instructions which may include ENG file modification.
So the script update is really easy compared to this.

[Csantucci]

About removing the Locomotive() hook:
What has occurred with the AWS script demonstrates that also scripts written without that hook can have their compatibility broken. The concept therefore is another one, that is writing code with care about compatibilities. And that should be true also for modifications to the OR core code. As stated more than once, I am against reshuffling working code or data structures, and find it is sometimes wasted time. So, to make a trivial example, I'm expecting that e.g. Locomotive.ThrottlePercent should always remain Locomotive.ThrottlePercent in the OR code.
AFAIK, scripts are written by people who know also the internals of OR, and that have even contributed to such internals: gpz, cesarBL, Serana, Ryan, myself. To write scripts you must know C#, it's not like modifying an .eng file. So I'm expecting such type of people to use with care the freedom that a hook such Locomotive() could provide.
Therefore removing such hook restricts freedom in writing scripts; I'm using more measured expressions than someone else here, and will tag removing the hook simply as an error.

I won't reply further about this matter (Locomotive()).

[gpz]

Carlo, please accept, that all the others think that refactoring the existing code is a key part of keeping it maintainable for the future, by designing more transparent and clear data structures, that serve the continuous development better. Even if you think it is futile, you must keep in mind that the other developers will do that, so you must act in a way that doesn't make it impossible.

The problem with the scripts is not that it would not be written by people knowing the internals. The problem is that the source code is spread to users not willing to overwrite that file with a newer version ever again potentially, so the written code is stuck there, forever. So we cannot allow them to store anything, that forbids us to change our part. Everything is about the ability of the control of our own code base. Scripts must not contain any code that influences our freedom to change ANYTHING in our own codebase.

I just don't understand how you don't see this. To me it is extremely trivial.

[roeter]

I fully agree with Peter's statement.
A large part of the code which is relevant to scripts (signalling, train control, physics) was a new design, developed from scratch some 10 years ago. Other parts were based on code which was created before that. Time has shown that this new design has flaws. Some flaws could be addressed within the existing structure, but others can not be corrected without extensive changes. Furthermore, we have learned new functions etc. which would improve that design.
Also, the code has been growing ever since, adding to the existing structure. There comes a time when the existing structure can no longer cope with further additions. The existing design may also be a severe handicap for new functionality.
Software is not created for eternal use. There comes a time when the original design becomes too much of a burden for further development, and when it starts to collapse under the weight of all the new additions. At that stage, a thorough redesign taking in all the lessons learned becomes inevitable. Given life, time and opportunity, the first steps for that redesign will be set this year. And that will affect data structures, that is inevitable.

Regards,
Rob Roeterdink

[James Ross]

Serana, on 03 January 2022 - 03:14 PM, said:

The scripts are not included in the trains but in a separated directory called common.script. Content creators are telling the users in their installation instructions to download the ZIP file on Github and decompress it in the TRAINSET directory.
So, when you update the scripts, you update them for all trains.

Okay, so it's more like its own piece of content rather than embedded in another piece.

Nevertheless, I consider it unlikely that a user will upgrade content, so we must build things to accommodate that.

That means we need to add the new functionality to the TCS script interface without breaking the original AWS script.

Csantucci, on 04 January 2022 - 12:52 AM, said:

What has occurred with the AWS script demonstrates that also scripts written without that hook can have their compatibility broken. The concept therefore is another one, that is writing code with care about compatibilities. And that should be true also for modifications to the OR core code. As stated more than once, I am against reshuffling working code or data structures, and find it is sometimes wasted time. So, to make a trivial example, I'm expecting that e.g. Locomotive.ThrottlePercent should always remain Locomotive.ThrottlePercent in the OR code.

There is critical difference between the compatibility problem with the AWS script and the "Locomotive" hook:

• For the AWS script compatibility, we can make the change in a compatible way - we made a mistake but we can fix it to be compatible
  
• For the "Locomotive" hook, it is impossible for us to stay compatible

Csantucci, on 04 January 2022 - 12:52 AM, said:

Therefore removing such hook restricts freedom in writing scripts; I'm using more measured expressions than someone else here, and will tag removing the hook simply as an error.

Removing the "Locomotive" is a deliberate decision to restrict freedom in scripts to make it possible to maintain compatibility (not guaranteed but possible).

This should not need to be an official ORMT policy but I am quite happy to put down an absolute policy here; exposing any non-scripting classes/structs to scripts is not allowed, ever.