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

[Goku]

Csantucci, on 18 September 2016 - 12:09 PM, said:

Following Goku's suggestion I've modified the data structure to get multiple car spawners.

Implemented in RE :) http://koniec.org/ts...SRE5_v0.622.exe

http://i.imgur.com/Tl1zoe6.png

Genma Saotome, on 18 September 2016 - 01:02 PM, said:

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

No. That's the motivation to use and help developing new RE. :)

Also it allows to easy and fast add new features, if all values are in one .w file. Syncing multiple world files would be difficult to do and prone to errors.

[Genma Saotome]

Goku, on 18 September 2016 - 01:25 PM, said:

Genma Saotome, on 18 September 2016 - 01:02 PM, said:

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

No. That's the motivation to use and help developing new RE. :)

IMO this is a very serious problem.

Don't get me wrong, I am delighted that somebody is willing to explore new features that are recorded in world files, something I've been advocating for years. So for that, good!

The problem is the both the incomplete nature of your program -- and by incomplete I mean missing features found in KUJU's RE, not meaning incomplete as something less that perfect. The feature can only be safely used on released routes or in routes where every KUJU RE function not matched in your program has been completed... which is basically to say just before release. Outside of those two it only creates the potential for screwing up a route under development.

James has spent much of the last 3 or 4 years squashing actions like this; I expect if he were around this week he'd already be shouting no. As I've been told no so many times I think I have a fairly good understanding of what causes him to say no. Maybe he'll surprise me when he learns of this but I don't expect that.

The other problem is how you work. You work on your own, doing what you want. This is not a criticism of you personally as what you do is pretty much what all of the OR developers do and is also consistent w/ many people involved in Open Source projects, so please don't take offense at my words as none are meant. The issue is the lack of collaboration in the creative design process. You know what you know, as does everyone else; working alone on most matters is highly limiting in the design stage. In this particular instance you did cooperate w/ Carlo -- a good thing -- but you, like most of the OR guys, have shown little inclination to do that routinely. That may not be much of a problem when you are trying to copy what KUJU did but IMO it is a problem for any new feature, any change to file content, especially where that file is still being read and written to by other programs.

My message is this: IF you can collaborate on ideas (well before coding), do so. Whatever you do, especially if it is done w/o such collaboration, could be at risk for being discarded IF the OR team ever gets around to designing a new data structure. IOW, absent collaboration they'll have no equity invested in your solution. Expect push back on any change tot he content of a KUJU designed file.

Goku, on 18 September 2016 - 01:25 PM, said:

Syncing multiple world files would be difficult to do and prone to errors.

I agree (and KUJU proved it for us). The ideal technical solution for a number of these issues is to put all of the data into a relational DBMS as it is too hard to do certain things right without such tools. Stuff like the list of displayed track shapes and the list of track shapes in paths is a many to many relationship of linked lists where any change to the former can have a disastrous effect on the later. But of course a DBMS introduces other issues.

last thought: Nobody likes to be pushed into things. The acceptance of the program should depend on what it does right, not on what it breaks.

[Goku]

Quote

IMO this is a very serious problem.

I see nothing wrong if OR will be able to use also second .w file for OR features, so you will be able to use new features in text editor and still use MSTS RE. But my editor won't support it ( in the future it will be possible to combine these files into one if someone will decide to switch to my editor ).

Quote

I mean missing features found in KUJU's RE

What missing features? I know one: Gantry. You always mentioned object sorting, point terrain editing and it's done.

[Csantucci]

Goku, on 18 September 2016 - 01:25 PM, said:

Implemented in RE :) http://koniec.org/ts...SRE5_v0.622.exe

That's excellent Goku, thank you!
I updated the blueprint and here are the .exe and .dll files to be replaced within x.3627 to test the feature.
 Multiplecarspawner.zip (1.16MB)
Number of downloads: 415
Now I hope this is OK for James to approve the blueprint. If there are still refinements needed, I'll see if I can implement them.

And here some rationale about what has been done, which is also a reply to Dave.
I had stopped working on this feature, because OR features could not rely on a development tool that was not open, with the risk that such development tool would die, or become strictly proprietary, or go towards directions incompatible with OR, leaving such feature unsupported.
This has radically changed now that TSRE is licensed under the GNU license. Even if Goku would go his own way, incompatible with OR, the sources are there and starting from them it is possible to get a TSRE version compatible with OR, and even growing with it.
By the way this specific case showed that a fruitful cooperation between Goku and the OR development team is possible, providing simple and fast solutions.
My opinion is that TSRE is becoming the de-facto route editor for OR, even if it is still a work in progress.
So I don't agree with the objections of Dave:
- TSRE is still work in progress? OR is this too. Waiting that TSRE work is 100% complete to implement new functions is the same than saying that one does not want to use TSRE to implement new functions
- Goku has his own mind and could go his own ways? Well, in this case he has been cooperative and also very fast. Not only, he was also propositive and in fact suggested a "cleaner" solution. If Goku won't be cooperative in the future (which I hope won't succeed) there is always the escape way to autonomously proceed from the TSRE source files.
- OR already has additional features that are "deleted" using the standard MSTS development tools to modify the files; this is true both for the cabview editor and the activity editor; for the new feature under discussion there is an advantage: files are generated by a development tool, and don't need to be hand edited. Moreover:
- This functional improvement can still be simply achieved by hand editing the .w file. In fact, when I tested it, I did so, because I didn't have yet the updated TSRE.
- With this improvement standard MSTS car spawners are still interpreted correctly both by OR and TSRE, which in my opinion is mandatory, and moreover the OR-specific car spawners don't cause problems to MSTS, which in my opinion is desirable, but not mandatory.

Finally, Dave, I am always very thankful to you for hosting OR discussion and in general appreciate your contributions, but I was quite annoyed in reading these words against my development: "James has spent much of the last 3 or 4 years squashing actions like this; I expect if he were around this week he'd already be shouting no. As I've been told no so many times I think I have a fairly good understanding of what causes him to say no. Maybe he'll surprise me when he learns of this but I don't expect that."
That's not the way to express disagreement. I'm spending my time generating new features and must read that.

[Genma Saotome]

To be clear guys I am NOT opposed to adding brand new features. I welcome it. I've been asking for new features for years (and being told no almost all of the time). All I was trying to do is point out risks, both technical and organizational and express some opinions on where an improved development process could help minimize those risks (I do have nearly 30 years in the software business so I'm not just talkin nonsense). If those risks can be properly managed, great -- I have lots of suggestions for new features that would also go world files.

So please accept my apology for not writing as clearly as was necessary.

Allow me to reiterate my concerns:

• AFAIK, a change of this nature has not been authored before.
  
• To whatever extent a route builder has to return to KUJU's RE after adding anything genuinely new to any file written by RE is to create a very risky situation for that route builder. Speaking as a long time route builder, new risk is absolutely the last thing we wish to add to the already rather difficult and unstable work environment we use.
  
• There are far too many new features in OR that have been added with insufficient input to the coder and/or consideration when provided after the fact. Such inputs are normally is handled in the design phase. All of you guys need to up your game, especially with regard to changes to the contents of the various files where said changes would reasonably cross the opinions, ideas, and desires of others.

That's all project stuff... nothing about you guys in particular or this specific feature (which I find interesting).

[Genma Saotome]

Goku, on 19 September 2016 - 01:22 AM, said:

What missing features? I know one: Gantry. You always mentioned object sorting, point terrain editing and it's done.

Were you not also asking for help to do signals and mileposts or did I misunderstand?

Let's be clear about this Goku: The issue is equivalent functionality and compatibility. To whatever extent your software doesn't provide an equivalent to KUJU's functions is a reason not to use your software -- obviously one cannot use it for those functions, right? So what';s the list... Gantrys, signals, mileposts... what else? All of those involve writing something to the world file and if they're not in your software we have to go back to KUJU's RE to do the job.

Switching back and forth from one editor to the other is doable... and even desirable for an improved work process. An example is your programs easy way to copy the qdirection of one object and paste it to another. KUJU's RE doesn't do that and your solution is easier to use than doing it in a text editor. It's a better work process. But until, what, yesterday?, you could not copy / paste position so if you needed to do both you could not and so there was no reason to use your software for when one is doing that kind of work.

Trying to force people to use your software is not the answer, equivalent functionality and compatibility is. And, FWIW, even with that criteria met, one has to be able to SEE stuff. I havn't bothered to complain about colors and lighting because it's not important now but eventually it should be fixed. I have mentioned terrain grid lines, item selection boxes, forest boundaries. Let me add the cursor and brush size for any terrain edits. On these points I'm astonished to be saying that KUJU's ancient, utterly crappy, 16 bit VGA resolution RE is better. That should not be the case.

My point here is not to beat you up or to discourage you from continuing, far from it -- I want you to continue and be successful at this. I'm trying to give you candid feedback that, if you consider what I'm saying, will help you make your product better.

[Goku]

Genma Saotome, on 19 September 2016 - 10:33 AM, said:

Were you not also asking for help to do signals and mileposts or did I misunderstand?

I asked for testing but no one wants. Everyone waits when it will be fully tested on dozens of new routes ... but how? I have to stop working on new features and go build adwanced routes instead?

Genma Saotome, on 19 September 2016 - 10:33 AM, said:

Let's be clear about this Goku: The issue is equivalent functionality and compatibility. To whatever extent your software doesn't provide an equivalent to KUJU's functions is a reason not to use your software -- obviously one cannot use it for those functions, right? So what';s the list... Gantrys, signals, mileposts...

You can use 'stick to track' or 'clone and transform' as a replacement for gantry (not efficient). I tested signals and mileposts on very simple route and they worked fine, but I know that everyone else ended with broken signals or even broken route. So it needs testing and fixing bugs.
So, you can do everything in my editor you can do in MSTS RE, it only needs bug fixes.

Genma Saotome, on 19 September 2016 - 10:33 AM, said:

Trying to force people to use your software is not the answer, equivalent functionality and compatibility is.

I'm not forcing them. There are two options:
1. new features incompatibile with MSTS RE
2. no new features at all

I know you don't like the first option, but for you it is not worse than the second.

[Csantucci]

James, could you kindly approve the related blueprint here https://blueprints.l...r-spawner-lists ? If there are objections I'm ready to discuss them.

[James Ross]

Csantucci, on 19 October 2016 - 11:14 AM, said:

James, could you kindly approve the related blueprint here https://blueprints.l...r-spawner-lists ? If there are objections I'm ready to discuss them.

I'm (as predicted by Dave) not yet happy with the changes to world files, but please let me fully catch up on this thread and I'll articulate my views in more detail soon.

[Csantucci]

James,
thanks for considering this.
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.