[captain_bazza]

The propriety [shape].S format has the advantage of being edited (uncompressed) in a unicode text editor. Some people are very adept at doing this.

The [mesh].3DS is an industry standard format and like most has pros and cons. It is also very flexible.

Cheers Bazza.

[gpz]

Browsing the milestone plan on launchpad James has linked, I gladly see that most of the 1.1 goals have been reached already. I browsed through 1.0 bugs in launchpad many times already, but I cannot find one I can really work on because of lack of familiarity with the affected program parts. The other 1.x and 2.x series mostly focus on activity design, that is being worked on, and I cannot contribute to. 3.0 looks more promising for me with the already implemented "3D cab interiors", and the interesting "OR Custom Rolling Stock - custom cab controls and locomotive operations", that sounds like the enhancement of the already existing scripting interface, which I started to re-think already.

Wayne is right, a route editor is missing very much. I would gladly contribute to it if a basic framework was existed, but I don't have the skills to develop this basic framework.

[Csantucci]

With the aim to move fast towards release 1.0, and considering that the main aim of this release is the MSTS compatibility, maybe these features foreseen for release 1.0
-Complete the signalling for multi-player mode
-New file for route-specific data such as signalling
-Specification for OR activities file
could be moved to release 1.1, without preventing volunteers working on it.

This way the two missing points for release 1.0 are
-Mouse operation for cab controls, as mentioned by James
-Experimental viewer for Activities
(bugs and documentation apart).
Referring to the experimental viewer, it could be based on the dispatcher monitor (CTRL-9), by transforming the player train to an AI train and by allowing viewing the dispatcher monitor also in the "preupdate" phase (the one before the player train enters the game). Later on (even after release 1.0) this could be improved by inserting a run-time selectable autopilot mode for the player train (first step towards player train switching, that is foreseen in release 1.1).

I too see that a good amount of points related to release 1.1 are already addressed, and in my opinion work on such features could be permitted, provided blueprints are available. From my side if I will work on further AI shunting functions, I will precede that with a small specification.

Referring to editors, the milestone scheduling puts at the first place the AE, with respect to the RE. I agree with the the fact that the AE has priority. However, as creation of the route editor can span through more than one release of the rest of the game, in my opinion any person(s) volunteering writing a draft blueprint (not a dream book) on it is welcome.

[James Ross]

The other comments look good to me, though I am not entirely sure what was intended for "Experimental viewer for Activities" in the 1.0 milestone.

Csantucci, on 16 October 2014 - 05:13 AM, said:

Referring to editors, the milestone scheduling puts at the first place the AE, with respect to the RE. I agree with the the fact that the AE has priority. However, as creation of the route editor can span through more than one release of the rest of the game, in my opinion any person(s) volunteering writing a draft blueprint (not a dream book) on it is welcome.

This is an important point: not all features are equal in size and some will therefore need more time planning and implementing than others. The RE is quite possibly the single biggest item, so the earlier we can start planning the better (but not implementing it until we're agreed on the main plan).

I'd like it if we could turn all the specific features listed in all the milestones in to actual blueprints (possibly mostly just skeletons for now), but I wanted to start by considering just 1.0 (and maybe 1.1) before we go that far.

[Genma Saotome]

James Ross, on 16 October 2014 - 12:40 AM, said:

Yeah, we have tried having that discussion before. I am in complete agreement that we need a new model format, to complement DDS for textures, but we've not found an obvious choice. Implementing the choice seems like the easy part now. :rolleyes:

A bit of thread drift... I hope that is ok....

I just re-read that thread James posted and IMO it was a good discussion. James is correct in being a bit disappointed that no clear answer appeared but IMO the discussion brought out a number of issues and I think help clarify the problem.

Not mentioned tho was any regard for the continued use of TSM and 3dCrafter. I believe there had been previous agreement those tools could continue to produce .s files that would "run" in OR, albeit lacking any OR-Specific cad produced features. That is still a valid understanding, right?

For myself, I am not put off by an obligation to manually execute a conversion of files from cad to game format so long as the source code for that conversion is owned/licensed to the OR team so it can be maintained over time. We've been doing that for .s for a decade now and while it would be nice to avoid doing that it's not like it is a new burden to bear.

Would migrating OR to one of the commercially used game engines (e.g., Unity) dictate an answer for the go-forward mesh file format? Cut off .s, TSM and/or 3dCrafter? Just asking.


Returning to the original purpose of the thread... I do think it would be helpful to present to the user community a list of the known missing MSTS features. It would help convey the size of the task as well as open up an opportunity for a bit of feedback as to whether any items in the list are a don't care. It could be the basis for a team management discussion on whether an early-than-planned fork (producing both 0.98 and 1.01 versions) is feasible and practical... something that might address the natural inclination of team members to roll out new features.

There is one other issue that comes to mind: When does the folk occur that puts pure MSTS files to one side and OR featured files to the other? By this I mean at what point do9es the team stop adding data to MSTS files and starts using an OR replacement file (e.g., 123.w = MSTS and 456.world = OR)? IMO this should be 1.0 but I concede that other opinions could argue for 2.0... or even "as late as possible" or even "never'. If the answer is a fork relatively soon, that news should be conveyed ASAP.

[Lindsayts]

Our host Dave Nelson and I have had some good discussions about a route editor and it should not be to come up with a realistic specfication and framework for an OR route editor stage 1. As has already been stated stage 1 needs not to be a dream but simple basic and reliable.

Items required.....

1.0:A world viewer, this already exists in the code so this should not be to difficult to get at.

2.0:The ability to generate terrain, including distant mountains, probably be a good idea to discuss a more accurate approach to the world model. I personally believe at least for stage 1 we do not deviate from the flat tiled world model that MSTS uses but just look for more accuracy in terrain generation and display. I have done a great deal of work on this.
I have a REAL simple approach for this that would be easy to place into stage 1.

3.0: Ability to select, move, manipulate and place objects. For stage 1 I would suggest keep this simple with limited automation the prime focus being on RELIABILITY.

4.0 Ability to lay track, alter track layouts and successfully and reliably manipulate the track data base.

4.1 Be able to set up signalling and other basic interactives between the train and the track.

5.0 Basic terrain manipulation tools, again for stage keep it simple, even to the extent of just having a simple terrain height tool.

6.0 Do not worry about backwards compatability, a route created or modified by OR's editor can no longer be modified by the MSTS world editor.

Sugestions welcome BUT KEEP IT SIMPLE AND BASIC, after all this is for stage 1 and we need to make good progress early, the all singing and dancing version will be developed over time.

Lindsay

[Genma Saotome]

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.

[Lindsayts]

7.0 ability to add to and manipulate the object database (the world files).

[Genma Saotome]

Lindsay suggests 2.0 is about terrain. IMO that raises the question of The Big Fork: A new terrain file means it's not MSTS anymore. I'm not so sure that is the right thing to do so soon... perhaps it is, perhaps not. As an alternative "small step" how about "exporting" an existing route's terrain to a neutral CAD format, like collada. People could pull it into Sketchup, Blender, perhaps 3dcrafter too, and edit/texture it as a shape file and put it back into the MSTS route (removing the actual terrain polys.

Consider that as another experiment: Does our CAD software provide a useful means for terrain editing and texturing? Maybe... maybe not. Right now we don't know and so later on, when the question of whether such tasks are to built into a route editor or not, we'll have a better idea of what the right answer will be.

[James Ross]

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

Not mentioned tho was any regard for the continued use of TSM and 3dCrafter. I believe there had been previous agreement those tools could continue to produce .s files that would "run" in OR, albeit lacking any OR-Specific cad produced features. That is still a valid understanding, right?

Certainly within MSTS content (e.g. an MSTS route, or MSTS trainset) we will never drop .s file support. I don't see MSTS content support being dropped any time soon - I hope it is supported for as long as practical. There is a debate to be had on whether we support .s files in an OR route or OR trainset (where we would be using all OR file designs).

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

For myself, I am not put off by an obligation to manually execute a conversion of files from cad to game format so long as the source code for that conversion is owned/licensed to the OR team so it can be maintained over time. We've been doing that for .s for a decade now and while it would be nice to avoid doing that it's not like it is a new burden to bear.

If we didn't support .s files in OR routes/trainsets, I would encourage people to produce (as part of the OR project) a simple conversion tool to whatever model format we do end up supporting. In fact, this applies to a variety of MSTS formats, where it makes sense (like models, textures, consists).

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

Would migrating OR to one of the commercially used game engines (e.g., Unity) dictate an answer for the go-forward mesh file format? Cut off .s, TSM and/or 3dCrafter? Just asking.

Probably. It would likely (although I am by no means certain) only allow us to load the specific game engine's supported formats, so any other formats would at minimum need a conversion step (which we could probably perform, at some loading cost).

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

There is one other issue that comes to mind: When does the folk occur that puts pure MSTS files to one side and OR featured files to the other? By this I mean at what point do9es the team stop adding data to MSTS files and starts using an OR replacement file (e.g., 123.w = MSTS and 456.world = OR)? IMO this should be 1.0 but I concede that other opinions could argue for 2.0... or even "as late as possible" or even "never'. If the answer is a fork relatively soon, that news should be conveyed ASAP.

Although it has been discussed before, we never got this really off the ground. My aim is to create a new system which can either: contain MSTS content directly or coexist next to MSTS content, so that you can mix-and-match at certain levels. E.g. I could run a Series 7000 from MSTS on whatever OR routes I have. This is what I am exploring with the Content Manager contributed-project.

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.