[Csantucci]

This MSTS feature is not yet present in MSTS. I'm working on it. It's not an elementary task, as it involves a good number of code parts.
Blueprint here https://blueprints.l...ted-speed-zones .

[Genma Saotome]

IMO, OR should have the ability for an Installation-wide feature, unless overwritten by an optional route-specifc feature, unless overwritten by an optional activity-level feature as a standard construct for loading up the internal objects with their data.

Speed limits is but one example. View distance, both near and DM is another. Use MassEmptyCar() as a required .wag parameter, MassLading() as either an optional .wag parameter for loaded, open top models and/or a default and an optional MassLading() in the Activity files (somewhere in the set of files) with the final total summed in OR is a third.

With that in mind, are all game data files processed by the loader?

[James Ross]

Genma Saotome, on 22 December 2015 - 10:25 PM, said:

IMO, OR should have the ability for an Installation-wide feature, unless overwritten by an optional route-specifc feature, unless overwritten by an optional activity-level feature as a standard construct for loading up the internal objects with their data.

Speed limits is but one example. View distance, both near and DM is another. Use MassEmptyCar() as a required .wag parameter, MassLading() as either an optional .wag parameter for loaded, open top models and/or a default and an optional MassLading() in the Activity files (somewhere in the set of files) with the final total summed in OR is a third.

With that in mind, are all game data files processed by the loader?

I'm not really sure what you mean here by "processed by the loader". All files read off disk should be loaded from the Loader Process, and all text-based Simis files must be loaded by the STFReader.

As for overwriting data from other files, this sounds like quite a tricky thing to construct as, presumably, you'd need to be able to specify how to reference any file from e.g. activities, if I understand you right. It may be worth noting that the Content Manager approach to loading data files does support a single level of "overlaying", in as much as the package you load an activity from will be checked first for the route, and then the bits within the route, etc., before scanning other packages for the content. In any event, I think this belongs in another thread if you have a proposal here.

[Csantucci]

I have now the modifications for the activity restricted speed zones ready. It required modifications in many points of the program, some of which let me sweat because referring to the calculation of the maximum allowed speed, complicating it (e.g. if within an activity restricted speed zone a standard speedpost is encountered, it must not be considered; however it must be remembered at the end of the restricted speed zone). Moreover these speed zones add a specific warning speedpost shape at some distance before the speed zone itself, than a start-of-zone speedpost shape and an end-of-zone speedpost shape. These objects must be "added" to the standard scenery objects present in the world files.
Working on this I also found what I believe were some bugs in computation of the max allowed speed in manual and explorer mode.
I want also to thank Rob for a direction he gave me to solve the final bug I had.

As the modification has some extension, before committing I'd like if someone could perform some tests in addition to the tests I did. Therefore I attach here the .exe and .dll files that must replace the original ones in release x.3404.


2/1/2016: new release to solve problems evidenced in the next posts(demo act for USA2 and standard act for JPN2)
3/1/2016 : further update to solve a minor problem in computation of max allowed speed
3/1/2016 : adjusted rounding to convert max temp restricted speed
4/1/2016 : patch removed because function uploaded in x.3406

[mirekkr]

Hi, Carlo!
So I've downloaded X3404 and applied your testing patch. I've created a simple activity on the default Marias Pass Route (see the Attachment). There are three resricted zones in the train's path (see picture in the attachment).
I'm afraid there's still something to do:
/1/ The 1st RestZone works fine, except that the RestZoneEnd shape should be green (speedpost.dat says: End_Restricted_Shape ( us2ResSpeed.s ) ); The RestZone Warning shape (yellow) is ok.
/2/ The 2nd RestZone is completely ignored.
/3/ The 3rd RestZone is marked by Warning sign, but ignored. The RestZoneEnd sign is missing.
I wish this helps you with your wonderful work.

And: HAPPY NEW YEAR to you and all the community!

Regards,
Mirek

Attached File(s)

•  Test_RestSpdZones.ZIP (17.52K)
  Number of downloads: 501

[James Ross]

Csantucci, on 29 December 2015 - 09:55 AM, said:

As the modification has some extension, before committing I'd like if someone could perform some tests in addition to the tests I did. Therefore I attach here the .exe and .dll files that must replace the original ones in release x.3404.
Runactivities.zip

I tried this out on the Hisatsu Line activity "Quake-Damaged Track" and all six markers (warning, begin, end for two zones) appeared, but there was no speed restriction shown in the Track Monitor. I'm not sure what bits are supposed to work but I observed neither a visual indication of the zone nor a change in speed limit.

[Csantucci]

Thank you. There is a problem with the direction, and it seems to depend to the orientation of the track. I have now some test activities (thank you Mirek and Eugen) and I will try to solve it.

[Csantucci]

OK. There were two problems:
1) a problem in the definition of the speedpost item's angle; to solve it the test activity I received from Eugen was essential;
2) a problem in parsing when one of the speedposts is missing in speedpost.dat (in route USA2 the speedpost shape definition for the start of the restricted zone is missing); for this the demo activity of mirek was essential.

In post #4 I have attached a new release of the modified files, always to replace in x.3404.

[mirekkr]

Carlo,
muuuuuch better now with my USA2-activity:
- all displayed values in Track Monitor are correct,
- BeginRestSpeed and EndRestSpeed signs are on the right place (it was not your fault when BegRestSpd sign was missing from USA2 route - I've added one from another route for testing purposes)
- but: the Warning sign is placed as follows:
-- the 1st one is placed some 0.3 mi before the beginnig of restricted zone (seems to me this is ok)
-- with the 2nd and 3rd restricted zones, the Warning sign is placed some 1.2 mi before beginning of the zone (which comes too much for me); see attached picture.

Thanks for your work,
Mirek

Attached File(s)

•  Test_RestSpdZone_Pict.ZIP (1.48MB)
  Number of downloads: 500

[Csantucci]

Hi Mirek,
that's the way MSTS does. If you run your test activity with MSTS, the position of the warning speedposts is the same as in OR.
The rule is as follows: the warning speedpost is located two Km before the start of the reduced speed zone or at the last node (switch or track start) before the start of the reduced speed zone: between these two positions, the nearest to the reduced speed zone start is selected.