[James Ross]

Csantucci, on 19 October 2016 - 11:58 PM, said:

Let me express some thoughts:
OR already and successfully provides extensions for following file types:
- .eng
- .cvf
- .sms
- .act
- .trk
- sigscr.dat
- sigcfg.dat
- in some way, tsection.dat
and maybe I've forgotten something.
The proposed extension does not damage MSTS operation.
The proposed extension does not even need manual editing of .w files (even if that remains easy and possible - I proceeded that way), because TSRE may handle extensions to .w files, and in this case does already handle this extension.

So in my mind implementing controlled extensions to .w files is within the OR development path.

My primary concern, and it is a diminishing one with TSRE around, is that world files (.w) are files with complex interactions with other files - like Dave says, it's basically a database stored across multiple different files (.w, .tdb, etc.) - and so I believe tools will be the only way many content creators can change them.

The file types above are either completely hand-made (e.g. engine/wagon files [.eng, .wag]) or relatively simple and mostly self-contained (e.g. track files [.trk]). Activity files are a little problematic, however, they can be hand-edited and individually avoided in the tools. If you have customisations in any world files, you lock out the entire RE functionality, unless you keep copies of your changes and reapply them manually each time (assuming of course they don't somehow break the RE during loading).

I would suggest something more like this:

...\World\w-001234+001234.w

        CarSpawner (
                UiD ( 532 )
                CarFrequency ( 11 )
                CarAvSpeed ( 20 )
                TrItemId ( 1 0 )
                TrItemId ( 1 1 )
                StaticFlags ( 00000100 )
                Position ( -601.849 15.6006 -929.784 )
                QDirection ( 0 0 0 1 )
                VDbId ( 4294967295 )
        )

...\World\OpenRails\w-001234+001234.w

        CarSpawner (
                UiD ( 532 )
                ORTSListName ( "List1" )
        )

The two files are then merged when loaded, and we can discard the OpenRails version if the type doesn't match for that UiD.

This has the downside that the two may get out of sync if UiDs change (but we can detect some of that and log warnings), but benefits that the MSTS RE won't be out-of-bounds and that you could override any property in the OpenRails version (such as using higher-quality versions of shapes).

[Goku]

Please allow two solutions. Your is very good if one wants to add new features in text editor and use old RE. But allow placing new attributes in main .w file too.

[Genma Saotome]

James Ross, on 23 November 2016 - 02:15 PM, said:

... and that you could override any property in the OpenRails version (such as using higher-quality versions of shapes).

Curious choice of example... what do you mean?


FWIW Routeriter does have a function to renumber UiD's in all world files so if you go forward with this you should probably mention somewhere that this one feature will break if you use that function.

I've used it several times to eliminate gaps in the UiD() values, something occasionally necessary when using KUJU's train.exe for anything. You have to re-create the .tdb/.rdb afterwards. It works, but then at the time I used it there were no multi-file interactives present so I cannot say anything about that situation.

[Csantucci]

James,
thank you for having considered that. I will check what it means implementing that, when I'll have finished other current tasks.
However, what do you think about Goku's proposal to have the two solutions available? I'm in favour of that, and it's already implemented :) (not in the uploaded version of course).

[edwardk]

Since the topic is covering spawning cars, I have to wonder if it would be possible to create a new car model with animated wheels?

Edward K.

[Csantucci]

I have created a patch implementing James' suggestion.
Here is an example of the "modifying" worldfile w-011008+014318.w (for route USA1, first car spawners after Philadelphia station), to be inserted into an Openrails subfolder within the World folder:

SIMISA@@@@@@@@@@JINX0w0t______

Tr_Worldfile (
		CarSpawner (
			UiD ( 532 )
			ORTSListName ( "List2" )
		)
		CarSpawner (
			UiD ( 533 )
			ORTSListName ( "List3" )
		)
	)

Here is again the example of file carspawn.dat, to be inserted into an Openrails subfolder within the route's folder:

SIMISA@@@@@@@@@@JINX0v1t______

3
CarSpawnerList(
ListName ( "List1" )
2
CarSpawnerItem( "car1.s" 4 )
CarSpawnerItem( "postbus.s" 4 )
)
CarSpawnerList(
ListName ( "List2" )
3
CarSpawnerItem( "policePHIL.S" 6 )
CarSpawnerItem( "truck1.s" 13 )
CarSpawnerItem( "postbus.s" 6 )
)
CarSpawnerList(
ListName ( "List3" )
2
CarSpawnerItem( "US2Pickup.s" 6 )
CarSpawnerItem( "postbus.s" 13 )
)

I inserted some non-legacy car shapes here above.

Here are the .exe and .dll files to be inserted into x.3672 to get the function running


And here are the patch file and the additional ORTSformat file needed


James' approach is of general use, and I implemented it that way.
With this patch any Pickup, Transfer, Forest, Signal, Speedpost, LevelCrossing, Hazard, CarSpawner, Static, Gantry may have parameters modified or added by the "modifying" .w file. It is e.g. possible to replace the shape foreseen in the original .w files with another one, without modifying the original .w files.
The implementation intrinsically allows for the addition of new OR-specific parameters both in the "modifying" .w file or in the base .w file.

Warnings If using the additional .w file: take into account that, if the route is edited with a route editor, UiDs could change and so the additional .w file could be out of date and should be modified.
If adding the extended car spawner parameter within the base .w file with TSRE5: if the route is subsequently edited with the MSTS RE the additional parameters are deleted; if the route is passed to a route checker, the additional parameters could be deleted.

I hope that this version of the extension (which is both a car spawner extension and the possibility to extend and modify specifically for OR .w file objects, without needing to modify the base .w files if not desired) can be approved by James.
3/12/16 Approval obtained

I've not yet tested modifying all object types mentioned above. I foresee to do that only after approval of the approach.
5/12/16 More comprehensive testing performed.

28/11/2016 new release managing also static and gantries
5/12/2016 attachments removed because function uploaded in x.3680. Additional car spawner file in Openrails subfolder renamed to carspawn.dat, accordingly to James' requirement.

[James Ross]

Goku, on 23 November 2016 - 02:26 PM, said:

Please allow two solutions. Your is very good if one wants to add new features in text editor and use old RE. But allow placing new attributes in main .w file too.

I dislike allowing changes to the main .w files for the reasons outlined earlier; it needs to be made very clear in the manual of both OR and TSRE that utilising new features in this way will make the whole route incompatible with MSTR RE. That may be fine for some people but I don't believe we're near the point that that is most people.

Genma Saotome, on 23 November 2016 - 02:45 PM, said:

Curious choice of example... what do you mean?

I was thinking, if you have a route that works in MSTS but you wanted to update it with newer models and such, which maybe don't all work in MSTS, you could use this to keep it as one route - but OR gets all the new scenery while MSTS only gets the bits which are compatible. Probably makes more sense when someone is just updating a route for themselves, but still wants to be able to use it in MSTS.

Genma Saotome, on 23 November 2016 - 02:45 PM, said:

FWIW Routeriter does have a function to renumber UiD's in all world files so if you go forward with this you should probably mention somewhere that this one feature will break if you use that function.

Yeah, that needs to be clearly documented in the OR manual.

Csantucci, on 24 November 2016 - 12:23 AM, said:

thank you for having considered that. I will check what it means implementing that, when I'll have finished other current tasks.
However, what do you think about Goku's proposal to have the two solutions available? I'm in favour of that, and it's already implemented :) (not in the uploaded version of course).

My concern for having both options is that people will not necessarily know or understand the consequences of editing the world files in-place - it's how they've edited other files, and certainly the easiest way - so they may unexpectedly find themselves unable to use the MSTS RE or maybe it will load but silently delete their extra lines.

The OR documentation should definitely make this clear, but I'll still be worried about it.

[James Ross]

Csantucci, on 27 November 2016 - 12:48 PM, said:

Here is again the example of file Extcarspawn.dat, to be inserted into an Openrails subfolder within the route's folder:

Do you mind if we just call it "carspawn.dat"?

Otherwise, and with the comments above, I'm okay to go ahead with this.

[Goku]

James Ross, on 03 December 2016 - 02:44 AM, said:

I dislike allowing changes to the main .w files for the reasons outlined earlier; it needs to be made very clear in the manual of both OR and TSRE that utilising new features in this way will make the whole route incompatible with MSTR RE. That may be fine for some people but I don't believe we're near the point that that is most people.

Modified route is not "whole" incompatible with MSTS RE. You can still extend your route using MSTS RE. Just need to remember not edit modified .w files.
I think that making a route in MSTS RE requires so advanced knowledge that any user doing this will know that if he wants to use MSTE RE and new OR features, he need to use second .w files for new features instead of one .w file.

[Genma Saotome]

Goku, on 03 December 2016 - 11:13 AM, said:

Modified route is not "whole" incompatible with MSTS RE. You can still extend your route using MSTS RE. Just need to remember not edit modified .w files.

That is true but I think it is wholly unrealistic to expect route builders to recall all tiles that have been extended in such a manner. With multiple editing tools I do move back and forth between editors depending on which has the better function for what I need to do. It'll be easy to goof and touch something in one of those tiles.

Goku, on 03 December 2016 - 11:13 AM, said:

I think that making a route in MSTS RE requires so advanced knowledge that any user doing this will know that if he wants to use MSTS RE and new OR features, he need to use second .w files for new features instead of one .w file.

Why not use a bogus static shape as a flag to go get another "advanced" .w file? Maybe a .wor or orw file. Use something like ExtraW.s having one poly and a texture file that is transparent as your flag. MSTS RE will regard it as just another static file. In its own way it is analogous to the Include() statement. The loader can be set to note it and load that extra file into the .w data stream -- or, if performance of the loader, in its own thread, is a concern than use a post editing script to append the "advanced" .w file to the end of the KUJU file. It'll be safer all around. An extra task like that is minor compared to the consequences of having your .w files getting goofed up.

Do understand it's not just a car spawner your dealing with here, it's ALL possible enhancements. With each additional new feature it becomes ever more problematic to always avoid touching those specific tiles.



FWIW, long term I recommend the future UiD data include a proper linked list feature so things like individual track shapes have a "UsedBy( UidNbr, Type )" and the corresponding interactive entry has a clearly labeled "Uses ( Uid, Type )" to ensure no editing session breaks a link w/o (1) telling the person doing the editing and (2) properly handling the disconnection. The inclusion of "Type" may not be necessary but what I was thinking is what type of object is at the other end of the link.