File Name: Maryland & Pennsylvania RR 0-6-0 No.29
File Submitter: timmuir
File Submitted: 06 Jul 2022
File Category: Steam Locomotives, 20th century (Open Rails only)
Maryland and Pennsylvania RR 0-6-0 No.29
Repainted, remapped, modified and "cleaned-up" NP L-9 base model shapes.
In honor Of long-time friend Paul Precht.
Tim W.Muir, builder and painter.
____________________________
! OPEN RAILS TRAIN SIM ONLY !
----------------------------
This model is a representative of the M&PA Baldwin 0-6-0 No.29. I've added details specific to the engine and tender. The cab has been rebuilt with meticulous tune-ups done to the mapping of parts, as well as adding some new parts. I could go on forever with this one.
The tender has a new body and details as well as getting some parts rebuilt, re-mapped and cleaned up.
A lot of work was put into this one; may be my favorite.
Figures are by Tom Werb with some texture and shape mods.
Texturing and artwork done in Paint Shop Pro7.
Some weathering and effects textures are from sources found at Textures.com. For those interested in weathering resources, I suggest the "Decals" category at their website. These can be cloned at low opacities onto new layers over your original artwork. I download the largest images.
Click here to download this file
Maryland & Pennsylvania RR 0-6-0 No.29
#2
Posted 06 July 2022 - 03:21 PM
Tim,
I am very honored that you did this. Thank you very much!!!!!!!
I am very honored that you did this. Thank you very much!!!!!!!
#3
Posted 06 July 2022 - 04:59 PM
My pleasure, Paul. This was an enjoyable project.
Open Rails 2022-07-06 12-18-42.jpg (2.4MB)
Number of downloads: 8
Open Rails 2022-07-06 12-18-42.jpg (2.4MB)
Number of downloads: 8
#4
Posted 26 July 2022 - 07:30 AM
I say "hello" to everyone, starting public work on better configuration (i.e. *.eng/*.wag-files) for TWM's wonderful models of Ma-Pa steam locomotives. ##29&26
It will be a challenge, as before my work was about modern rolling stock, which demand fewer parameters. Also, P.Newell (a.k.a. steamer_ctn) developed so many improvements for steam traction, and all that deserves to be studied.
In other words, I plan to share: my past experience, new discoveries, ideas, and maybe, other people's advices, opinions...
Can't promise, it will be quick or massive work, but the result and common knowledge are more important, isn't it?
These posts may be improved and added/corrected with time. So it can form a kind of tutorial later.
It will be a challenge, as before my work was about modern rolling stock, which demand fewer parameters. Also, P.Newell (a.k.a. steamer_ctn) developed so many improvements for steam traction, and all that deserves to be studied.
In other words, I plan to share: my past experience, new discoveries, ideas, and maybe, other people's advices, opinions...
Can't promise, it will be quick or massive work, but the result and common knowledge are more important, isn't it?
These posts may be improved and added/corrected with time. So it can form a kind of tutorial later.
#5
Posted 26 July 2022 - 07:38 AM
Part one: with what to begin?
My choice is text editor, as Notepad Plus (ConText before) or even MS Word/OpenOffice Writer, which all show non-printable symbols.
NpP becomes preferred, as it better shows indent structure, what is essential for such files, as MSTS configuration ones.
As Open Rails offers "friendly configuration succession" I see the sense to use it.
What do I mean?
ORTS can read files from OpenRails subfolder of route or rolling stock unit's durectory, while old MSTS configuration files can exist on their places further, without our modifications.
So, I offer to create such sub folder for future work, but leave intact original files, at least for initial phase of work.
I'm going to write files from scratch, for testing every modification, avoiding inheriting of old errors and redundant MSTS-era parameters
The configuration file contains of blocks hierarchy, so we can have a canvas, where will place verified blocks one by one.
My choice is text editor, as Notepad Plus (ConText before) or even MS Word/OpenOffice Writer, which all show non-printable symbols.
NpP becomes preferred, as it better shows indent structure, what is essential for such files, as MSTS configuration ones.
As Open Rails offers "friendly configuration succession" I see the sense to use it.
What do I mean?
ORTS can read files from OpenRails subfolder of route or rolling stock unit's durectory, while old MSTS configuration files can exist on their places further, without our modifications.
So, I offer to create such sub folder for future work, but leave intact original files, at least for initial phase of work.
I'm going to write files from scratch, for testing every modification, avoiding inheriting of old errors and redundant MSTS-era parameters
The configuration file contains of blocks hierarchy, so we can have a canvas, where will place verified blocks one by one.
#6
Posted 26 July 2022 - 07:59 AM
Getting started?
MSTS configuration files have standard structure: SIMIS signature at very beginning, which defines the file type and purpose, then blocks hierarchy, with boundaries, in form of brackets. This means, that all brackets must have their pairs: opening/closing each block.
And our ConText, or NotePadPlus can show the second bracket of each pair, highlighting them (NpP also points that, by thin red arrow)
We can copy the string with SIMIS signature from working configuration file, for avoiding misspells, than continue.
Comments
I'm sure, they are needed, welcome and very important: for yourself - as a backup for memory (especially years later), for collaborators, and for other interested sides.
Comment is better to write in form of Comment (...) block, as symbols, like * or # have proven their irreliability, being often misunderstood as desired by parsers.
So, we insert our notes in braces after Comment word. That also can be fragments of configuration, which we decide to turn off for some reasons.
After SIMIS signature (very first string), I advice to make the first comment, pointing on:
-version
-date
-author
of given file.
MSTS configuration files have standard structure: SIMIS signature at very beginning, which defines the file type and purpose, then blocks hierarchy, with boundaries, in form of brackets. This means, that all brackets must have their pairs: opening/closing each block.
And our ConText, or NotePadPlus can show the second bracket of each pair, highlighting them (NpP also points that, by thin red arrow)
We can copy the string with SIMIS signature from working configuration file, for avoiding misspells, than continue.
Comments
I'm sure, they are needed, welcome and very important: for yourself - as a backup for memory (especially years later), for collaborators, and for other interested sides.
Comment is better to write in form of Comment (...) block, as symbols, like * or # have proven their irreliability, being often misunderstood as desired by parsers.
So, we insert our notes in braces after Comment word. That also can be fragments of configuration, which we decide to turn off for some reasons.
After SIMIS signature (very first string), I advice to make the first comment, pointing on:
-version
-date
-author
of given file.
#7
Posted 27 July 2022 - 07:28 AM
Two more notes, before editing starts:
Open Rails offers to us (thanking dear developers) two great abilities:
- if some parameter is missing in our configuration file, it would be taken from default hardcoded tables, according to other defined parameters, and to ORTS Log-file would be recorded note, that such substitution to this *.eng/*.wag file, and to those values took place.
- we can enter values now, measured/expressed in same units, as in tech documents of prototype machine, without need to convert them to some MSTS default units.
We only should specify the units, we used. For complete list of acceptable UoM's and their designation in ORTS syntax - see Manual's appendix.
Open Rails offers to us (thanking dear developers) two great abilities:
- if some parameter is missing in our configuration file, it would be taken from default hardcoded tables, according to other defined parameters, and to ORTS Log-file would be recorded note, that such substitution to this *.eng/*.wag file, and to those values took place.
- we can enter values now, measured/expressed in same units, as in tech documents of prototype machine, without need to convert them to some MSTS default units.
We only should specify the units, we used. For complete list of acceptable UoM's and their designation in ORTS syntax - see Manual's appendix.
#8
Posted 30 July 2022 - 03:22 AM
I've refined code of #29 and her tender, and corrected *.cvf direction of front view as well.
Soon, I hope to add files.
I've said about non-printable symbols, like long spaces, added by Tab key.
In appropriate text editors, they are looking like right-pointing arrows, so their quantity at particular string helps us visually check structure of code (levels of embedding)
Every opened bracket adds one level, which goes one step up after closing bracket.
Another benefit of tab spaces - they automatically align "words" of different strings, forming accurate columns.
Delete txt-second ectension for using SVRy16.cvf-file
Soon, I hope to add files.
I've said about non-printable symbols, like long spaces, added by Tab key.
In appropriate text editors, they are looking like right-pointing arrows, so their quantity at particular string helps us visually check structure of code (levels of embedding)
Every opened bracket adds one level, which goes one step up after closing bracket.
Another benefit of tab spaces - they automatically align "words" of different strings, forming accurate columns.
Delete txt-second ectension for using SVRy16.cvf-file
Attached File(s)
-
Ma&Pa060tender29.wag (4.83K)
Number of downloads: 5 -
SVRy16.cvf.txt (7.6K)
Number of downloads: 4 -
Ma&Pa0-6-0no29.eng (12.66K)
Number of downloads: 2
#9
Posted 26 August 2022 - 07:39 PM
Now, the general reference will be needed.
The actual information (at least I hope, that's so) can be seen on P.Newell's pages:
http://www.coalstone...rmat/#top-wagon
Because our MSTS ENG/WAG "bible" by Rudolf Richter might be not enough for ORTS era.
The actual information (at least I hope, that's so) can be seen on P.Newell's pages:
http://www.coalstone...rmat/#top-wagon
Because our MSTS ENG/WAG "bible" by Rudolf Richter might be not enough for ORTS era.
#10
Posted 26 August 2022 - 09:32 PM
Weter, on 26 August 2022 - 07:39 PM, said:
Now, the general reference will be needed.
The actual information (at least I hope, that's so) can be seen on P.Newell's pages:
http://www.coalstone...rmat/#top-wagon
Because our MSTS ENG/WAG "bible" by Rudolf Richter might be not enough for ORTS era.
The actual information (at least I hope, that's so) can be seen on P.Newell's pages:
http://www.coalstone...rmat/#top-wagon
Because our MSTS ENG/WAG "bible" by Rudolf Richter might be not enough for ORTS era.
Thanks for the link, weter. I'll have to study these pages well, sometime.