[Csantucci]

My 5 cents.
Compatibility of OR towards MSTS means that OR must be able to run content developed for MSTS, and not vice-versa.
In parallel, compatibility of TSRE5 towards MSTS RE and MSTS means that TSRE5 must be able to accept route files developed with the MSTS RE, and it does not mean that TSRE5 OR extensions must be able to be recognized and left unaltered by the MSTS RE. TSRE5 is a product for OR, as Goku says. .
Re utilities to check and restore route inconsistencies: these utilities haven't been available since MSTS was published, but were created later, following needs that arose. What are the needs, when a developer uses TSRE5? We don't know yet, but I expect they will be lower than those using the MSTS RE, because I don't think it's Goku's purpose to develop a package that easily allows for buggy files, or that easily loses pieces of work as it was with the MSTS RE. Goku works interactively with route developers, and so can intervene where needs for more data consistency arises.
I think that having both implemented James' solution, which is very general, and also the possibility to have the additional fields in the main .w files, is the most general solution, that can be well suited for the intermediate phase, where someone will still use the MSTS RE, and for the final phase, where only TSRE5 will be used.
And waiting for a "new" format for route files is the best way to stop evolution of OR, because that would require a much higher development effort, which the actual development team isn't able to afford.

I am confident that wisely extending the actual file formats, and maybe adding some simple others, not for replacement but for additional function, can provide much space for the OR evolution.

What I would ask Goku is that TSRE5 recognizes the w. file chunks within the World\Openrails subfolder.

One comment to Goku's words: while it is true that James' solution could easily allow also to insert new items in the .w file (e.g. a new car spawner or a further static object), as of now I have implemented only the possibility to add or replace parameters in items that already exist in the base .w file.

I also think that with the same data structure it could be possible to have additional .w file chunks linked to specific activities.

[Goku]

Csantucci, on 06 December 2016 - 01:22 PM, said:

What I would ask Goku is that TSRE5 recognizes the w. file chunks within the World\Openrails subfolder.

My editor will include support for additional .w files in openrails subfolder. I can do this even in next version. But readonly. For example if someone will want to import these values to main .w file.
Saving attributes to different world files will not be possible.

Saving whole objects to different world files - maybe? If OR will use "additional .w file chunks linked to specific activities". I think it's interesting idea.

[Genma Saotome]

Goku, on 06 December 2016 - 11:26 AM, said:

No. This is not a solution. Beside it is extremaly ugly, it will not work.
Where in your solution is connection to existing carspawner and where custom car spawner name is defined?

I don't envision it as having anything to do with an existing car spawner entry. It's a new intended-for-for OR entry. It's only going to work for OR anyway. I couldn't care less if train.exe regards it as a static entry when some activity runs. The only thing that matters to me is the enhancement must not cause KUJU's RE to throw away that Uid() entry. Where the real data is stored is of no particular interest to me.

If somebody wants to convert an existing car spawner entry to a multi-car entry they can delete the old one and insert the new one. Yes, that means it is an OR only route. I am not disturbed by that fact. More* on this below.

What this should mean for your route editor is this: You could code for only one kind of car spawner -- the new one. If the designer wants to use only one car shape he should be able to define that. If he wants to use multiple car shapes he can define that instead. I am unaware of any reason why your code should write a new entry that follows KUJU's design just because the guy wants to specifiy one car. Carlo's feature should deal with just one car shape and if the route designer doesn't want anything to do w/ Carlo's feature he can stick w/ RE.

IOW what I'm trying to do here is get a win:win situation: Carlo gets his feature, you get to code it, and when its done it doesn't cause people like me to maintain a list of tiles for which we should never touch in KUJU's software.



* If somebody wants their route to run in both train.exe and runactivity.exe they can continue to edit that route with KUJU's RE. As Carlo said elsewhere, that means they don't get to use OR-specific features. OTOH if they commit their route to be an OR route they'll be able to use your RE to add those features. Again, the only thing that matters to me is the enhancement must not cause KUJU's RE to throw away stuff when it doesn't know what to do with it. If there is another way to do that than what I'm suggesting with the Static object "flag", fine, just that it not cause KUJU's RE to throw away stuff that it doesn't know what to do with.

When your RE is finished and what it does isas good or better than KUJU's software, the later can be tossed. I do not believe your software is finished nor do I believe it is as good or better in every regard -- some places, yes, it is clearly better but in other ways, not even close. Painting has potential but where is the undo button for any sort of edit you screw up? Absent that I'll stick with professional paint tools. Terrain editing has no undo. Absent that I won't touch your terrain editing function if you paid me. Using mouse movement to actuate terrain changes is fine if you have absolutely no idea of what you want to do but for fine motor control you need to be using a stylus and tablet to come anywhere close to getting something right. You've got an adjustable radius tool... is it visible to the guy whose hand is on the mouse? No, so he's got no way to know what your software is about to change. As bad as KUJU's terrain editing is, it is still safer to use. Where is the help text that normally is found under the help function? IMO your choice of mnumonics for commands are even more obtuse than KUJU's. Now I like mnemonics, a lot actually, when they make sense. My point is there is along list of things that are either not present or could be improved above their current crude level of functionality. The software has potential but IMO it is not ready to be anointed as a KUJU RE replacement.

[Goku]

Genma Saotome, on 06 December 2016 - 03:16 PM, said:

I don't envision it as having anything to do with an existing car spawner entry. It's a new intended-for-for OR entry. It's only going to work for OR anyway. I couldn't care less if train.exe regards it as a static entry when some activity runs. The only thing that matters to me is the enhancement must not cause KUJU's RE to throw away that Uid() entry. Where the real data is stored is of no particular interest to me. If somebody wants to convert an existing car spawner entry to a multi-car entry they can delete the old one and insert the new one. Yes, that means it is an OR only route. I am not disturbed by that fact. More* on this below.

In that case why ever need anything in main .w file. Just in second .w file use high UiDs. No need for placeholders.
But not allowing extending existing objects isn't a solution :)

Genma Saotome, on 06 December 2016 - 03:16 PM, said:

What this should mean for your route editor is this: You could code for only one kind of car spawner -- the new one. If the designer wants to use only one car shape he should be able to define that. If he wants to use multiple car shapes he can define that instead. I am unaware of any reason why your code should write a new entry that follows KUJU's design just because the guy wants to specifiy one car. Carlo's feature should deal with just one car shape and if the route designer doesn't want anything to do w/ Carlo's feature he can stick w/ RE.

Our solution allow for making route with better experience in OR but still playable in MSTS. Your solution forces route designer to choose: the same experience in MSTS and OR, or OR only route.

Genma Saotome, on 06 December 2016 - 03:16 PM, said:

IOW what I'm trying to do here is get a win:win situation: Carlo gets his feature, you get to code it, and when its done it doesn't cause people like me to maintain a list of tiles for which we should never touch in KUJU's software.

But using Jamess Ross solution you can still touch these tiles.

[Goku]

About writing custom data to .w files. Funny thing, I just discovered that TsUtils writes it's own world object id 300 with copyright info :)

[Goku]

Genma Saotome, on 06 December 2016 - 03:16 PM, said:

Painting has potential but where is the undo button for any sort of edit you screw up? Absent that I'll stick with professional paint tools.

KUJU RE has no painting at all. You can still use proffesional paint tools when using my editor.

Genma Saotome, on 06 December 2016 - 03:16 PM, said:

My point is there is along list of things that are either not present or could be improved above their current crude level of functionality.

So, what is on the long list of things that are in KUJU RE but absent in TSRE?

[Genma Saotome]

WRT Carlo's proposed feature. I've raised my concerns, so have others. Goku is now part of the OR team. The OR team can resolve this.

[Genma Saotome]

Goku, on 06 December 2016 - 06:05 PM, said:

KUJU RE has no painting at all. You can still use proffesional paint tools when using my editor.


So, what is on the long list of things that are in KUJU RE but absent in TSRE?

You conveniently ignore the phrase "or or could be improved above their current crude level of functionality." So crude as to be unusable. As in not present.

Not have an undo for any terrain editing makes ALL terrain editing functionality not usable. As in not present. I picked a track shape at random (1500m05r) and placed it one a random location. Tipped it slightly (observing how the tip function works with each individual character typed -- you've got to be kidding) and after spending 10 minutes looking for how one adjusts terrain to align with a track I spent another 10 minutes trying to find anything that matched TSRE and Manual or TSRE and Tutorial or TSRE and documentation that might actually turn up one word of help, I finally found a reference to your web site where, after guessing the right url subset found a couple of pages that actually helped (good job at pocketing JKY's money and doing not much for the gift). The letter F - why F?... Ahh, maybe fill (a guess; one should not have to guess, there should be a complete list, with concept word -- like F - Fill), I went back and pressed F. The ground changed in both directions as desired (very quickly, a plus) and the track was completely buried. Not one portion was visible. Undo? Nope. Ok, exit, don't save. Try again. Oh, the most recent path wasn't saved...........

Let's do it all over again... oh, this time when I try and tip the track I see, once again, there is no undo. Trying to reset it to 0 pitch erases the track shape. No undo. Not really that big of a deal in this case -- KUJU's RE will do the same... but that really isn't good enough either, is it? There is no undo with the paint tool. The paint tool I use outside of sim editing software lets me have many dozen undo's -- it's the nature of editing art. One screw up in your paint editor and boom, everything done since the last save is lost. NO WAY will I use that sort of editing. NO WAY would anyone do serious work with that kind of editing. Play around? Sure. Real work? No way. Reset the terrtex back to the original? Same issue - you lose what was good. There is a reason why artist prefer using a stylus and table when painting pixels -- fine motor control. If you're stuck using a mouse, you are going to goof up. As in: effectively there is no terrain painting functionality present.

Mousing terrain lofting? For make believe worlds, ok, sure it can do the job. For editing DEM data? Not chance. Waaay too easy to screw up. No undo? Kills the feature right there. Try this: Use a pseudo paint tool to mark out a territory within which the terrain lofting can be done. Allow add and subtract functions on that marked out territory (this is analogous to creating a mask in an art program). Now it's bounded AND if you've made the masked area visible, the designer can see his target region. If the radius of the terrain pen nib is visible he can see where the function will be applied. JUST LIKE AN ART PROGRAM. What a concept. WAAAAY better than what KUJU did, even if all you have is a mousing. And as a superset of functionality, way better than you you have so far.

30m DEM resolution. It is to laugh.

Camera movement. I'm not terribly fond of all of camera movement keystrokes in OR, but it's what there is right now. Is there any reason for the so-called OR Route editor to be using different camera key commands? Other key commands... what has Z got to do with what word that is related to terrain editing? Why does a mouse wheel raise or lower an object. In CAD and 3d modeling tools it's a camera control.

Need I go on?

All of that said, I do see what you are trying to achieve and since nobody on the OR team was willing to even try, your code is the only game in town. It has some potential, but as is it's simply demo-ing a general direction. I think it can be made to be better because I think all of the problems like that can be dealt with. Except you always say you're done and everything is fine. Everything is not fine and therefore, IMO, the software is not done.

If this is all there is going to be... it s a HUGE lost opportunity, in part because bettering KUJU's RE is low hanging fruit. OTOH if this is all there is to date, then perhaps the future looks promising. But that's never how you present it and your response to suggestions is routinely negative. You CAN do better, you know. It's a lot of code so clearly you know a thing or two about coding. It's just not as good or better than KUJU's junk, which should be the objective.

Last: You may doubt this, but I am NOT trying to piss you off. I'm trying to convey how you can have a big success instead of a small success, the opportunities lying on the table, waiting to be picked up. It's up to you whether you want to reach for bigger and better. My advice is to stretch yourself and do it.

[Goku]

All you said is ok, but the question was why KUJU RE is better:
"So, what is on the long list of things that are in KUJU RE but absent in TSRE?"
But only thing I found in your answer is undo function.

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

Tipped it slightly (observing how the tip function works with each individual character typed -- you've got to be kidding)

What is wrong here?

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

The letter F - why F?

Because it is good to have all important keys under one hand.

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

there should be a complete list, with concept word -- like F - Fill

Here it is: http://koniec.org/ts...recontrols.html

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

Trying to reset it to 0 pitch erases the track shape. No undo.

No one has reported this bug. Fixed now.

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

30m DEM resolution. It is to laugh.

Since the beginning you can use any resolution HGT file. Not only 30m.

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

Camera movement.

My camera movement is like in most games. AWSD+Mouse. Where is it wrong?

Genma Saotome, on 06 December 2016 - 07:57 PM, said:

Why does a mouse wheel raise or lower an object. In CAD and 3d modeling tools it's a camera control.

Most changes of this kind I am doing on requests from TSRE users.

[Genma Saotome]

• I may be wrong here but the track moves with each charact4r types. If you are multiplying the existing numbers by 10 when accepting a new number then it's ok... it just looks a bit odd. What's 0/00 mean?
  
• Yes, if you are coding a first person shooter game, but your program is not a game, it is a 3d editing program. Different purpose, different design requirements.
  
• Append it all -- in your code or an associated file -- to some function under help. Your web page might not be there for years and years but your program probably will.
  
• One bug killed.
  
• .HGT is obsolete in the US and the STRM data that goes into .hgt has been obsolete for over 10 years. AFAIK the .hgt data that is available is 1 arc second -- 90m resolution. The entire country is available at the national map viewer in 1/3 arc (30m) and about 20-25% is available in 1/9 arc second. All of which was explained to you many months ago. It is still true today.
  
• Your program is not a game. It is a 3d modeling tool. Mouse movement in such tools is for zooming... as it is, after a fashion, in Open Rails.