My observations thus far:
MAIN_RES:0:0
BRAKE_PIPE:0:0
BRAKE_CYL:0:0
EQ_RES:0:0
Frame 0 minimum, I have defined maximum at 100, will these work properly with smaller maximum frame values?
SPEEDOMETER:0:0
Needle is defined by 3D geometry and animated from 0 to some maximum (I used 100).
THROTTLE:0:0
Zero to full.
DIRECTION:0:0
Reverse, neutral, forward.
TRAIN_BRAKE:0:0
ENGINE_BRAKE:0:0
Both brakes go from zero to full. Problem: the number of steps in the animation seems to be defined by the number of frames, that is, the animation will not interpolate like the speedometer and brake gauges. To get a fairly smooth animation, I used 100 frames. This causes issues with the door, which seems to read the total number of frames in the scene as its animation length. Therefore, at one frame per second, the door takes about a minute and a half to go through the total animation length, and another minute and a half to close.
I think we ought to be able to define wiper and door operating speeds independent of some fixed framerate. Even if, for example, we changed the door's animation to read the number of actual keys and disregard the total number of frames in the scene, we would still be unable to properly animate a handle (which would rotate to its maximum position before the door even began to open) without slowing the door way down. Operating speed ought to be set by a separate parameter. As well, it would be nice if the brake levers interpolated like the gauges do for smooth operation.
More observations:
All animated parts in cab must end in :whatever:something. This is important to note, because the manual lists names for the doors and mirrors that do not reflect this. The names are not LEFTDOOR, RIGHTDOOR, and MIRRORS, they are LEFTDOOR:whatever:something, RIGHTDOOR:whatever:something, and MIRRORS:whatever:something. The external wiper tag in the manual is correct and provides a clue to naming the other parts. That all animated cabview parts require these suffixes to operate needs to be a bullet point in "development rules."
It is possible to avoid duplicating texture files by inserting paths into the texture file names:
images ( 3
image ( ..//GP10_A_T.ace )
image ( ..//GP10_B_T.ace )
image ( GP10_C_T.ace )
)
textures ( 3
texture ( 0 0 -5 ff000000 )
texture ( 1 0 -5 ff000000 )
texture ( 2 0 -5 ff000000 )
)
light_materials ( 0 )
light_model_cfgs ( 1
light_model_cfg ( 00000000
uv_ops ( 1
uv_op_copy ( 1 0 )
)
)
)
Since editing of the shape file is required anyway, all this required was for me to find and replace all instances of those two texture filenames to tell the sim to look in the parent folder for them. This means that we can create a convention for structuring our locomotive folders to allow for the same cab shape to be used on different locomotives. If we put each locomotive in its own dedicated folder, and use the same texture filenames for each variation of the same model, we could simply use the same 3D cabview for each locomotive, and it will read the textures in the parent folder. To avoid duplicate cabview textures, we could insert commands to a common folder like we often do with conventional cabviews. Let's say, for example, I have a hypothetical ATSF GP20 set. The three models differ in minor details not necessarily visible in the cab, so they can all use the same cabview. All three models use the same texture file (let's call it ATSF_GP20_A_T.ACE), but, obviously, each locomotive (let's say 1125, 1154, and 3105) has different textures in its individual folder. Each model uses the same cabview (let's call it GP20_ATSF_VC.S, and give it a single texture file, GP20_ATSF_VC_T.ACE). The basic folder structure might look like this:
/COMMON.CAB
/ATSF_GP20
GP20_ATSF_VC_T.ACE
/ATSF_GP20_1125
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_1125.ENG
ATSF_GP20_1125.SD
ATSF_GP20_1125.S
ATSF_GP20_A_T.ACE
/ATSF_GP20_1154
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_1154.ENG
ATSF_GP20_1154.SD
ATSF_GP20_1154.S
ATSF_GP20_A_T.ACE
/ATSF_GP20_3105
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_3105.ENG
ATSF_GP20_3105.SD
ATSF_GP20_3105.S
ATSF_GP20_A_T.ACE
The materials in GP20_ATSF_VC.S would, accordingly, look like this:
images ( 2
image ( ..//ATSF_GP20_A_T.ACE )
image ( ..//..//COMMON.CAB//ATSF_GP20//GP20_ATSF_VC_T.ACE )
)
Therefore, all three locomotives will have discrete texture files, but since each locomotive is in its own folder, the names can be the same, meaning a single cabview can be used with all three; all three copies of this 3D cabview will call up the same texture files from the common.cab/ATSF_GP20 folder. Therefore, instead of nine separate texture files, of which four would be duplicates, we have four: a single cab texture, and a single texture per locomotive.
If we can find a way to allow open rails to read .eng files in subfolders within the TRAINSET folder (perhaps allow more complex paths in consist files?), we could clean this up even more by having all of these folders within a main folder called ATSF_GP20_PACK1 (note that I changed the folder structure slightly, requiring different texture paths in the cab model):
/TRAINSET
/ATSF_GP20_PACK1
/COMMON.TEXTURE
GP20_ATSF_VC_T.ACE
/ATSF_GP20_1125
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_1125.ENG
ATSF_GP20_1125.SD
ATSF_GP20_1125.S
ATSF_GP20_1125_A_T.ACE
/ATSF_GP20_1154
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_1154.ENG
ATSF_GP20_1154.SD
ATSF_GP20_1154.S
ATSF_GP20_1154_A_T.ACE
/ATSF_GP20_3105
/CABVIEW3D
GP20_ATSF_VC.S
GP20_ATSF_VC.CVF
ATSF_GP20_3105.ENG
ATSF_GP20_3105.SD
ATSF_GP20_3105.S
ATSF_GP20_3105_A_T.ACE
This would significantly tidy up the TRAINSET folder.
There are more efficient ways of accomplishing all of this that allow a single model to use multiple texture sets, with a configuration file for each texture set allowing common textures to be in a remote folder (see: Microsoft ESP), but this is still an order of magnitude more efficient than the alternative.
I have to say the process of building a 3D cab is fairly intuitive and straightforward, and the commonality of most processes to building a 2D cab is fantastic. I'm pretty excited for what we'll be able to do now. I've been testing the processes out using the low-res cab from the GP10 external model, and have been quite pleased with the results:
Please ignore the ugly handrail stanchions, although I did replace those the other day. I am ready to build a proper cab now, we'll see how it goes.
dekosoft, on 07 October 2016 - 07:03 AM, said:
Log In
Register Now!
Help
