[conductorchris]

I want to put in a little encouragement from the peanut gallery here and say I am very much looking forward to a future where rolling stock can be made up with multiple shapes. This first came to mind when getting frustrated at creating flat car loads. I wanted a load of bulldozers and could only find single ones in the file library. A number of different flat car load scenarios, including piggyback loads have reminded me of this wish. Then came the controversy about importing shape files and someone suggested that allowing shape files to work together would take away a good deal of the impetus for importing shape files.

What about shape files that are part of a whole but articulate? Those big Milwaukee road electrics or big steam engines?

Christopher

[Genma Saotome]

conductorchris, on 24 June 2015 - 07:46 AM, said:

I want to put in a little encouragement from the peanut gallery here and say I am very much looking forward to a future where rolling stock can be made up with multiple shapes.

Me too. I have several cars I am working on and the one thing they all have in common is no trucks, no couplers. How many trucks and couplers have been done over the last 12 years? From where I sit the answer is none... I have to craft them myself from scratch because I'm using Sketchup. It's nuts.

conductorchris, on 24 June 2015 - 07:46 AM, said:

What about shape files that are part of a whole but articulate? Those big Milwaukee road electrics or big steam engines?

I suppose when car and locomotive assembly gets well defined it'll have to include articulation... and probably changes in the .eng file as well.

[Genma Saotome]

cjakeman, on 24 June 2015 - 07:31 AM, said:

Sorry for the pause in conversation - been a bit busy but I still want us to complete this collaborative activity.



I'm suggesting the new file type SG to keep things tidy. SG is indeed descriptive game information, but it's doing something different from SD, so I prefer to leave SD (and the code which reads it) unchanged and invent a new SG file type which provides only the new functionality. The code for reading the W file will need to be extended though, to handle the proposed ShapeGroup element.

I see. I'm not convinced but as it is a matter of physical implementation instead of logical specification I won't fuss too much about it. I will make one more comment tho, just to be sure we've fully explored the matter: What KUJU is doing with the .sd is using it to carry class data into the world file where it can be edited as object data. I do think that basic purpose applies to this grouping idea as well as to setting the time of day to use night textures. Where it doesn't apply (relative to other proposals I've made for using the .sd file) is for replacing some of the strings and numbers found within the .s mesh file, things like providing a replacement texture name and/or a more suitable LOD distance value.

With that in mind then, abstracting away from KUJU's implementation I would say there are three distinct improvements that need a home in some file somewhere:

• The class to object transformation that occurs for anything going into the world file.
  
• The inclusion of / alteration of data in the mesh.
  
• The apparently more complex requirements of grouping parts for locomotives and cars.

If you think the right answer to (1) is to design a new file type to carry that information into an OR specific world file (i.e., replacing KUJU's .sd and .w files)... that is perfectly acceptable to me. It puts implementation off for a while but it would be a clean design.

As (2) can apply to any mesh file it seems reasonable a new file needs to be paired to the .s... but the data it holds is not germane to the .w file at all so something new is necessary.

And (3) is also not germane to the world file... a brief thought suggests it might be very well suited to .eng and .wag.