[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.

[Csantucci]

Goku, on 05 June 2016 - 01:53 PM, said:

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.

OK, now I go to bed and I hope we find an agreement. Comment from other people is welcome.

[Csantucci]

So, thinking about extended features for routes, to be managed by the new RE and by OR:

If one goes towards the direction of using modified .w file formats for new features and objects (which can be a good solution IF the new RE supports them), taking as example the Multiple Car Spawners one possible solution could be:
1) within the route's OpenRailsFolder a WORLD folder is created, where the OR specific .w files reside;
2) it has to be decided wether these .w files contain only the OR specific parts, or the whole .w file; I'd say they contain only the OR specific parts, to spare space, but it is only a hypothesis;
3) the RE could have a setting modifiable at startup that defines whether the creation of files with OR specific features is enabled or not; if not, the related menu items, form items etc. are greyed out
4) again referring to the Multiple Car Spawners item, within the Car Spawners Property form an additional field to select the car spawner list name could be present (the name list can be derived by the RE from the extcarspawn.dat file)
5) a checkbox could be present in the same form; if not checked, the car spawner is only inserted in the OR .w file; if checked, it is also inserted in the MSTS .w file (with the MSTS format, and MSTS will display the cars of the default car spawner list for it).
6) referring to the format of the extended car spawner block, it could be as shown in my post #29, or it could have a ListIdx ( int ) parameter instead of a ListName parameter, where the RE gets the ListIdx from the extcarspawn.dat file. This way OR is faster in associating lists to car spawners at runtime.

This is a proposal.

[Genma Saotome]

The problem w/ side by side .w files (located anywhere) is referential integrity. Any way you look at it exists the possibility of something breaking whatever you use to tie the two files together. This is why interactives are so problematic to route builders (the workaround being you do them last and you never edit the roads and tracks).

The only real answer is you commit to using only one route editor and that editor either puts all the necessary rows related to road shapes in the one relevant world file or has very strong referential integrity (e.g. inserting a link marker into every UiD() set that is referenced) and uses that to properly manage the reference (e.g., a cascading delete that removes the link reference on both sides).

The problem with committing to Goku's route editor is that it's not done. There is no documentation of any kind and in some regards it's hard to use (e.g., the cross hairs are almost impossible for me to see). Anybody that goes back and forth between the two could break the reference.

If you are going to go ahead anyway may I suggest this method: Insert a bogus static shape entry into the .w file. Put a meaningful value into filename, something like Filename (CarSpawnernnn) which is your reference to the correct rows in whatever other file you are using to hold the real data. You'll need a shape file of the same name, maybe even placed as-if it were a KUJU car spawner. The KUJU editor will accept it w/o question and anybody that still uses Train.exe will get the original spawners, working as expected; The OR software will recognize it's something special and when found look in the correct place for it. The OR software will also have to control for any broken references. Both editors can place the static item (put it underground so it doesn't show in-game). If Goku is willing, he could write code that will add/change/delete rows in the "real" file. For those of us who don't yet use his editor the "real" file can be manipulated in an ordinary editor.

The same method would work for all other interactive that you want to "enlarge".

What you obtain from this approach is pretty important:

• Both editors can write the necessary Uid() entry into any world file w/o further problems.
  
• Both game programs can use that world file data w/o any further problems.
  
• The original car spawner data remains untouched.

The obligation placed on the OR software is:

• To provide a very simple shape for placement.
  
• To act correctly when discovering that special shape in a world file when its X and Z values match those of an existing car spawner (Y is vertical).
  
• To ignore the new feature when it cannot be matched up to a corresponding car spawner.

The requirements for GOKU are:

• To ensure the placement of this special static entry has a position value equal to an existing Car spawner UiD()'s X and Z position.
  
• To add, change. delete the relevant data in the new interactive file.

The requirement for using KUJU's editor:

• to copy/rename the special shape as many times as desired and to move them to the routes /shape folder.
  
• to add the special shape(s) to the routes .ref file.
  
• End user (or route builder) must hand edit the X and Z values in the special static files Position() field to match that of the car spawner. This is an extremely trivial matter for experienced route builder because that sort of editing is done all of the time. The steps can be easily done by any end user.

Last, don't hide the files. KUJU put interactive files in the root directory. IMO they should have used \Interactives (or some similarly purposed name). Come up with some suitable name and put them there.

It's not a perfect solution as the referential integrity problem remains but at least it is a solution that will work for both editors.

This post has been edited by Genma Saotome: 06 June 2016 - 11:18 AM
Reason for edit:: Added benefis & responsibilities

[Csantucci]

Following Goku's suggestion I've modified the data structure to get multiple car spawners.
The tentative new structure is described here.
The multiple car spawner lists file has remained as before, and an example is shown here

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" )[attachment=71538:extcarspawn.zip]
2
CarSpawnerItem( "US2Pickup.s" 6 )
CarSpawnerItem( "postbus.s" 13 )
)

The first "3" indicates the number of car spawner lists in addition to the default one. This means that the default carspawn.dat remains valid. The new file is called extcarspawn.dat and has to be inserted in an OpenRails subfolder within the route's folder.

A CarSpawner block within the .w file that wants to refer to an additional car spawner list must have following structure

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

If the CarSpawner block wants to refer to the default car spawner list, line ORTSListName must be omitted.

I have tested this new structure on an example and it works.

This arrangement does not cause problems if one wants to run this with MSTS. MSTS will ignore the ORTSListName line and will always use the default car spawner.

19/9/16 corrected one error in the attached file

Attached File(s)

•  extcarspawn.zip (340bytes)
  Number of downloads: 401

[Genma Saotome]

Is ORTSListName retained when KUKU's RE writes that world file to disk?