To merge or not to merge...

[JimDep]

I could use some help deciding on whether or not to break down a large route to smaller sections. My concern is that once all the content is added, it will take much longer to load and that the overall frame rates might suffer. There are elevation changes that might make merging more difficult, I haven't tried it yet. For the most part, the track is done, along with approx. 10% of the scenery, but I could use some suggestions from others who might have been through this already.

I eventually would like to make the route available, so maybe breaking down the route in sections is a better approach? What other info can I provide?
Thanks,
JD

 

[davesnow]

I could use some help deciding on whether or not to break down a large route to smaller sections. My concern is that once all the content is added, it will take much longer to load and that the overall frame rates might suffer. There are elevation changes that might make merging more difficult, I haven't tried it yet. For the most part, the track is done, along with approx. 10% of the scenery, but I could use some suggestions from others who might have been through this already.

I eventually would like to make the route available, so maybe breaking down the route in sections is a better approach? What other info can I provide?
Thanks,
JD

The only advice (warning?) I can give is that in my experience, whenever I merge two routes, you will need to go back and check all industries for track that has become un-joined at the point where it joins the industry. This doesn't always happen, but many times it will. Also, industries may need to have product re-configured.

Also, if you break down a very large route into smaller sections, it might be good for people with slower PC's. I'd just make sure you have the different sections able to run independently of one another. Then, if a user decides to merge the routes, I'd make a text file with merging instructions.

I hope this helps. I'm not always the expert here, but these are just my observations.

 

[jytte]

Like davesnow says, a section is only of use to anybody, if it's an independent route. If you have to merge them again, you're back to the big route, so what's the point in that?

This is an interesting question though; to make a smaller route that eeeeveryone can handle, or to make a bigger route (more interesting?) that may leave some people out in the cold?????????

I'm curious JD, when you say "large route", how large is that? as in boards? or length of tracks? I'm asking, because I'm working on a relatively large route myself (289 boards), and I'm always wondering what the end result might be in the way of performance. As I understand it, it has more to do with how much is on those boards? I'm too inexperienced in this to know if I might have bit off more than my PC (and others) can chew.

I hope this is not off topic.

 

[stagecoach]

The larger the route the more content. More signals, junctions and train operations the slower the computer. When running a route the entire route is using the computer not just what you see. As said before dont break a route unless that section can be run on its own like town A to town D and in the second section town D to town H. Repeat the end parts so those who download can then delete the overlapping boards themselves, makes merging a bit easier. look at the yorkshire sections as an example.

 

[JimDep]

This route runs about 120 sq miles; 20 miles north of Denver, beginning a 60 mile trip up to Cheyenne WY. Included are 3 additional subdivisions with numerous industries and interchanges between BNSF, UP, and GRW shortline.

I like the idea of breaking up the route into maybe 8 subsections with the goal of merging them together. I suppose this could be done by using portals put in strategic locations. For my own purpose, I need to be able to have the track run continuously up to Cheyenne to simulate the distance/time of the local freight traffic.

To help performance as the content increases, I'm staying conscious of condensing the variety of trees, buildings, tracks, and splines. I'm creating many of the structures for the major landmarks, but should be able to reuse them in different areas.

Even with this strategy, I'm concerned how this will slow down my system as more content gets added. So far I'm still getting frame rates in the 30's for the more congested areas, but I don't want that to suffer as more content gets added through out the route.

The boards are done, but how do you get the total number?

 

[HiBaller]

JD:

You can go HERE and get my ErazorA Program. There is a top menu item under File -> GND File Info that will tell you all you want to know about your GND file - including how many boards your route contains. It will also tell you how full your texture table is getting (there is a max of 256 textures you can use on a given route). It is also handy for eliminating any pesky textures you may have inadvertently put down and want to get rid of.

Bill

 

[JimDep]

Wow Bill, this is a "must have" for me. Thank you!
I wish I had it when I started many moons ago. Before I knew of the texture limitation of 250, I carelessly maxed it out along time ago. Since I'm creating textures of the actual terrain and ballast of this region, I'm having to write over the 3rd party textures that I somehow incorporated. I wish I'd used less of the built in textures!

Thanks again, I'm gonna jump over and download your Erazora program.

Jim D.

 

[jytte]

As for my own layout, I always know exactly how many there are (boards). If I'm interested in the number from another layout, I just count them on the minimap.

 

[HiBaller]

Counting boards on the minimap is ok, but when you get up into the many hundreds it gets a bit awkward because you can't zoom out far enough to see the whole map. If you don't, then you run the risk of not counting (or double-counting) some boards. I wrote ErazorA for just that eventuality. All you have to do is run it once and your board count is done.

Bill

 

[JimDep]

Using the ErazorA program, I discover I currently have 1749 baseboards. That number will grow another 50 to 100.

So...to merge or not to merge?

 

[jytte]

Using the ErazorA program, I discover I currently have 1749 baseboards. That number will grow another 50 to 100.

Yikes! That is BIG!

 

[jytte]

Counting boards on the minimap is ok, but when you get up into the many hundreds it gets a bit awkward because you can't zoom out far enough to see the whole map. If you don't, then you run the risk of not counting (or double-counting) some boards. I wrote ErazorA for just that eventuality. All you have to do is run it once and your board count is done.

Bill

I'm a little leary about the name "Erazor", what else does it do??

 

[JimDep]

I better let Bill explain his program. I just needed it to get the baseboard count for right now.

Edit: OH...you WERE asking Bill to explain it. whoops.

 

[HiBaller]

Jim:

The entire DHR was only 206 boards, so yours tops ours by quite a bit.

Jytte:

The thread HERE on our site explains it all. Basically,it will let you overwrite any texture you want to get rid of with a special texture (found on the DLS) by Narrowgauge so that my program will completely remove ALL textures under it AND the special texture also right down to bare baseboard. It removes the entry from the texture table also BUT ONLY if it isn't used anywhere else.

Bill

 

[jytte]

OK, thanks, I'll have a look.

 

[mononlaf]

Jim and others:

I've had a problem with merging routes that on at least one thread that I can't find at the moment someone has said is a bug in TRS. I'm using 2006, SP1.

The bug, if it really is one, is that after merge, TRS sees the merged map as read-only forever after - and saving a change means giving it a new name - every time you make a change. And that, of course, means updating the config file of any sessions for it every time also.

If you look up the status of the file, neither TRS nor Windows shows that it is a read-only file. But, at save time, TRS thinks it is.

Nobody else on this thread has mentioned this problem. Is that because it is not a problem for everybody? If it's not, does anybody have an explanation that would lead to my eliminating it in my system?

Dick

 

[JimDep]

I'm been having that problem for a while. I haven't done any merging yet, but while I'm working in "surveyor", every third save or so, I am prompted to have to save the route under a different name. Once saved with a different name, the sessions disappear from the menu (but are retained in CMP). I'm only doing occasional sessions for testing, so that's not a problem right now but it will be a problem down the road when the sections are merged into one large route.

Having the route done in sections would hopefully eliminate losing sessions, but once merging the route for the long runs would bring the problem back.
To retrieve the sessions involves going into CMP and changing the map number or session number in the config file so that they'll match. That wouldn't be much fun having to do that often just to run sessions.
Hopefully there's a better solution.

 

[robbiehanson]

I've merged a route or two...

All I've had to do is "Overwrite route yes/no".

Use at your own risk though!

 

[jytte]

I've had a problem with merging routes that on at least one thread that I can't find at the moment someone has said is a bug in TRS. I'm using 2006, SP1.

The bug, if it really is one, is that after merge, TRS sees the merged map as read-only forever after - and saving a change means giving it a new name - every time you make a change. And that, of course, means updating the config file of any sessions for it every time also.

Dick

Hmmm, never hear of that, but I'm rather new.

I have never merged anyone else's route. But when creating the route I'm working on, I needed to have extra "grids" in order to make it match a map i had printed out with grids, and needed to transfer to the boards (289 of them). To solve that problem, I made my own "grids" on a board by putting a little road-spline in a criss cross pattern on a board. Then started my layout in one corner and merging the "grid board" over and over again, each time "drawing" that particular part of the map, then deleting the roads, on to the next merge, and so on....
So I did 288 merges and never had a problem with it. I'm running 2006 SP1, maybe it's different in other versions?

 

[Dermmy]

In 06 you can mostly move a session to a newer version of the same map by opening the session config in CMP and editing the map-kuid tag to the kuid of the new route.

This may not always work if you have edited portals or any other 'fundamental' session info, but I must have moved the intro session for my Clovis route to a hundred edited versions of the map...