[Jovet]

Csantucci, on 04 June 2016 - 05:34 AM, said:

I think also that Joseph's proposal is a bit restrictive, and also changes the existing logic for the carspawners.

I thought my idea was less restrictive, since 1) it could quickly be applied to any route without figuring out specific world files and spawner locations; 2) car spawners should already know what their associated shape file is; and 3) it can co-exist as a level underneath the specific-spawner-by-world-file list methodology.

[Goku]

Csantucci, on 04 June 2016 - 05:34 AM, said:

and could be generated with a simple upgrade to the Goku RE

My Editor will support new features as extension to existing formats, no additional weird files and folders. I do not like this idea. No workarounds. MSTS ignores additional parameters.

[Genma Saotome]

I agree w/ Goku's assessment (and opinion) with one exception: If you switch back and forth between KUKU's RE and his you'll lose the rows of data holding the new stuff. IMO Goku's editor is close to equivalence with KUJU's editor but there is still enough that is missing that keeps me using KUJU's RE.

[Goku]

Good idea is do it like ENG files. If you want to use old editor, you use additional .w file for new stuff. But if you use new editors, new stuff is simply in the one .w file.
I can do in my editor loading both files, so if someone decide go from old editors to new - no problem.
But to avoid mess - save only into one w file.

[Csantucci]

I'm not adding new lines in the MSTS files. They remain fully unaltered.
Goku, what is weird or not does not depend on your opinion. At least I make source code available for what I do, so that at any moment, if there is agreement, things can be changed. You don't make source code available, at least up to today.
Of course you're free to do what you like, and I appreciate very much your editors, but I hope you'll do extensions for OR in a coordinated way with the OR community, as I do. So, what is your proposal to manage extensions for car spawners? As of now the OR include code isn't able to manage files like the .w file, that can have also a binary format.

[Goku]

Csantucci, on 05 June 2016 - 09:34 AM, said:

As of now the OR include code isn't able to manage files like the .w file, that can have also a binary format.

Can you tell more, because I don't understand.
1. What include.
2. There is no tool that writes binary .w files. RE uses text, my editor uses text.

[Csantucci]

That's true that also the MSTS RE generates text files, however using tools like Route Riter you compress the .w files to binary format, and usually that is the format that is used to distribute routes (to spare disk space and I think also to speed up loading). Such type of files is parsed in OR with the "SBR" parser, that is able to handle both binary and text files. This parser does not manage files using the "include" feature (explained in paragraph 8.14 of the manual), which is used to add OR-specific parameters to an .eng file without needing to duplicate it entirely. The "include" feature instead is used by the "STF" parser, that is used for text-only files.
This "include" method could be used also e.g. to replace some car spawner blocks with extended car spawner blocks, but, as said, OR does not manage the "include" feature for this type of files.
From your words I don't understand if the OR-specific .w file you mean should completely replace the old MSTS .w file, or should only contain the modified information.

[Goku]

W file - only msts objects.
Another file - new objects, but the same syntax like original W file.
If you want to compress W files using RR, you will compress only compatibile W file.
Iif you will use my editor, compression will not be available for now. I don't think it is a problem. Now loading text files is very fast. I've done some tests with my engine and results are very similar.

Quote

This parser does not manage files using the "include" feature (explained in paragraph 8.14 of the manual), which is used to add OR-specific parameters to an .eng file without needing to duplicate it entirely.

OK. I was thinking that OR just checks if the other file exist.

[Csantucci]

So you suggest that, e.g., your OR .w file could include blocks like this one?

	CarSpawner (
		UiD ( 533 )
		CarFrequency ( 10 )
		CarAvSpeed ( 20 )
                ListName ( "List1" )
		TrItemId ( 1 2 )
		TrItemId ( 1 3 )
		StaticFlags ( 00000100 )
		Position ( -604.498 15.6084 -929.761 )
		QDirection ( 0 0 0 1 )
		VDbId ( 4294967295 )
	)

where ListName is the name of one of the additional car spawner lists, which are included in extcarspawn.dat (I've added a new ListName ( string ) parameter for every car spawner list)?

[Goku]

Something like this. My idea is to keep the same format for new objects, not making dozens files and data structure for every new stuff.