Revelations 12:28*
You can add comments to a reference file, (Ya Hoo).
Ok, You already have known this, but it is new to me. I'm tiring to build a route, and I bring in all kinds of content to try-out. I don't want dozens of 'class' divisions in RE, so I group things to my liking. At the same time I add the author to my "Credit Doc" file. However as I try so many different files I get confused what is by whom, and what is in or out. Who was the original author sometimes becomes obfuscated.
It seems to me if the text is not a 'key word', and there are no parentheses then it has no effect on the route. Now I've only tried this a couple on times, so this may not be so! I may not have loaded the files referanced. Please correct me.
As an example:
Static (
Filename ( "String16-20-A.s" )
Class ( "Bridges" )
Align ( None )
Description ( "String16-20-A" )
)
Static (
Filename ( "SRV_RR_Pier.s" )
Class ( "Bridges" )
Align ( None )
Description ( "SRV_RR_Pier" )
In the first entry a have to look up “Sandy River Tom” Werb, in the second entry the initials of the 'pen-name' prefaces the entry so it must be Ron Picardi.
If so, then in the 'route.ref' itself to be able to group by author it is a boon, and everyone can be given, in the end, just due credit.
The best to each of you in the New Year
Michael
*my own revelation
Page 1 of 1
.ref file text Adding Comments
#2
Posted 28 December 2012 - 11:04 PM
Generally speaking MSTS will ignore any line that begins with a # character without much regard to where it is found (by generally speaking I mean most of the time... you always have to test it). If you use the # character within the parens of some data variable you should consider placing your comments inside their own set of parens. I do that in the Lights() section of .eng files. Always test when you do inside the data area.
As for the ref file itself I find it far easier to read if you don't follow the Kuju suggested multi-line format. Mine are always like this (worth clicking on to enlarge):
example.jpg (322.68K)
Number of downloads: 26
Any MSTS can be presented that way, even world files, but if any organized this way are written to by MSTS the result will always revert back to the Kuju format (all of it).
Note my use of a prefix in the description parameter, over on the right margin in the first few lines of data; I use that on occasion when I need to subset a large class of objects, typically buildings or trees, and so I use 1 sometimes 2 letters as a prefix... the example seen at the very top -- L2 -- is a geographic location. Those that follow are out there somewhere but I've forgotten where so I havn't prefixed them yet. I will in due time. RE will sort the list of objects available to you by what you put into Description()... so IMO use it more fully to your advantage. The other thing I want to mention about the Description() is more to your issue: only about 22-24 characters will show up in the MSTS RE window that displays the values and whatever is after that is ignored. Seems like a fine place to add the contributors name. As a suffix behind whatever you want to see in RE it'll be out of the way but it will be in a very good spot in your .ref file.
Hope this is useful.
As for the ref file itself I find it far easier to read if you don't follow the Kuju suggested multi-line format. Mine are always like this (worth clicking on to enlarge):
example.jpg (322.68K)
Number of downloads: 26
Any MSTS can be presented that way, even world files, but if any organized this way are written to by MSTS the result will always revert back to the Kuju format (all of it).
Note my use of a prefix in the description parameter, over on the right margin in the first few lines of data; I use that on occasion when I need to subset a large class of objects, typically buildings or trees, and so I use 1 sometimes 2 letters as a prefix... the example seen at the very top -- L2 -- is a geographic location. Those that follow are out there somewhere but I've forgotten where so I havn't prefixed them yet. I will in due time. RE will sort the list of objects available to you by what you put into Description()... so IMO use it more fully to your advantage. The other thing I want to mention about the Description() is more to your issue: only about 22-24 characters will show up in the MSTS RE window that displays the values and whatever is after that is ignored. Seems like a fine place to add the contributors name. As a suffix behind whatever you want to see in RE it'll be out of the way but it will be in a very good spot in your .ref file.
Hope this is useful.
#3
Posted 29 December 2012 - 12:47 AM
Although I've seen and used Dave's suggestion, I haven't found it to be accurate 100% of the time.
I believe if you use the words, comment or skip at the beginning of a line then add a space then add your text within parentheses, MSTS will not read that line.
comment ( text within parentheses )
skip ( your text here )
Instead of editing these files, why don't you create a separate running text file to add each author to the list. You can then copy and paste it into your README file under credits.
That seems a lot easier to me, anyway.
;)
I believe if you use the words, comment or skip at the beginning of a line then add a space then add your text within parentheses, MSTS will not read that line.
comment ( text within parentheses )
skip ( your text here )
Instead of editing these files, why don't you create a separate running text file to add each author to the list. You can then copy and paste it into your README file under credits.
That seems a lot easier to me, anyway.
;)
#4
Posted 03 January 2013 - 05:38 PM
thegrindre, on 29 December 2012 - 12:47 AM, said:
Although I've seen and used Dave's suggestion, I haven't found it to be accurate 100% of the time.
I believe if you use the words, comment or skip at the beginning of a line then add a space then add your text within parentheses, MSTS will not read that line.
comment ( text within parentheses )
skip ( your text here )
Instead of editing these files, why don't you create a separate running text file to add each author to the list. You can then copy and paste it into your README file under credits.
That seems a lot easier to me, anyway.
:good2:
I believe if you use the words, comment or skip at the beginning of a line then add a space then add your text within parentheses, MSTS will not read that line.
comment ( text within parentheses )
skip ( your text here )
Instead of editing these files, why don't you create a separate running text file to add each author to the list. You can then copy and paste it into your README file under credits.
That seems a lot easier to me, anyway.
:good2:
Rick,
You are right it is easier to have a text file for credits.
here's a snippet from mine:
Structures and Details
Andy Miller,
Chama structures added 3/6/2010 (chamastr.zip)
Terrain textures (ctstrrtx.zip)
Stations Signs reskinned with permission.
“Sandy River Tom” Werb
Trestle kit (TrestleKitV1.zip)
Trestle kit ref file by Sean Kelly
Ron Picardi,
Bridges (srvnkit1.zip)
(srvnkit2.zip)
(srvnkit4.zip)
<Note all bridges use the silver version of textures, and most have been resized using Shape File Manager>
David Rowe
Queen’s Land Trestles
(qr_trestle.zip) ???
, but as i remove things, i don't always clean-up the text. No harm I guess.
However having the credit in the ref file will help me in the end. When all the unused stuff is removed, files and textures compressed, ect the creators will be with their content.
As an aside, the way Alex Lewis, put all the content read-mes in a Document folder on the CUESTA GRADE ROUTE, is a cool idea, too.
Michael
#5
Posted 05 January 2013 - 09:22 AM
MSTS should ignore any data group name that begins with an underscore.
GroupName ( GroupData1 GroupData2 )
_Comment ( This is a comment here which ends at the first )
GroupName ( GroupData1 GroupData2 )
_Comment ( This is a comment here which ends at the first )
#6
Posted 26 January 2013 - 08:28 PM
Basic, but valuable information, pinned for future reference.
Cheers Bazza
Cheers Bazza
Page 1 of 1