Message Areas - "Standardization proposal for tsection.dat and track sections"

Train-Sim.Com Message Areas

"Standardization proposal for tsection.dat and track sections"

Email this topic to a friend
Printer-friendly version of this topic
Bookmark this topic (Registered users only)
Previous Topic | Next Topic Conferences MSTS Route Design (Protected) Original message
OkrasaGhia (294 posts)
Apr-03-02, 06:06 AM (EST) "Standardization proposal for tsection.dat and track sections" This is a cross posting at www.train-sim.com and www.uktrainsim.com. If you think this should be posted on any other forum please feel free to do that as long as you forward this whole message. You may also translate the text if you think that appropriate. Only make it clear the message has been forwarded from www.train-sim.com.From previous discussions I hope it is clear that some kind of coordination of the tsection.dat file is necessary. This is the file specifying all track sections in the MSTS installation and it needs to be in sync with all routes you want to run. Unless we coordinate this we will find ourselves in an impossible situation where we can’t share and run each others routes.This is a proposal to how to handle such a coordinated file and making sure it stays coordinated with a minimum off effort from the involved parties.
Other goals of this proposition are that it should minimize the difficulties for the end user and (if necessary) put the responsibility on the route builders.Lets talk about the tsection.dat file (the one in the global folder, the one in your route folder is a different one). This file lists all track and road sections available in your MSTS installation. For each section it lists a unique id, the shape-file, length & radius of all paths, if it’s a tunnel and some other things. The important note in this discussion is the unique id that has to be the synchronized with any route you use. If you download a route built by someone else and that person has used add-on track sections you need to install those add-on track sections in your tsection.dat using the same ids. When more people make add-on track sections we are more likely to have developers using the same id and thus creating a conflict. But this is not all there is to it, dynamic track sections also use these same ids. In tsection.dat is stated the total number of ids used in the file and MSTS Route Editor reads this figure and adds dynamic track section immediately after it. For a standard installation the maximum id in tsection.dat is 262 thus the first dynamic track section used gets id 263. This becomes a problem when one wants to add new add-on track sections and like to assign them numbers above 262 (cause there are no more free numbers). You could add the new track sections well away from the numbers used by dynamic track but the problem is you don’t now exactly how many dynamic track sections there are (cause that depends on the route builder) and the Route Editor can’t handle this situation (but it seems you can run trains and activities which makes for some interesting possibilities). Routes can be converted to work in Route Editor with new tsection.dat files and this conversion is a one time job done by the route builder thus this is acceptable provided routes don’t need updating every month. We can avoid frequent needs for conversions by reserving ample of space for future track sections in the new proposed tsection.dat but then the question is how much is enough? Some say 100,000 or even a million (I don’t think we’ll ever see that many add-on track sections but that’s not important) but there is another problem with dynamic track sections and that is they do not work when ids get past 65,535 (may look like an odd figure but for a programmer it’s very familiar, Unsigned Integer). Thus the total range of ids is 0-65,535, MS/Kuju divided this as 0-262 for track/road sections and 263-65,535 for dynamic track. A new tsection.dat needs to make more room for track/road sections but still allow space for dynamic tracks. Suggestion is to divide the new file thus; 0-39,999 for track/road sections and 40000-65,535 for dynamic tracks. Each dynamic track uses at least 2 ids if it’s only a straight and more if it’s curving too thus on average you can have about 5-6,000 dynamic tracks in that space. Tests has shown that if we avoid using those ids assigned to dynamic tracks in the standard routes (or other routes built without add-on tracks) those routes can still work as long as you do not try the Route Editor on them. Thus you could still run the standard routes without doing anything to them and you can run and/or build routes using add-on track sections at the same time without need for any reconfiguring between turns. The remaining problem is to determine how many ids to jump over before adding new track sections to make room for dynamic track sections in standard routes. This is much the same problem as before when deciding where to put the upper limit for the ids. Fact is though we don’t need to make this decision, instead we can add new track sections from the top and work our way down (much like the stack and heap work in a computer). The first version of the new tsection.dat would have the standard track sections down in the range 0-262 and a number of add-on sections up in the range 36,000-39,999 leaving the range 40,000-65,535 open for dynamic tracks of new routes and leaving ample of space free from 263 and up for dynamic track sections in routes based on the original tsection.dat.David Beach has volunteered as the coordinator of the new tsection.dat and if we all agree he well soon release the first version. David will post a message with an e-mail address and a few guidelines on requesting ids and on getting track sections added to the issued tsection.dat file. This first version will include as many of the up to this date released track sections as their respective authors approve. Future versions will add more track sections to this file but never should a previous track section be removed in order to keep backwards compatibility. The release will only be of the tsection.dat, not the shapes and textures of the different track add-ons. It would be very nice if the release could be made as an installer which checks the versions of the previously installed file and the update in order to make sure the user does not replace a never file with an older but this then would have to be a specially developed installer. It is not necessary to have all track shapes installed even if they are in tsection.dat, you only need the shapes if they are used in a route in your MSTS installation. Routes using add-on track sections should clearly state which add-on track sections are used and which version of tsection.dat is used so that users can determine if they are able to run the route or if they need to install additional track add-ons. Track add-on developers should also state from which version of tsection.dat their package is included. The track package could (and probably will) include that version of tsection.dat and again it would be very nice with an installer which could automate the process while making sure you do not accidentally replace a newer version of tsection.dat with an older.This might be my longest posting to date but I hope as many as possible will read through it all and ventilate their opinion. There is always a group that will want to keep to the standard set of track sections and that is okay but for those that do want to have more various track sections I hope the above suggestion will be to their liking. Please note that this is not to be made part of XTracks, all add-on track packages will continue to be developed, released and maintained by their respective authors. Only the tsection.dat file will be a common community responsibility. For this to work we need the support of current add-on track packages and XTracks will support this, a new version with some additional tracks will be released as soon as a new tsection.dat standard is agreed on. Current routes using XTracks will need to be updated which can be done using Horace, I will also help anyone needing assistance to make the transition as painless as possible. It is unfortunate needing to change all again but I think the end result is worth it, no more problems with dynamic tracks because routes were built with different tsection.dat.

//Okrasa
Chief Engineer
okrasaghia @ yahoo.com
http://www.geocities.com/okrasaghia



Steam: 0-4-0T #9, 0-6-0 #12, 2-6-0 #25, 2-6-6-2 #37, 2-8-2 #40
Diesels: SW8 #16, F3 #53, F7 #54, FP7 #57, Budd RDC #61, TrainMaster #88 Alert Edit | Reply | Reply With Quote | Top
Table of Contents

Subject Author Message Date ID RE: Standardization proposal for ts... controll Apr-03-02 1 RE: Standardization proposal for ts... jleslie Apr-03-02 2 RE: Standardization proposal for ts... oboe Apr-03-02 3 RE: Standardization proposal for ts... controll Apr-03-02 4 RE: Standardization proposal for ts... ccyko Apr-03-02 5 RE: Standardization proposal for ts... davidbeach Apr-03-02 6 RE: Standardization proposal for ts... kxs156 Apr-04-02 8 RE: Standardization proposal for ts... enocell Apr-04-02 7 RE: Standardization proposal for ts... davidbeach Apr-04-02 9 RE: Standardization proposal for ts... beadyboy Apr-04-02 10 RE: Standardization proposal for ts... OkrasaGhia Apr-05-02 11 RE: Standardization proposal for ts... b101uk Apr-05-02 12 RE: Standardization proposal for ts... b101uk Apr-05-02 13 RE: Standardization proposal for ts... OkrasaGhia Apr-08-02 18 RE: Standardization proposal for ts... controll Apr-06-02 14 RE: Standardization proposal for ts... oboe Apr-06-02 15 RE: Standardization proposal for ts... davidbeach Apr-06-02 16 RE: Standardization proposal for ts... controll Apr-07-02 17 RE: Standardization proposal for ts... OkrasaGhia Apr-08-02 19 RE: Standardization proposal for ts... oboe Apr-08-02 20 RE: Standardization proposal for ts... davidbeach Apr-09-02 21

Lobby | Topics | Previous Topic | Next Topic
Messages in this topic
controll (564 posts)
Apr-03-02, 06:58 AM (EST) 1. "RE: Standardization proposal for tsection.dat and track sections" Okrasa,It looks like we are finally on the way to a workable solution for the Tsection.DAT file problem....thanks for the above statement and hopefully (as you said) everyone will want to get on board and become compatible with this issue....One issue you mentioned above is that the number for dynamic track is limited at 65,535 and no dynamic track will work above this number....will other addon objects work above that number so that we could leave 262-65,535 open and place everything else above 65,536? I feel this would leave enough open endedness to the file that problems would be gone.....did you test this issue?I am firmly behind whatever the decision for a number and solution for the DAT file is...and David is a brave soul volunteering for the job of keeping up the file.Let us know the verdict.Rick Remove | Alert Edit | Reply | Reply With Quote | Top
jleslie (138 posts)
Apr-03-02, 07:44 AM (EST) 2. "RE: Standardization proposal for tsection.dat and track sections" Sounds good to me, but like you said there will be a number of people who will not buy into this because they are afraid of changing from default. Maybe you can get Nels to make a seperate category in the file library devoted just to tsection.dat, so if for example my National Guard unit gets activated and I go away for 6 months, when I come back all I have to do is go there and get the latest tsection.dat file.Okrasa, I think you should take it a step farther and make Xtracks THE standard for add-on track sections. Here's your first vote right here. I can say this because I have made Xtracks work for me and I understand how to make it work, so I have no fear in using it.I can see that there will be people who need to have a specific track section for their own unique route. Curved turnouts would be great. Modular 5d and 10d turnouts would be great too. The use of the shape file from a1tpnt10d switch for the Xtracks scissor point is another issue. Other than those, Xtracks has provided me with everything I need to build my route. If I was to stay with the default track, I would still be in the stone age as far as track laying. If there is somebody out there designing a route and they have made their own custom track, they will just have to realize that they will have to get their custom track incorporated into Xtracks for them to be able to distribute. That would take some of the burden off you for desinging custom track sections. If I'm building a route not for distribution, then I can hack away all day at custom track, but if I want to distribute I'll have to get that custom track to be part of Xtracks. Sounds kind of Communist, but most people who distribute routes here appear to have bought into Xtracks anyway. If I don't want to use Xtracks in a route, then it should work anyway with your tsection.dat proposal.Hope I made sense here...Everybody is entitled to MY opinion....Jeff Leslie Remove | Alert Edit | Reply | Reply With Quote | Top
oboe (172 posts)
Apr-03-02, 11:23 AM (EST) 3. "RE: Standardization proposal for tsection.dat and track sections" This is great ...A copy of the post should be forwarded to KUJU ... I think that one section ( You guys decide the size )should be left open, or reserved, for home brew goodies. The reserved area could never be used for distributed routes, or uploaded track pieces, but would always be available for individuals that have created their own track sections for special applications on their own route. This would provide an area where an individuals efforts for their own use would always be safe, no matter what was uploaded.You are absolutely on the right track ( was that a pun ? )oboe Remove | Alert Edit | Reply | Reply With Quote | Top
controll (564 posts)
Apr-03-02, 04:23 PM (EST) 4. "RE: Standardization proposal for tsection.dat and track sections" Jeff and others,One issue that will come around eventually is that this is still a sim and folks want to be able to make it as they see fit and distribute it as they see fit...its not a situation that we have control of or could even stop if we wanted to...so I recommend that whatever course we take the route of having a file say that it is version whatever of Tsection.DAT compatible is about all we can hope for since people will make routes and put in what trackage types they are comfortable with and forcing them to become a type of track compatible will meet with difficulties and descention amongst users as to what is best or who should contol the situations.Just thinking about possibilities of what could and will happen.Rick Remove | Alert Edit | Reply | Reply With Quote | Top
ccyko (451 posts)
Apr-03-02, 05:31 PM (EST) 5. "RE: Standardization proposal for tsection.dat and track sections" I still am very leary about forcing users to have an outside program to run the Chicago-L. To me the extra complexity of having to keep track of versions, and what they have, need and how to find seems it will be more work on me, and them. Since I began route uploading last June/July, I have gone to great lengths to make sure the Chicago-L is self containing.-Chris
Chicago-L Remove | Alert Edit | Reply | Reply With Quote | Top
davidbeach (122 posts)
Apr-03-02, 11:37 PM (EST) 6. "RE: Standardization proposal for tsection.dat and track sections" Chris,The whole point to this reorganization is that custom track sections will be usable without additional software. There will be a transition for anybody who is using extended track sections now, but anybody who has not yet used extended track sections will not have to do anything.People who have used any extended track section will need to get a version of the standardized \global\tsection.dat file which includes the standardized reference for those sections. Once they have that file, they will need to use Horace to revise the references.Any route that does not use extended track sections will not ever need to have Horace run on it to use it as it is.When a route is released, the route developer will include a copy of the standardized \global\tsection.dat file that includes all of the extended track sections used in the route. The install routine will then have to compare the included tsection.dat file with the already installed \global\tsection.dat file. If the install routine discovers it has a newer tsection.dat file, it will overwrite the already installed file, if not it will not.The way this allocation of section and shape id numbers works, it will not have an impact on any route that is started after the standardized \global\tsection.dat file is first installed. The only routes that will be impacted are those which presently use extended track sections. The present situation means that any route that uses extended track sections is potentially incompatable with all other routes and all routes on any given computer have to be Horace'ed to work with a \global\tsection.dat file.There WILL be some transition problems, but once the transition is completed, the whole process should become far easier.David Beach. Remove | Alert Edit | Reply | Reply With Quote | Top
kxs156 (45 posts)
Apr-04-02, 03:33 PM (EST) 8. "RE: Standardization proposal for tsection.dat and track sections" I think what we should strive for is a standardized Track Expansion Kit. (T.E.K. And we make sure the expansion kit is 100% backwards compatible. That way developers can do two things:1) Use the basic MS setup, wth no fear of problems for users who have the expansion kit.or2) Use the expansion kit, knowing that many users will already have the kit installed since all expanded routes use the same kit, and knowing that those who don't can easily install it without fear of messing up other routes, future downloads, etc.This is an important effort and I absolutely agree with the previous poster that we should try to involve Kujo in this effort, or we might see it all go to waste when MSTS2 comes.Kaspar Strømme
Chief Engineer
MSTS Flåm Railway Remove | Alert Edit | Reply | Reply With Quote | Top
enocell (555 posts)
Apr-04-02, 02:48 PM (EST) 7. "RE: Standardization proposal for tsection.dat and track sections" I have my own track pieces(bridges) and custom tsection.dat. My route is still in beta so I can change the numbers if needed. I used IDs 1900-1906 for them.Maybe we should have a database so there wouldn't be duplicate IDs?Enocell Remove | Alert Edit | Reply | Reply With Quote | Top
davidbeach (122 posts)
Apr-04-02, 03:46 PM (EST) 9. "RE: Standardization proposal for tsection.dat and track sections" If you are designing custom track sections and would like to be included in the standardized \global\tsection.dat file, please e-mail your shape and section lines, along with the .s and .sd files referenced, to me at tsection@train-sim.com (thanks to Nels for hosting the e-mail alias). Not knowing whether I am unleashing a trickle or a torrent, I don't know how long it will take to get them assigned and integrated into one file. Once I have Build 0001 issued, I will start taking requests for id allocation.When you submit entries, please also provide a description of what the sections and shapes are, and your contact information. I will not furnish the .s and .sd files to anybody else, but will use them simply to test the entries in the tsection.dat file. Supplying the .s and .sd files to others will always be left to the route developer, I will only post updated tsection.dat files, and the tsection.dat file will include the contact information so that some one wanting to use a track section can know who to contact to get it or who to get permission from to release it in another route. Not including the .s and .sd files in what I release is also intended to encourage developers who may be intending to release payware track sections to use the standardized file.David Beach. Remove | Alert Edit | Reply | Reply With Quote | Top
beadyboy (183 posts)
Apr-04-02, 06:52 PM (EST) 10. "RE: Standardization proposal for tsection.dat and track sections" The thought has always occured to me of having a GUI for such a tsecion file. Users would just enter their pieces in blank fields and the program would update them to the tsection file.Of course you'd have to have a basic understanding of how the tsection file works but it may make things easier.Eg:TrackShape <__> - drop down box with choicesFileName <_______________> - blank fieldNumPaths <__> - drop down box with choicesMainRoute <__> - drop down box with choicesSectionIdx <_______________>
<_______________>
<_______________> - several blank fieldsNatually some fields wouldn't always require an entry. A tracksection gui would possibly be on the same screen.
This is just my best interpretation at this time of how it might look but I'm sure a programmer could come up with something. Just a thought.
Remove | Alert Edit | Reply | Reply With Quote | Top
OkrasaGhia (294 posts)
Apr-05-02, 12:27 PM (EST) 11. "RE: Standardization proposal for tsection.dat and track sections" Some points during the past days and my views /comments
(cross posted at train-sim.com & UKTrainSim)Q: Has anyone spoken to MS/Kuju?
C: Many have tried (regarding other matters) but none has succeeded to my knowledge.
It’s my belief they do not correspond with privateers, only companies.Q: Availability of the tsection.dat?
C: You only need to update the tsection.dat file when you download a route using new track sections or when you want to build a route using new track sections. It should not be a problem running a route developed by someone using version 10 on your system using version 9 (or even earlier) as long a s the route builder has not used any of the new tracks available in his version. The point here is to take the strain of the end user and put it onto the route builder. It’s not much of a strain either, just keep track of which “official” version of tsection.dat your route is based on.
I think track add-on packages should include the tsection.dat where their tracks were included. The file should come with an installer that checks the users current version in order not to replace a newer version with an older (anyone building such an installer?). The installer should ask confirmation before replacing a newer or unknown version.
The tsection.dat could be available by itself at different sites but there is no point updating the file unless you also add some new tracks to your installation.
(Matt (NeutronIC @ UKTrainSim), thanks for the offer but I don’t think there’s much point in distributing the file as is. Could be nice with a public page for info regarding it though).Q: Updates on a regular basis?
C: It only needs updating when new track add-ons are released and then I suggest the tsection.dat and installer is included with the track add-on. There is no point in having the tsection.dat only any way (see above).Q: Can ordinary sections be placed at IDs above 65,535?
C: No because if you have such entries in the tsection.dat any dynamic track sections added will get IDs above that and thus not work. We are stuck with 65,535 (at least until MSTS v2.0).Q: What about people not wanting to alter their installation?
C: Well they continue running routes based on the standard set of tracks as usual. Those upgrading can also run routes developed with the standard set. There’s no way we can accomplish the opposite (standard MSTS running route using add-on tracks).
Route builders MUST clearly state if they use add-on tracks, then it’s up to the user if he wants to update his system in order to be able to run the route. If not he should stay with routes for the standard MSTS.Q: Could XTracks be made THE standard track add-on?
C: Well, I don’t want that and there is actually no need for that. Different track add-ons can be released by different people and you install them when needed (because you want to run/develop a route with them). You don’t need to have all s & sd files for all track shapes that are in the tsection.dat unless they are used in a route on your system. The crucial part is that any new track add-ons get included in a new “official” tsection.dat and that the one releasing the track add-on does not include a home brew tsection.dat but the “official” version.Q: Could a section of the tsection.dat be reserved for private use of track sections never intended to be released?
C: Sure, that was actually my intention with the IDs 1900-1999 in XTracks 2.0 but I was unable to get that message out.
For this to work the handling of the tsection.dat file is crucial.
People must not hand out their own tailor made versions of it.
If you make new track sections get them included in a new “official” version.
Playing around with this and handing it out to others could easily mean disaster for users when they have other routes installed depending on tracks in a different version of the tsection.dat.
All installation procedures must include the official version of the tsection.dat needed to run the route or use the add-on tracks and it must include instructions NOT to replace a newer version.I have not seen anyone against this proposal thus I would like to give David a green light (I know he’s already started). David, if you need any help let me know.
I think included in the first version should be controlls and enocells bridges, Graham Pitts magnetic platforms, the Maglev by Craig Scott (currently being reworked), I think Chris in Chicago might have a few things to add (as David said our point is to take the strain of the user) and of course XTracks v3.0 (not yet released). Have I forgotten someone?
If anyone of you like to have your shapes included with the XTracks delivery (with credits of course) please let me know and I’ll do it. It’s not necessary having all shapes in one big package but it could be nice for the users not having to find many different downloads.

//Okrasa
Chief Engineer
okrasaghia @ yahoo.com
http://www.geocities.com/okrasaghia



Steam: 0-4-0T #9, 0-6-0 #12, 2-6-0 #25, 2-6-6-2 #37, 2-8-2 #40
Diesels: SW8 #16, F3 #53, F7 #54, FP7 #57, Budd RDC #61, TrainMaster #88 Remove | Alert Edit | Reply | Reply With Quote | Top
b101uk (53 posts)
Apr-05-02, 01:12 PM (EST) 12. "RE: Standardization proposal for tsection.dat and track sections" hi all
now i see its geting off the ground I have a requirment for
some entres in the tsection.dat.i nead about 60 TrackShapes entres, and about <20 TrackSections entres. but i have not desided wether to use them as roads yetb101uk Remove | Alert Edit | Reply | Reply With Quote | Top
b101uk (53 posts)
Apr-05-02, 02:43 PM (EST) 13. "RE: Standardization proposal for tsection.dat and track sections" i should have added a link to wot it is i working on see
http://www.train-sim.com/dcforum/DCForumID6/4065.htmlb101uk Remove | Alert Edit | Reply | Reply With Quote | Top
OkrasaGhia (294 posts)
Apr-08-02, 01:23 PM (EST) 18. "RE: Standardization proposal for tsection.dat and track sections" Get your sections sorted and all entries in the tsection.dat finished, then send everything to David at the tsectin address.
We don't want to give out ids in advance as people could easily under estimate the amount of work involved and then we end uo with a lot of not used ids.

//Okrasa
Chief Engineer
okrasaghia @ yahoo.com
http://www.geocities.com/okrasaghia



Steam: 0-4-0T #9, 0-6-0 #12, 2-6-0 #25, 2-6-6-2 #37, 2-8-2 #40
Diesels: SW8 #16, F3 #53, F7 #54, FP7 #57, Budd RDC #61, TrainMaster #88 Remove | Alert Edit | Reply | Reply With Quote | Top
controll (564 posts)
Apr-06-02, 07:50 AM (EST) 14. "RE: Standardization proposal for tsection.dat and track sections" Hi Guys,I think this is going to go well and I am all for doing it soon so as to put a close to the problem....however I think this issue needs to be addressed as well (and may have been on another of our discussions I can't remember) a naming convention for the S and SD files. If we are to start making pieces for routes and naming them without guidance then I can forsee that somewhere along the line we might end up with the same named objects and that will lead to problems...David could at that point contact the issuer and fix it or we could start out with a good foundation for this now and not encounter the problem in the future.
What does everyone think...do we need to address this as well?My idea for this was to put the creators initials or a picked set of two letter or more at the start of all our creations...this would do two things...first keep the naming convention from every duplicating anything we do and second give the editor of the Tsection.DAT and other users a guide to know who made a specific creation for easy contact info.The initials could go at the front or some other location in the name....examples below....FZ_Bridge_Girder_100M_Grey_DT.S
or
Bridge_Girder_100M_Grey_DT_FZ.SWe should also think of the naming for ease of selection by builders...so that they look into the RE object selector and see the sections they want (Bridge, Road, Track, etc) then they get a good description of the item from the name (Type of object beyond "Bridge", length, color, issuer,etc).I for one did not like the KUJU/MS naming of the track and other pieces when building a route because it was too cryptic...not enough info, had to review the folks who had mapped out what each piece was...this could fix that problem...for addons.Just an idea and I feel its needed but do the rest of you?Rick Remove | Alert Edit | Reply | Reply With Quote | Top
oboe (172 posts)
Apr-06-02, 04:25 PM (EST) 15. "RE: Standardization proposal for tsection.dat and track sections" LAST EDITED ON Apr-06-02 AT 04:27 PM (EST)Right on Rick:I would really like to see some sort of naming convention whether it's at the front or back, and I vote for three letter initials. I am currently preceeding everything I create with the letters "SSS_", and I will continue to do so. I will eventually be uploading using these initials at the front of both the directory names, and the filenames.This is part of a post that I wrote on Feb 2nd.:
_________________________________________________________ Most important is preventing duplicate files, and a simple method is for a person to apply his own initials or a routes initials to the filename 1. No central registry needs to be kept ( Except maybe for Initials. ) And a creator becomes responsible for his own filenaming structure.2. Nobody has to "apply" to anyone for a filename.4. DUPLICATE FILENAMES ARE VIRTUALLY ELIMINATED.5. Companies can still use things like USA2 or their own companies initials in the filename.oboe Remove | Alert Edit | Reply | Reply With Quote | Top
davidbeach (122 posts)
Apr-06-02, 05:32 PM (EST) 16. "RE: Standardization proposal for tsection.dat and track sections" B101uk,Send me an e-mail at tsection@train-sim.com with the lines from your tsection.dat file and all of the .s and .sd files and I will get them incorporated.Controll (Rick) & Oboe,The MS/KUJU section naming convention is definitely cryptic at first blush. When one gets used to it however, it has a certain logic to it. If I was looking for a particular track section to install in a route, I would rather look for it where it would logically be in the MS/KUJU naming scheme rather than having to remember who initially created it. I don't see any trouble with initials at the end of the name, and I am going to insist on contact information for every entry in the tsection.dat file, so any route developer can find the original creator of the track section.Oboe,The main point of a central registry, as you refer to it, is to coordinate the assignment of the id numbers in the \global\tsection.dat file. Frankly, I hadn't even focused on the (very real) need for unique .s and .sd file names.Okrasa,I would anticipate uploading each version of the standardized file, just so that route developers could see what new developments have been made. It is quite likely that the standardized \global\tsection.dat file will receive wider distribution than some of the track sections included and the revised file will give those sections exposure.All,This is really an attempt to make things better, but there will be a bit of a hassle for route designers during the transition. But there should be much less hassle for your users, and that is the point. I have followed the threads about Jim (Sniper297) Ward's xtrack in/out batch file and have been testing Chris Cyko's L2 route where he uses a presumably similar batch file to set up and remove a \global\tsection.dat file for his sections. This standardized file will eliminate that need while also eliminating the incompatibility problems encountered when using the original xtracks V1 and V2. The best of both world, we hope.David Beach. Remove | Alert Edit | Reply | Reply With Quote | Top
controll (564 posts)
Apr-07-02, 07:19 AM (EST) 17. "RE: Standardization proposal for tsection.dat and track sections" David & Oboe & All,I agree that the naming convention should have the initials or whatever we use to make the names unique at the end of the name so as to allow for the pieces to be catalogable (if this is a real word)....then we can have as I stated above a naming convention that allows users to find the pieces they want by type and then have some detail info added to the line for clarifications (Size, Color, Sub-Type, etc) my request is that we all begin naming our stuff with this new convention before inclusion into the DAT file...I know it will require us (designers) to redo most of our S And SD files and may cause some headaches for us at first....but once it is done the simplicity of the naming will come through. Here are my ideas for naming.....Type of Item ( Bridge, Road, Culvert(drainage), Buildings(tracked), Rail (Sections), etc)
Sub-Type (Girder, Truss, Moving Spans, Etc....)(each type above will have numerous sub-types)
Additional Sub-Type Parameters (Howe, Warren, Wood, Steel, etc)
Size (in meters)
Color (Grey, Blue, Yellow, etc)
Initials (or whatever we choose as the unique ID)
Number Of Object (What number in the series is it)Example:Bridge_Truss_Howe_100M_Grey_FZ1.SBridge_Truss_Howe_100M_Grey_FZ1.SDJust an idea so far refinements are definately needed for this to work and a knowledge of how much info can be placed into the RE selection window...so you can still see it for the effect.
The RE selection window may only accomodate 16 characters before truncating the text of the info line...so we should work within this parameter...to keep it simple and may have to show a line like this....Example:BRG_TRS_HOW_100M_GR_FZ1.SBRG_TRS_HOW_100M_GR_FZ1.SD
Just enough info to give the user what they need.Let me know what you all think of this.Rick Remove | Alert Edit | Reply | Reply With Quote | Top
OkrasaGhia (294 posts)
Apr-08-02, 01:28 PM (EST) 19. "RE: Standardization proposal for tsection.dat and track sections" "BRG_TRS_HOW_100M_GR_FZ1" hows that for a cryptic name
Even though the default sections name at first are cryptic when you start using them they do make some sort of sence and I don't see a point in addapting a completely different naming convention. It's true it needs some additions but I think we should try to conform to the same overall pattern.

//Okrasa
Chief Engineer
okrasaghia @ yahoo.com
http://www.geocities.com/okrasaghia



Steam: 0-4-0T #9, 0-6-0 #12, 2-6-0 #25, 2-6-6-2 #37, 2-8-2 #40
Diesels: SW8 #16, F3 #53, F7 #54, FP7 #57, Budd RDC #61, TrainMaster #88 Remove | Alert Edit | Reply | Reply With Quote | Top
oboe (172 posts)
Apr-08-02, 06:46 PM (EST) 20. "RE: Standardization proposal for tsection.dat and track sections" I like it .... Remove | Alert Edit | Reply | Reply With Quote | Top
davidbeach (122 posts)
Apr-09-02, 00:49 AM (EST) 21. "RE: Standardization proposal for tsection.dat and track sections" The first release candidate of the standardized \global\tsection.dat file was sent this evening to the two contributors who have provided entries so far. Should have the first release out soon.David Beach. Remove | Alert Edit | Reply | Reply With Quote | Top

Lock | Archive | Remove

Lobby | Topics | Previous Topic | Next Topic