Part 5. How To Do A Merger Project
How To Do A Merger Project
This is an approach on how to do a merger project. It is not error free or all-inclusive, nor does it contain the best or only ways to do things. But it does offer one builder's interpretation of what one needs to know, figure out, and do when undertaking a merger project. The topics are:
- Understand The Fundamentals
- Prepare A Route For A Merger
- Perform The Merger
- Complete The Project
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Understand The Fundamentals
The more one understands the fundamentals of the MSTS world as depicted in the Route Geometry Extractor (RGE), the higher the odds for success in removal and merger projects. Fundamentals include how the MSTS world relates to the real world in terms of the locations and shapes of routes, the manner in which they are referenced and manipulated, and the factors that must be considered. Certain factors can be particularly complex and difficult to address. However, by understanding the fundamentals more fully, and employing certain techniques that can help deal with complexities, the odds for success can be increased.
Maybe what follows will help one gain that understanding if currently lacking. The best place to start is the MSTS world itself, where a route begins.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The MSTS world
- The default MSTS world is a flat area at one meter above sea level from which the shape and location of a route is set.
- RGE is used to display this world and create initial files.
- RGE can also be used to reshape an existing route with additions and deletions of terrain, called tiles.
- The user makes this choice with "File/New Route..." for a new route, or File/Select Route..." for an existing one.
- RGE displays the whole world in an initial window, but cannot load all the data necessary for user actions.
- It requires the user to "Zoom Region" twice to get to the desired region containing the data for a route's area.
- Regions have demarcation lines (grid) to differentiate one from the other.
- After that, the user can "Zoom Window" in or out to facilitate selection of the area (tiles) to add or delete.
- Zooming is done by placing the cursor in a desired location and right clicking.
- A route may span from one region into another. Each requires its own region and window zooming, and user selections.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
World grids and tile structures
- Like the real world, MSTS uses longitude(east/west) and latitude(north/south) to indicate world position from zero.
- With the MSTS world being flat, values used for it's longitude/latitude will not precisely match the real world's.
- While both use degrees to indicate position from zero, MSTS also uses a 2048x2048m square as a location reference.
- This square is the familiar world file/tile, with its name indicating position east/west and north/south from zero.
- For design purposes, MSTS superimposes three types of grids with row and column names over its world to form squares.
- These grids provide coordinates which MSTS and the builder can use for identifying location/distance.
- The first is an invisible grid used as a base to translate cursor position to longitude/latitude and world file name.
- It is preloaded and consists of the squares that are used for defining "world" files with names displayed at bottom.
- A second grid (default) is for user selection of squares to become "regular" tiles used as close-in ground terrain.
- A third grid is Distant Mountains (DM) tiles, which are mountains seen in the distance as created by Demex not RGE.
- The user selects which grid to load by choosing the fourth icon at the top left for regular tiles, the fifth for DMs.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Tile size
- Tile size determines the amount of terrain area covered by the tile.
- The size of the grid square as set by the user determines the size of the tile that will be generated (created).
- Ideally regular tiles should be the same size as world files at 2048m on each edge (side), thus on a one-for-one basis.
- A builder can mistakenly create regular tiles that cover multiple world files, with 2, 4, 8, or more on a side.
- An example can be seen in an RGE display of the default USA1 route, near the bottom on the east side.
- (For those with little RGE experience, this would be a good time to try the steps above and see the example.)
- The issue can be prevented by always setting grid squares to the smallest possible size when creating regular tiles.
- Distant Mountain tiles cover many world files, and are usually eight or sixteen world files on a side.
- When tiles are larger than world files, they can have significant impact in merger projects. More about this later.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From grid to regular tiles
- First, an altitude must be set via Edit/Set Height Offset". The value specified should be the desired value -1.
- The general process is to set the grid squares to the smallest size, then select/populate/generate tile files.
- All of this can be done via a cursor drawn selection box, right click, then "Add All..." and "Extract Tiles...".
- Or it can be done in separate phases as follows.
- Setting the grid square to the smallest size is done via right click then "Split", repeated as necessary.
- The builder selects the grid squares he wants for his routes by "populating" them to flag his choices.
- To "populate" selected square(s), they must be toggled via right clicking and selecting "Toggle Populated...".
- Toggling will put an "X" into each selected square to populate it, or remove it to depopulate it.
- To create actual tile files for populated squares, they must be generated via clicking "Edit/Generate...".
- Regular tiles are stored in the "Tiles" folder. (Distant Mountains are stored in the "Lo_Tiles" folder by Demex)
- The regular and DM tile structures, its quad-trees, are created and saved in the TD folder upon "File/Save Quad-Tree".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The world files/tiles
- MSTS uses grids with column and row names as its primary location indicator for world files/tiles.
- Columns represent the distance east/west from the MSTS starting point, and rows represent the distance north/south.
- The MSTS starting point locations are different than the real world's starting point locations.
- Columns start at zero at the line (like a longitude) through Tokyo, Japan, with negative values to the west.
- Rows start at zero which is the circle (like a latitude) somewhere in/near/at the South Pole. Positive to the north.
- Distances in both cases are expressed as units, not degrees, with a unit being a single world file/tile (2048x2048m).
- These distances are reflected in the file names of world file/tiles.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
World file/tile naming format
- World file names represent the distance from the starting point. Each name reflects its location in the MSTS world.
- (The naming of terrain tiles is not covered here. Never saw the need to figure it out.)
- For world files, the first part in the name represents a column for east/west, the second part a row for north/south.
- Thus world file "w-11069+14261" represents 11069 units west and 14261 units north from the starting points.
- Because of this design, routes can be moved by changing world files names and updating data bases accordingly.
- This design, and others that allow reshaping a route and adjusting altitude, is what makes merger projects feasible.
- Tools that exploit these designs to implement changes to a route is what makes merger projects possible.
- As will be seen, these are intertwined and are performed in a preparation phase before an actual merger of two routes.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Moving a route:
- A route can be moved by TSUtil MOVE which manipulates world file names and adjusts references to them in data bases.
- It's like moving a puzzle piece next to another, but one or both may require some reshaping for them to fit properly.
- The distance it moves is based upon two values that must be derived by the user.
- A route can be moved in two directions (east/west and north/south) for a specified number of world files in each.
- The specified values must be whole numbers representing the number of world file units (distance) to move, or zero.
- As will be seen next, certain specific world file names will be used to derive the values to use with TSUtil MOVE.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Moving what to where
- It may make it easier to visualize a move by thinking of it as shooting an arrow to a target.
- Here, the terms "Arrow" and "Target" will be used to provide a mechanism to determine how far to move a route with MOVE.
- Arrow and Target can be determined by using the "JctWF" for each route.
- "JctWF" is the world file name representing the junction from which tracks will later be extended into the other route.
- "JctWF"s are selected during analysis of the routes using knowledge of the routes and RGE/AE/RE.
- Arrow is the "JctWF" of the route chosen to be moved.
- Target is adjacent to the "JctWF" of the other route, the open space to be occupied by the Arrow after a MOVE.
- The amount to move is derived by calculating the arithmetic differences in the two parts of two world file names.
- The difference between the first part of the Arrow and Target names determines the distance east or west.
- The difference between the second part of the Arrow and Target names determines the distance north or south.
- Positive values (with no sign) move east and north, negative values with a minus sign move west and south.
- Zero means no move in that direction.
- After providing the values to TSUtil, it shoots the Arrow to the Target, dragging the whole route with it.
- The objective is to get the routes to fit together as closely as possible with no overlap before a merge.
- An example of a move will illustrate.
An example of an unrestricted move:
- A route is to be moved a short distance east and south.
- All tiles are at the smallest edge size of one world file, thus it can be moved anywhere.
- World file -11057/14283 on the east side of the route to be moved is designated as its "JctWF", thus the Arrow.
- World file -11052/14270 on the west side of the route to be moved to is designated as its "JctWF".
- The open space adjacent to the "JctWF" of the route being moved to is -11053/14270, and designated as the Target.
- Thus the Arrow is -11057/14283 and the Target is -11053/14270.
- The value for the move east would be the difference between -11057 and -11053, which is 4.
- The value for the move south would the difference between 14283 and 14270, which is 13. To move south, value is -13.
- Therefore the values of "4 -13" would move the whole route east and south to the desired Target.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
You can't always move where you want
- If the largest tile in a route is one world tile on a side, the route can be moved anywhere in the MSTS world.
- But if the largest is larger than one world tile on a side, then the specified values must be a multiple of that size.
- For example, if the largest is a DM with eight world files on a side, the specified values must be a multiple of eight.
- Or if the builder mistakenly created a large tile at two world files on a side, then values must be multiple of two.
- If a restriction exists, it means that a route may end up near but not at the desired location.
- Default USA1 has a restriction. It can be easily removed with no harm because that area is not actually used.
- If a restriction can't be eliminated, then a gap is likely which will require filling in with more world files/tiles.
- This restriction is not a TSUtil deficiency. A large tile covers multiple world files, thus all must move as a unit.
- An example of a restricted move will illustrate the impact that large tiles have, and how to deal with it.
An example of a restricted move:
- A route is to be moved a short distance east and south, as above and with the same initial "JctWF"s.
- But this time, the route has DMs with the largest at 8 world files per side.
- Because of this, valid choices to move this route are restricted to 0, 8, 16, etc.
- The values "4 -13" from above are invalid and must be changed if want to keep the original Arrow or Target.
- If used "8" for the move east, Arrow would end up at -11048 (-11057 + 8 = -11049), east of the target route's "JctWF".
- Overlap will occur, thus not allowed. See more about overlap in the next section.
- Because of this overlap, the only choice for the move east is "0", which will cause a gap. See next section.
- The gap to fill would be 4 world file/tiles (the difference between -11057 (after MOVE) and original Target's -11053).
- If used "-8" for the move south, Arrow would end up at 14275 after MOVE. (14283 - 8 = 14275)
- This is north of the target route's "JctWF", which means no overlap, but now a gap to deal with.
- The gap to fill would be 5 world file/tiles (the difference between 14275 (after MOVE) and original Target's 14270.
- The proper values to use for this restricted MOVE are "0 -8" instead of the originally preferred "4 -13".
- In merger projects using routes with large tiles, reshaping of the route(s) is often required to deal with overlap/gap.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Overlap/Gap = reshape/move
- Overlap is when both routes have one or more tiles/world files with the same name, thus occupying same areas, a no-no.
- Overlap can be resolved before a merger by reshaping one or both routes via deletions, or by moving a route (via TSUtil).
- If overlapping tiles have world files with data base items, the data base items must be removed with one of the methods.
- Overlapping tiles can be deleted via RGE, FILTER, or both.
- Gap is when there would be empty space between routes, often created because of restricted moves.
- Gap can be resolved by moving and/or reshaping a route before or after a merger with added tiles to fill in the gap.
- Whenever reshaping is required, it often means a different set of Arrow/Target from initial choices.
- Ultimately, shape/Arrow/Target must be found that provides MOVE values that can achieve no overlap and minimum gap.
- One way to alleviate overlap/gap issues is to achieve a "straight edge" along the whole joining border, if possible.
A whole straight edge
- Sometimes routes can be reshaped to have a straight edge along the whole joining border where overlap could occur.
- Achieving a straight edge means removing all world file/tiles beyond the "JctWF" towards the other route.
- Many routes have excess tiles beyond their last tracks which can be easily removed with no discernable harm.
- If this can be achieved for both routes, then overlap can't occur - nothing would stick out into the other route.
- An example would be a route that is to be extended by another route, with both having excess tiles at their ends.
- If an eastern route's "JctWF" on the west side is at -12345/XXXXX, then all from -12346/XXXXX would be removed.
- If a northern route's "JctWF" on the south side is at -YYYYY/12345, then all from -YYYYY/12344 would be removed.
- Of course the same approach would apply to the other routes involved, but in the opposite directions.
- If straight edges can be achieved, the effort to reshape to prevent overlap can be significantly reduced.
- Otherwise, maybe a partial straight edge can be achieved near the "JctWF"s to help make things a little easier.
A partial straight edge
- It may not be feasible to have a straight edge along the whole border for both routes.
- This is when world files/tiles other than an "JctWF" might stick out beyond it, potentially into the other route.
- This is likely to happen when a route is to be merged into another at one or more "JctWF"s within it.
- Figuring things out and spotting/selecting/deleting tile/files in this case would be more difficult.
- Reshaping to at least a three world file straight edge with an "JctWF" in the middle might make it easier.
- Otherwise, individual tiles/world files will have to be dealt with on an individual basis, making things harder to do.
Regardless of border edge shape:
- Whenever reshaping includes the removal of tiles, any existing corresponding world files will have to be removed too.
- If so, then consider reshaping as a removal project. This means: pick one of the removal methods to use to remove areas.
- When lots of world files to remove, the CLRDB removal portion of the TSUtil CLRDB/MERGE may be best.
- When few to remove, the RE Delete method may be best.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Viewing, analyzing, and identifying
- In order to address overlap/gap, the builder has to be able to view the routes in displays, on paper, and in his mind.
- Unfortunately, RGE displays only one route, making it hard to determine where world files and tiles might overlap.
- To assist, one can create and use a small hand-drawn RGE-like matrix as a worksheet to mark pertinent info onto.
- It could be a box matrix consisting of smaller boxes with five along each side, one matrix for each route.
- Pertinent rows and column names from the RGE display and the "JctWF" can be marked onto the worksheet matrix.
- Tiles that can be deleted and other notes can be marked on it too.
- Thus the matrix worksheet could be a subset for the border area around the "JctWF" of the real RGE display.
- I found that such worksheets used in conjunction with RGE/RE helped to view/analyze/identify, but it's still not easy.
- In the following link there are some other explanations and techniques that might help when viewing routes.
- http://www.trainsim.com/vbts/showthread.php?235096-Quad-Tree-file&highlight=quad+tree
- The next section includes a way to view two routes in one RGE and one AE display, and identify any overlap.
- In fact, this is done automatically in one of the first steps of the approach described below.
When one has a sufficient understanding of the fundamentals, he is in a position to learn more about how to prepare a route for a merger, the hardest phase of merger projects.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Prepare A Route For A Merger
Preparing a route for a merger is doing the necessary tasks to ensure that each route will be in its proper location, shape, and altitude before the actual merger of files and folders of the two routes. To do so, a route may have to be reshaped, moved, and have its altitude adjusted. Any reshaping involving removals of world files with data base items in them will have to be done in conjunction with one of the methods in order to synchronize data bases for those world file changes.
For help when using methods, tools, and functions described below, refer to the "how to"s in:
- Part 2 for the usual methods
- Part 3 for the TSUtil CLRDB/MERGE method
- The Appendix for RGE and the TSUtil and Route_Riter functions
Here is an approach for preparing a route for a merger, starting with an overview:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Overview
- Check to see if both routes use Mosaic files
- Conduct a trial run of TSUtil MERGE
- Conduct an initial analysis of the routes
- Find out if a MOVE restriction exists
- Conduct an unrestricted move, then skip the next two
- Eliminate or reduce a restriction if possible
- Conduct a restricted move
- Adjust the altitude of a route if necessary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Check to see if both routes use Mosaic files
- Use these steps to see if there is a possible showstopper caused by the use of Mosaic files in both routes.
- Check the Terrtex folder of each route. Look for sequentially numbered files such as "mosaic_0001", "mosaic_0002", etc.
- If both routes contain such files, they will have same names but different content in most cases.
- If so, terrtex files from the primary route will prevail. Their use in the secondary portion may not appear correctly.
- No need to continue until/unless resolved, unless you want to address the issue after the actual merger.
- Otherwise, proceed to "Conduct a trial run of TSUtil MERGE", next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conduct a trial run of TSUtil MERGE
- Use these steps to see if there is a showstopper caused by data bases that won't merge. No use continuing if so.
- Back up the routes, and have Route_Riter at its most current level, at least 7.6.18 (26 Aug 2011).
- Run MERGE. The only purpose is to view results. Either route can be primary. Don't worry about preparation.
- Check the bottom of the Report Form. It may indicate a need to "Horace", some other problem, or program completion.
- If need to "Horace", do so and repeat trial run. Use TSUtil CVRT, global swapping, or Horace as desired.
- If some kind of a problem, refer to "When Things Go Wrong" and repeat above if fixed. You may or may not be successful.
- After successful MERGE completion, copy the contents of "newRoute" folder back into the route's main folder.
- Load the merged route into AE to see if the data bases load okay. Activity related errors can be ignored.
- If doesn't load, data base errors exist in one or both routes that prevent successful processing by TSUtil.
- If fails to load, try again after restoring the primary and using original secondary as primary, or troubleshoot.
- When a merged route loads in AE, this means that it is worthwhile to continue, though there still may be issues.
- You can now view two routes in a single RGE or AE display. Also, the merge log contains a list of any overlaps.
- Refer to "How to get two routes in one RGE or AE display instead of just one, and find overlap" below.
- With RGE and AE displays and worksheets available, an initial analysis can be done.
- Proceed to "Conduct an initial analysis of the routes", next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conduct an initial analysis of the routes
- Use these steps to get a quick indication of what to expect in terms of degree of effort and difficulty.
- View and use RGE and AE displays and any worksheets to determine the relative locations of the two routes.
- If a gap, reshaping may be necessary to fill the gap, and/or a route may have to be moved.
- If no or slight overlap, maybe some trimming along the borders will suffice, and not a move.
- If more extensive overlap, maybe it can be removed via reshaping without a move, especially if overlap is excess tiles.
- Once you decide you are done with the initial analysis of the merged route, restore the primary.
- You want to ensure that both originals are in place before doing analysis and reshaping on them which follow.
- Now you can use the RGE/AE displays of the original routes and worksheets from the trial merge for analysis.
- If you decide a move is not necessary, reshape as necessary and proceed to "Adjust the altitude of a route..." below.
- Otherwise a move is necessary.
- Reminder: The terms "JctWF", "Arrow", and "Target" are used below. They are defined in "Moving What To Where" above.
- Proceed to "Find out if a MOVE restriction exists", next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Find out if a MOVE restriction exists
- Use these steps to see if a move restriction exists in a route to be moved, thus determining which type of move to do.
- Before proceeding, be sure that both original routes are in the Routes folder, and not the one from the trial merger.
- Pick a route to be moved.
- If you already know the route to move has a restriction, skip to "Eliminate or reduce a restriction if possible".
- If you already know the route to move has no restriction, skip to "Conduct an unrestricted move" below.
- Otherwise, use RGE or a trial move to determine if there is a large tile that forces a move restriction, or not.
- In RGE, look for larger "X"s including DMs. If see any, proceed to "Eliminate or reduce a restriction if possible".
- Otherwise, if no larger "X" in RGE, proceed to "Conduct an unrestricted move" below.
- If don't want to use RGE, do a trial run of MOVE. It will quickly and easily disclose a restriction if any.
- You can do this by doing a MOVE using "1 1" as values. The only purpose is to see the Report Form.
- Check the bottom of the Report Form. It will report the route moved, a move restriction, or a problem.
- If a problem, see if you can fix it and repeat the trial MOVE above.
- If a restriction, write down the multiplier value, exit with "No", and proceed to "Eliminate or Reduce..." below.
- Do not respond "Yes" to Route_Riter's offer to copy "newRoute" into the route. If do, restore the route after MOVE.
- If moved (thus no restriction), exit with "No" and proceed to "Conduct an unrestricted move", next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conduct an unrestricted move
- Use these steps to move a route when it has no move restriction. It can be moved anywhere. Reshaping may be desirable.
- Analyze each route to choose its "JctWF" and the tiles/world files to delete/add for reshaping if necessary.
- This is where RGE/AE displays and worksheets (single route or both routes) are used to conduct the analysis.
- To help identify a JctWF", latitude/longitude in AE can be used with RE or Route_Riter to find its world file name.
- During analysis, see if able to achieve a straight edge along the whole border towards the other route.
- Reshape the route accordingly. Use one of the removal methods when deleting world files containing data base items.
- If you have little experience with RGE, refer to "How to use RGE to reshape a route" in the Appendix.
- Designate the "JctWF" of the picked route as the Arrow.
- Use the "JctWF" of the target route to derive Target. Target is an open space next to the target route's "JctWF".
- Derive the values for MOVE by getting the east/west and north/south arithmetic differences between Arrow and Target.
- Run MOVE using the derived values. Check bottom of Report Form.
- The move should complete without restriction. If it has one now, this means one was created during reshaping. Fix it.
- Respond "YES" to let Route_Riter copy "newRoute" into the route assuming successful completion of MOVE.
- That's it. The moved route should be at its proper shape/location a for merger, but may need an altitude adjustment.
- Proceed to "Adjust the altitude of a route if necessary".
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Eliminate or reduce a restriction if possible
- Use these steps to see if you can eliminate the restriction value to make subsequent steps much easier, or to reduce it.
- If you encounter a restriction, consider picking the other route as the one to move if it has no restriction.
- If you decide to pick a route to move that has no restriction, proceed to "If no MOVE restriction" above.
- If you already know that the move restriction can't be eliminated or reduced, skip to "Conduct a restricted move" below.
- See if DMs exist by loading its quad-tree in RGE, and assess if they overlap with the other route.
- If DMs exist and overlap, then reshaping or complete removal may be necessary
- To delete all, use RGE or just delete the LO_Tiles folder and the "lo_td_idx.dat" and "*.tdl" files in the TD folder.
- Otherwise analyze the route to see if you can remove or reduce the restriction by reshaping.
- If can, reshape the route accordingly, using one of the removal methods as appropriate for world files.
- Always reshape to the smallest size possible.
- If you were able to eliminate all large tiles by reshaping, proceed to "Conduct an unrestricted move" above.
- Otherwise you still have a restriction, but you need to know its size.
- If you were unable to reduce the size of the restriction, it should be the same as you noted during the trial move above.
- If you were able to reduce it, you should know the value for the current largest tile after your changes.
- If you don't know that value, don't proceed until finding out what it is via RGE or another trial run of MOVE.
- Proceed to "Conduct a restricted move" when you know the restriction value, next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Conduct a restricted move
- Use these steps to move a route that has a restriction that can't be eliminated.
- The distance to move has to be a multiple (divisible by) the restriction value determined from RGE or a trial move.
- Analyze both routes to pick an initial pair of "JctWF"s, one for each route.
- "JctWF" is the world file name representing the junction from which tracks will later be extended into the other route.
- This is where RGE/AE displays and worksheets (single route or both routes) are used to conduct the analysis.
- During analysis, see if able to achieve a straight edge along the whole border towards the other route.
- To help identify a JctWF", latitude/longitude in AE can be used with RE or Route_Riter to find its world file name.
- Do not do any reshaping now. You may need some tiles for filler in case a gap is forced by a restriction.
- Designate the "JctWF" of the route to be moved as the Arrow.
- Use the "JctWF" of the target route to derive the Target. Target should be open space next to the target route's "JctWF".
- Derive the values for MOVE by getting the east/west and north/south arithmetic differences between Arrow and Target.
- Check to see if the values are divisible by restriction size. See "An example of a restricted Move" above if necessary.
- If not, recycle through the analysis process to find a Target or other "JctWF"s that will satisfy the restriction.
- Reshape the route(s) accordingly. Use one of the removal methods when deleting world files containing data base items.
- Run MOVE using the derived values. Check bottom of Report Form.
- The move should complete without restriction. If one is reported, this means you need to recycle thru analysis again.
- Respond "YES" to let Route_Riter copy "newRoute" into the route assuming successful completion of MOVE.
- That's it. The moved route should be at its proper shape/location a for merger, but may need an altitude adjustment.
- Proceed to "Adjust the altitude of a route if necessary", next.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Adjust the altitude of a route if necessary
- Use these steps to adjust the altitude of a route to match the other at the border.
- Plant a scenery object in the "JctWF" near the border towards the other route.
- Note the "Y" value in the RE Object for the selected object. It is the altitude at that spot.
- If you use a track for this, its "Y" may be at the connected end, not the free end. Makes a difference if on a grade.
- Delete the object.
- Repeat the process above for the other route to get its altitude near the "JctWF" border.
- The arithmetic difference between the two "Y" values provides the difference in altitude in meters at the border.
- If don't need to adjust either route's altitude, proceed to "Prepare the other route if necessary" below.
- Pick the route whose altitude you want to adjust.
- Run TSUtil ADJH using the nearest whole number of meters from the "difference" determined above, up or down.
- Respond "YES" to let Route_Riter copy "newRoute" into the route assuming successful completion of ADJH.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Prepare the other route if necessary
- At this point one or both routes should be prepared to be in proper shape, location, and altitude.
- If both not yet prepared, perform the appropriate sections above for the route needing it.
- That's it for the preparation, ready for merger.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Perform The Merger
Performing the actual merger is using one of the methods described in this document to actually merge data, files, and folders from one route into the other while synchronizing data bases with the changes being made. The merger could be for copied world files/tiles, or for both whole routes.
To perform the merger
- Decide which method you want to use for the actual merger, one of the usual methods or TSUtil CLRDB/MERGE.
- To merge part of a route into another via RE Rebuild or RE Select, refer to the "how to"s in the "Usual.." section above.
- To merge two whole routes, refer to "MERGE" in the "How To Use TSUtil And Route_Riter Functions" in the Appendix.
- That's it for the merger, ready for completion of project.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Complete The Project
Completing the project is performing the final tasks to join the routes into one.
To repeat from a previous section:
- Provide scenery, textures, and other files from one route into the other if not already present, including .ref file.
- Address possible differences in .dat files, signals, etc. that may require manual merging or editing.
- Join tracks, add scenery, and adjust terrain at the borders to get a smooth transition from one route to the other.
- Fix any conflicts caused by shapes/textures and terrtex files having same names but different content.
- Repair or replace activities that may have been affected by track changes in world files.
- That's it.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Closing commentary
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Results from projects like these can span from complete success, success with sacrifices, or complete failure.
- How a project will turn out depends upon many items, including interactions between builder, routes, tools, and methods.
- If one lacks skill/experience in building routes, such projects shouldn't be started until after gaining some.
- If one has that skill/experience but not in these methods, maybe this document will help one get started.
- If one has skill/experience in such projects but not all methods, maybe this document will provide new option(s).
As said before, this is FWIW and is just one builder's version about these kinds of projects and methods.
- There is lots of stuff along with lots of opportunities for errors, omissions, oversimplifications, and disagreements.
- If one is spotted, replace it with your own knowledge/skill/common sense. Serious ones may prompt revisions to this.
- If the TSUtil CLRDB/MERGE method works for you, great.
- If not, hopefully the other stuff will.
- Good luck.
That's it, except for some recognition of others, and the Appendix which follow.
- Thanks to all past/present contributors to the Route Design forum. They keep the route building engine alive and well.
- Thanks to Carlos-Heinz for TSUtil and to Mike Simpson for Route_Riter.
- Their remarkable contributions are truly indispensable to the route building community.
Chuck Rickert
|