[darwins]

I have been looking at using include files with the steam locos I am making at the moment.

One type of locomotive that I am making was to begin with fitted with several different boilers to try to remedy the poor steaming of the original design. So there are include files for the different boilers.

Freight Anims are used to add headlamps - showing different headlamp codes - Class 1, Class 2 .... Class 9

Freight Anims are also used to put a driver and fireman in the cab - and animated fire in the firebox of the 3D cab.

So I thought I would use include files for the different headlamp combinations. I found out that if the headlamps are in one include file and the loco crew are either in the main eng file or in a different include file that one of these things does not appear. Learning - all freight anims must be in one block - so I have had to copy and paste the loco crew and the fire into each of the headlamp inc files. (That seems to almost defeat the object of using inc files.)

[copperpen]

I don't see that it does defeat the object of inc files. Their job is to make the inclusion of common data easier to add to different eng files. The more data etc you can add to an inc file the easier it becomes to make changes across the fleet.

[ErickC]

All child shapes of the same type must be in the same block. Use an MSTS definition for whatever needs to be in the include file and OR definitions for the rest. Ensure the flag to enable the MSTS definition is set in the OR definition. This is precisely how the loads on my hoppers are handled separately from ACI plates or car numbers.

It would be helpful if OR did recognize multiple definitions per file, though. Similarly, I don't think there should be a limit on the number of SMS files we can load for one object. There's no reason that control samples and horns should be in the same SMS files as the engine sounds when those things should be both common to multiple different sound sets and swappable without changing the engine sounds.