[Lindsayts]

Genma Saotome, on 16 October 2014 - 09:55 AM, said:

WRT the reasonable hesitation about tucking into a route editor... yeah, a FULL RE would certainly be intimidating... so don't start there.

I have previously expressed my opinion that starting with a very limited RE could serve as a testbed for exploring/discovering what nee3ds to be in the code... static objects only... figure out how to do a select, then how to accept keyboard entry of a few parameters (e.g., altitude, rotation, and ESD_Display_Level) of that selected object, add a write transaction to the .w file (written so it can be easily replaced at some later date with the equivalent OR specific file). Don't add cute visual junk -- world building is a form of 3d cad designed to position predefined meshes -- use keyboard mnemonics and icon toolbars as any 3d cad package does.

It might turn out that the experiment shows what NOT to do (a valuable learning) or it could turn out to be very much the right way to go. Approach the task as an experiment and it should provide the foundation for moving further, either in understanding or in code. When the above is refined enough to be accepted then start on copy attributes from a different object and moving a static object to another position as both of those would build upon the basic select, UI interaction, write functions. Placement would probably be a bit harder so do that last. Stuff like road, track, interactives, terrain editing, etc. etc., are not well defined right now and IMO any code trying to deal with them would be highly speculative.

The key point I'm trying to make is to just start with the easiest task, do one RE task at a time, and learn as you go.

The way to handle an unknown programming task is to be able to break it down into known junks. A route editor is a viewer with the ability to select and place objects and to correctly manipulate the data files, nothing more. It appears the track data base can be worked on OK one assumes the track viewer goes a good way down this path. from various posts around Elvastower there also appears to be much knowledge on the world files, so both of these should be do able.

Lindsay

[Genma Saotome]

I'd like to return to the issue I've called The Big Fork: Is it necessary for the OR team to provide a MSTS compatible replacement for AE? For RE? Or are they free to create editors that do not include backwards compatibility?

If you follow the implications for a bit before answering I think you'll get to this question: Can I migrate my favorite route into an OR-featured environment? Or is it shunted off onto the MSTS fork, forever frozen, while OR chugs merrily along on the OR fork, destined for 2.o, 3.0, and so on? Is it ok if the answer is no, the team doesn't need to bother? OTOH, if the answer must be yes, what does that mean for how those new editors will be built and operated?

[gpz]

Dave, either I misunderstand you , or you misunderstood the meaning of a "fork". I think no one wrote that OR will be split to MSTS-part and non-MSTS-part. Everything will live together for the foreseeable future. The "fork" just a regular development procedure, where a developer starts to maintain his own source code repository with his own modifications and branches, which we developers all have done already. It is nothing unusual, or something that one has to be afraid of, or that affects the official project. No official Big Fork (or Big Split) will be done.

[gpz]

James Ross, on 16 October 2014 - 10:06 AM, said:

The problem is (and I think there is likely some agreement here) that we need to move beyond the MSTS directory structure, in one way or another, and this is a big step - and if we don't support MSTS file formats in that new structure, it's an even bigger step.

This is another big problem with the RE project: unless we want to build a RE that works on MSTS file formats (I don't think we do), we have to settle on at least some of the new structure and file formats before it can really get going.

I think OR should support the old format models without a need for conversion for being able to be built into new "structures". I don't think it would be a big deal, afterall it is just one more file format.

[James Ross]

gpz, on 16 October 2014 - 10:54 AM, said:

I think OR should support the old format models without a need for conversion for being able to be built into new "structures". I don't think it would be a big deal, afterall it is just one more file format.

It's not always that simple, since most file formats reference other files and how that works in the new structure may need sufficient tricks to make it work with the old formats that it's not practical. We can figure this out when we have a better idea of the new structure, though.

[Genma Saotome]

gpz, on 16 October 2014 - 10:29 AM, said:

Dave, either I misunderstand you , or you misunderstood the meaning of a "fork". I think no one wrote that OR will be split to MSTS-part and non-MSTS-part. Everything will live together for the foreseeable future. The "fork" just a usual development procedure, where a developer starts to maintain his own source code repository with his own modifications and branches, which we developers all have done already. It is nothing unusual, or something that one has to be afraid of, or that affects official project. No official Big Fork (or Big Split) will be done.

I do understand the concept of "fork".

What I'm getting at is this question: Will these new editors always read, edit, and write the MSTS formats specific to each editor... or not? Perhaps the replacement AE will... but do you expect the replacement RE will as well? I'm doubtful. I mean it would be nice if it does... but I think it might mean an unusual amount of extra work: this terrain tile has been terra-formed and retextured by the OR editor but that terrain file has not... these interactives function in new ways, those seemingly identical interactives do not. And so on. Once the OR code stops reading, editing, and writing the old formats those files are effectively frozen, right along with KUJU's runactivity.exe. Sure, their data will be read by OR and executed... but for fixing/enhancing features they're forked off into a frozen version and the end user is obligated to use KUJU's AE and/or RE to edit them. IOW, as far as go-forward files are concerned, the old KUJU files are forked into a different path than the rest of OR.

See, I think a perfectly reasonable approach would be to say 1.0 is the end of all editing of KUJU files. It accomplishes MSTS compatibility as promised but from here on out there is the MSTS fork that shall take bug fixes and the OR fork that shall develop all new features, editors, and file formats. That would effectively freeze changes to all MSTS routes (they'll still run in OR.. but they won't ever be changed by OR).

OTOH, it is also perfectly reasonable to say none of the above is acceptable, that instead, for all time, OR editors will read, edit, and write to both KUJU and OR specific files, even co-mingling them for use in one route. IMO that is the more desirable outcome... but is it really feasible? If not... then where does The Big Fork appear? With a new AE? With a new RE? Or just unplanned... when it has to happen?



p.s. The suspected difficulty of OR editors working equally well with both KUJU and OR file formats is part of the reason why I'm suggesting an early start on an experimental, limited RE. If all it does is (1) teach how to do an editor, and (2) do static object editing on Kuju's .w file then then prospect of OR's full-scale RE not working with KUJU files is not such a big concern, especially if it forms a platform for someone to eventually take further down the MSTS-compatible fork while the OR-Specific editor grows and evolves as is needed on the OR fork.

[gpz]

Dave, OR is unable to edit the MSTS content, it only reads it. That is why no Big Fork is needed. It is not unplanned, simply there is no point in splitting OR this way. OR can simply continue to read everything as it does currently without any Big Split.

[Genma Saotome]

gpz, on 16 October 2014 - 12:08 PM, said:

Dave, OR is unable to edit the MSTS content, it only reads it. That is why no Big Fork is needed. It is not unplanned, simply there is no point in splitting OR this way. OR can simply continue to read everything as it does currently without any Big Split.

Ok... perhaps I've missed an option... are you saying you expect the new OR editors, one for Activities, one for the World, will be able to read KUJU files, optionally edit whatever is there, and write a fully functional corresponding file in whatever the new OR file format is? IOW these new editors will convert all existing data from the KUJU files that were created by AE and RE to whatever new files are native to the OR Editors?


If that is what you meant then, yeah, there is no "Big Fork" because all of the routes and their activities that people like are convertable to native OR files.

Is that really what you are saying?

[gpz]

I don't know if this conversion can be done on the fly. Previously the idea was to convert the routes prior of editing, then edit the new structure only. But I can't know the technical details in advance. (I am not talking about the activities, because currently I don't think there will be a tool for OR to convert the existing activities for further editing, since it might be easier to ask everyone to create a new activity once a dedicated activity editor will be available instead. But timetable concept is already here, which is an outstanding feature, and makes most of "regular" activity editing unnecessary.)

[Lindsayts]

On file formats, all that is required is the format works and is understood. For a stage 1 route editor it would very likely be better to use the existing formats as designing a new format would be quite a complex task and would best be left until the need to improve the existing formats was QUITE CLEAR. No point in chasing extra work until there is a clear need.

A point I will make is one part of the route editor that needs to be done as soon as possible is to document the file formats MSTS uses particularly the track Data base file and the World file. There must be a considerable amount of understanding of these particularly of the two mentioned amongst the developers and some of the more senior Elvas Tower subscribers (by some of the posts I have read). Documenting the formats would allow anyone interested to have a far easier time contributing to the editor.

One way to start this would be to have a section on say this forum where anyone could freely post an explanation of some kind on a definition in one of the formats. That way a repository of knowledge would gradually be built until a decent doc could easily be writen.
I believe something like this has been required for a long time. Quite sometime back I spent 3 months or so going through the steam code and learned a great deal. Sadly there was no where I could post this info as each extra definition/function became clear. If all working on OR could post an explanation of items of info that became clear while working on OR we would soon have a real good body of knowledge which would be a MASSIVE help for new potential developers (and existing ones).
While such thing would be a distraction from writing new functions (something nearly ALL open source developers LOVE doing, its NOT unique to the OR devs. Documentation in most OS projects is well known as being pathetic), it would in the end make it far easier for new volunteers get into the act.

Lindsay