Default rolling stock

[wacampbell]

.. but until I can see the fruits of your labors, I'm not buying them (figuratively).

There's not much to buy ( even figuratively) yet. I think Chris shared some info on my experiments for those folks who are interested in hearing about what's going on in the backrooms of the project.

-Without a way to create content, how are you testing these new Physics and Features that you are encoding into the ORTS software?

I wasn't working on physics features but as they are implemented in text files - they are easy to create for testing. I have written a Blender exporter to experiment with graphics features.

-It's an Open Source project (sorta-not), but you're "holding back" the tools to create content...?

Its just that the time isn't right. My experiments are a long way from being available in the production released version. It was fun to explore what might be possible. The graphics team has a plan and priorities that control their progress. And the way I implemented them for my experiments may not be how they ultimately are implemented in the final product. We don't want developers using my tools only to find out that we've made a change that breaks compatibility for them. It really makes sense for us to first solidify how we extend the file formats before we start to release the content developer tools for them. Its definitely not an 'aks-baskwerds adventure'.

[OTTODAD]

I am not quite sure which cames first when creating a new train simulator or a new railroad, the chicken or the egg !

I should have thought that the tracks and signalling infrastructure must came first like in reality and we already have the best train simulator tracks with DB-Tracks.

Then using them to create routes with an editor comes next which can use created for the sims 3D graphics engine objects and scenery and that is just the start of it all.

Then comes rolling stock to run on the tracks, designed to emulate their real physics as closely as possible, requiring engineering knowledge as used by their designers.

Using anything from previous versions of a sim for a new one is like designing a new good looking Porsche and then use an older Volkswagen engine in it !

O t t o

[hminky]

like designing a new good looking Porsche and then use an older Volkswagen engine in it !

Weren't the first Porshes VW based?

Easier to start with something and improve it, than start from scratch.

Harold

[OTTODAD]

Weren't the first Porshes VW based?

The first ones were but not later ones.

Easier to start with something and improve it, than start from scratch.

Depends on how much of the "something" can be improved using new technology. methods and different physics, the ORTS team seem to have problems with !

O t t o

[longiron]

I am not quite sure which cames first when creating a new train simulator or a new railroad, the chicken or the egg !Then using them to create routes with an editor comes next which can use created for the sims 3D graphics engine objects and scenery and that is just the start of it all.

Then comes rolling stock to run on the tracks, designed to emulate their real physics as closely as possible, requiring engineering knowledge as used by their designers.

Using anything from previous versions of a sim for a new one is like designing a new good looking Porsche and then use an older Volkswagen engine in it !
O t t o

Really what comes first is file formats and storage architecture if you are building any computer program, including a train sim. That's what Wayne is referring to -- the OR team must make those fundamental determinations before adding everything else: Editors, content creation, physics, etc

[lindsayts]

wow, with that amount of time, a practiced modeller makes a full 3d cab model with texturing

Almost yes, the exprience of this cab and the one for the N class made me consider doing a cabview using a composite system, the main body and coarse detail being done as a 3D model a snapshot taken then the fine detail being done on that. The two I mentioned,the Sprinter and the streamlined DMU are being done that way, for the Sprinter I have actuall built the panel (Note 1) and am going to simply photograph it from the correct angle. One of the problems I have found is getting the texturing to look realistc (which is why I built the panel), the only way to do this is to photograh as many surfaces as one can, particularly inside rail vehicles. Also to get the gauges accurate and to look correct takes a good deal of effort, I find it best to get as good a photograph of the gauges as one can as constructing them from scratch even in a 3D modelling program takes a good deal of time.

To do any accuate modelling takes time and effort, always did and always will............................

Note 1: The panel is actual quite simple being rectangular and 800 mm long and 180 mm's high, mostly warning lights and toggle switchs and I luckily have a real Westinghouse brake gauge (in new condition) of the correct type I can copy. This makes job relatively easy as I run a machine shop.

Note 2: I have used simulators with 3 D cabviews and I do not like them (at all) as I find them to counter intuitive to use. I find the high detail 2D cabs I have done excelllent to use, mind you it is me that did them.....................

[lindsayts]

Really what comes first is file formats and storage architecture if you are building any computer program, including a train sim. That's what Wayne is referring to -- the OR team must make those fundamental determinations before adding everything else: Editors, content creation, physics, etc

I will support (I hope) both longiron and wacambell here, the file formats are everything, as you are the developer and it is presumed of course one knows what one is doing it is relatively easy to create test specimens of the files for testing particularly in MSTS where most of the files are text based. Once one gets the file formats all nailed down, in this it is VERY important to remember the develeopers of OR are likely doing a good bit of reverse enginnerring (and this takes time and effort) on these formats one can get onto the tools to create them.

A point I will continue to stress is these guys are volunteers with lives to lead and have people who depend on them so there time is limited.

Well done OR dev's

Lindsay

[wacampbell]

The point in question here is our decision to take an incremental approach to development and that decision drove the desire for backward compatibility. In hindsight, I am certain both decisions were correct. It allowed us to get usable code out quickly. Programmers could work on byte size projects, release them, and see the results immediately. Had we not done this, we would have needed to build the simulator, the RE, the AE, developer tools and ALL content before we could run the first train. Its taken us 5 years ( I started work in 2007 ) to get to where we are now, and we are still years away from having the above complete. There is no way we would have been able to maintain momentum for such a long time without at least being able to sit down and run a few trains.

So far, and as far as we can see going forward, these decisions have not in any way hindered our progress, nor limited us on what we can do. Bigger teams than ours have failed at this endeavor. I am certain, on this point, we have made the right decision.

[OTTODAD]

I am certain, on this point, that we have made the right decision.

Yes, you have, considering what it would take a part-time team to create a train simulator from scratch.

Being able to use tracks like the DB-Tracks is something no other train simulator has and still remember what the Trainmaster's and later MS-TS-2 tracks and their switches looked like and don't mention Trainz switches !

It has taken 11 years for MSTS to reach the maturity it has now and like you have said it will take the ORTS team many years before it can release a fully working version of it, complete with editors.

Take care all of you and don't neglect your families and loved ones !

O t t o

[lindsayts]

The point in question here is our decision to take an incremental approach to development and that decision drove the desire for backward compatibility. In hindsight, I am certain both decisions were correct. It allowed us to get usable code out quickly. Programmers could work on byte size projects, release them, and see the results immediately. Had we not done this, we would have needed to build the simulator, the RE, the AE, developer tools and ALL content before we could run the first train. Its taken us 5 years ( I started work in 2007 ) to get to where we are now, and we are still years away from having the above complete. There is no way we would have been able to maintain momentum for such a long time without at least being able to sit down and run a few trains.

So far, and as far as we can see going forward, these decisions have not in any way hindered our progress, nor limited us on what we can do. Bigger teams than ours have failed at this endeavor. I am certain, on this point, we have made the right decision.

A lot of people have made the mistake of looking at a project they are trying to build as one big homogenous whole and been crushed under the weight. As far as I can see you MUST break a project down to "bite" sized junks as soon as possible to be able to make any kind of progress.

" A journey of 1000 miles begins with a single step"

Chinese philosopher Laozi 604bc - 531bc

Lindsay