Kicking around some ideas, part 1

[muskokaandtahoe]

Another (unrelated) idea would be the use of XML coding in the model.

There has been a lot of vigorous debate about .xml and IIRC one of the major objections raised was concern over the average guy trying to edit it relative to the effort the same guy would have in editing a file in MSTS notation.

Speaking for myself, I started out in favor of .xml but pulled back that opinion after considering that, given a choice, I actually would prefer editing by hand in MSTS notation over an identical content .xml file. It might not be technical pure... but IMO ease of editing, however subjective that might be, should be a consideration. And last I heard, OR is sticking w/ the MSTS notation. But of course next time the topic comes up... who knows, maybe .xml finally wins the argument.

[muskokaandtahoe]

Yes, but picture this readme:

"xyz.cplr" and "abc.truk" required to run this equipment.

Then both files go missing from where they're supposed to be hosted. It's bad enough when it happens to sounds and cabs. This is just another layer of things you have to replace when they inevitably turn up unavailable (and they will).

Open Rails would have a reputation as a sim where you have to track down component parts to run anything.

Eric, the concern about not being able to run is, IMO, valid, bit I think there is a simple solution for that -- simply provide an OR default model and file. If the .wag specifices something else and it cannot be found, issue a warning message and then plug in the default.

And thinking about it a bit more, I think it unlikely that any missing .cplr and/or .truk file could have the same consequences of, say, a missing set of .cvf files. If the end user didn't have the suggested component model he could just plug in the names of what he does have and it should be fine. Where things get could get sticky is if there was something else in the .wag that made reference to the suggested .cplr or .truk file -- that would be a problem and so thats all the more reason to put everything the sim needs to know about those components into their own file, leaving just the name and location data in the .wag.

Would that address your concern?

[burgerbern]

I like the idea but would be concerned if it were added as a FA line as was suggested further up, as that would leave no room for a FA being used to alter appearances as it is now, unless of course Open rails could be coded to cope with more than one type of FA in a single .eng or .wag file.

[Erick_Cantu]

Would that address your concern?

No, because the primary concern is that it overcomplicates things. Too many files, too many things that should be one model and one configuration file split into several. RailWorks has that problem, it makes things more difficult, not less. Remember, people are going to actually be building and painting these things, not just using them. Adding second shapes was, at one time, a way to get around a technical problem, now rendered unnecessary, which is why I no longer split shapes (although I do keep a second for the cab).

[rfranzosa]

While we're dreaming....

I used to watch a PC freight leave Hartford yard in the morning when I was attending the Hartford campus of RPI. The movement was a Hartford to Cedar Hill way freight combined with a New Britain local. The consist was typically an RS3 or two, a couple dozen freight cars, caboose, the New Britain RS3, another dozen cars and another caboose. In Berlin, CT the rear section would drop off and head to New Britain.

I enjoyed watching this train, because about halfway into the lead section there would be a car or two that would be at the 'node', alternating between being pulled by the lead unit and pushed by the trailing unit. THAT would be something to see modeled (as with helpers).

RGF

[3Directions]

simply provide an OR default model and file.

I've no particular thoughts on the way things are done , but , any solution that incorporates the above ^^^ is a good solution , particularly if animation is included .