Four Route Building Questions...

[K36487]

1.) How do I stop the "pop-up" mounatains in the C&TSRR?

2.) How do I make the flashing water stop?

3.) How do I add the water column to my Cumbres Pass Route? (same as a regular scenery object?)

4.) How was the movie of the Crawford Hill Route made? I want to make something like that for the RMNGRR! ;)

Thanks,

[calr]

I can answer one of your questions, #2 on flashing water. This has plagued many people since MSTS was released. The solution was just discovered in the past two months. Jeff Bush is the one who spent many hours researching this and came up with the solution. Thanks, Jeff for all your hard work.

There are two ways you can handle this problem. Both accomplish the same end result. All of the environment files (about 15 total) contain a section on water characteristics. There is a function named BlendATexDiff that is reference three times in the water section of each .env file. If this function is changed to BlendATex in each of the three instances, it will solve the problem. This must be done in all of the .env files.

The easy way to modify the .env files is to download the latest version of Route-Riter. This version has a function in the environment section which patches all .env files for the selected route.

As for your other questions, #1--You need to provide more information; #3 & #4 I don't know.

Cal Rasmussen
Beaverton, OR
cal.rasmussen@verizon.net

Columbia Gorge Route (Phase 1 track completed. Taking a TSM break!)

[Coonskin]

I can answer #1:

You can't. To stop the pop-in mountains you will have to re-DEM all of the DEM's at a lower maximum elevation. What you're seeing is the result of the highest terrain being at, or too near, the maximum elevation that MSTS allows: 3500 meters. To stablize the terrain, the DEM's for the entire route would likely need to be set at -1000 elevation offset.

Doing this on your route now would leave your tracks suspended in mid-air 1000 meters above your terrain.

Sorry.

Andre Ming

[DRGWK36]

The pop-up mountains are a consequence of the CTSRR v1.x being a "training" route, and not knowing these nice little details until it was completed. Version 2 will use NG track, and also has lowered the terrain the needed 1000 m.

Progress from Antonito - track to Lava, scenery to Hangman's trestle. A slight detour as I've been learning how to make rolling stock.

Andy

[griffinmt]

Relative to this topic, would a utilty that lowered the altitude of every object in every world file by a fixed amt be usefull. It would also have to do the equivilent in the tdb and rdb files. Anywhere else??

Martyn T. Griffin
griffinmt@mindspring.com

[Coonskin]

Hi Andy! Hope all is well.

Learning to build rolling stock? Cool! Looking forward to seeing some pics of your new rolling stock and progress shots of your new Chama line.

BTW, did lowering the terrain solve the pop up mountains?

Martyn: Don't know if that would help? Others have had the same malady, one large line in particular: The Marshall Pass line.

Andre

[griffinmt]

I was thinking that if it were possible to change the terrain altitude by a fixed amt across the board (EG: -500 meters), that would leave everything else 'floating' above (or below) by that amount.

Applying the following logic should resolve those parts, and all would be as before.


; \World folder, all .w and .ws files
; Locate the Position ( x y z ) lines
; change to Position (x y+delta z )
;
;
; route.RDB, route.TDB, route.TIT and route.RIT files
; locate all UiD ( a b c d e f x y z g h i ) lines
; change to UiD ( a b c d e f x y+delta z g h i )
;
; locate all TrVectorSections ( cnt a b c d e f g h i j x y z k l m ... ) lines
; change to TrVectorSections ( cnt a b c d e f g h i j x y+delta k l m ... )
;
; locate all TrItemRData ( x y z a b ) lines
; change to TrItemRDATA ( x y+delta z a b )


I am willing to give it a try if someone can explain the best way to alter the terrain (not a re-dem).

Edit: In fact, if a prototype program seems to make it work, it would be another great addition to Rout-Riter!!


Martyn T. Griffin
griffinmt@mindspring.com

[calr]

Martyn
I think you have some useful ideas there. However, I am not sure Route-Riter is the place for it. RR is a wonderful program but it is getting so many bells and whistles put into it that I fear it may be getting to large and complex for some people. I suspect that it is becoming a maintenance headache for the author, also.

Maybe it would be a good idea to split RR into two separate utilities and include your elevation changes into one of them. The first utility would be more related to the original purpose of packaging a route for distribution. The second utility would be a utility package on the order of the old PC-Tools and Norton Utilities but in this case for MSTS. Your terrain elevation functions could go in the latter version.

Food for thought, IMHO.

Cal Rasmussen
Beaverton, OR
cal.rasmussen@verizon.net

Columbia Gorge Route (Phase 1 track completed. Taking a TSM break!)

[lfriddle]

Martyn,
Sounds like a big job.
From what I can understand from the old posts by Deanville and JohnCS, and others, the Y.RAW files containing the DEM data wouldn't have to be changed. Just the base floor height which is located in the .t files. If that is the case, you would only have to find the byte location in the .t file and subtract the offset height. That information was also posted at one time. It's time to go searchin through the archives!
Larry

[griffinmt]

I can find the elevation value(s) in the T files cause I have an expansion routine for them.

I just assumed there is more to it than just that.

Isn't there something about when you change the ceiling height the value that gets multiplied by the .raw file values needing to change?

Martyn T. Griffin
griffinmt@mindspring.com

[davidbeach]

The thread to look for in the archives is the "glimmer of hope" thread.

[davidbeach]

If I recall correctly, converting the _y.raw values to elevations subdivides the distance between the floor and the ceiling into 65536 intervals, then the _y.raw value says how many intervals above the floor.

You will then need to delete all of the _n.raw and _e.raw files and let the program recreate them. DM terrain, if present would have to be re-DEMed unless JohnCS is willing to share all of his secrets.

[griffinmt]

David,

I have that thread downloaded into an xml file, just haven't had a chance to 'absorb' much of it yet. Gues I won't be able to put it off. Have the rest of it coded and 'partially' tested so far.

Martyn T. Griffin
griffinmt@mindspring.com

[griffinmt]

I have the code working to lower/raise every track and object in the route. Tested is on a couple of routes, raising by 10 meters. It certainly seems to work as expected.

What it doesn't do yet is raise or lower the terrain. Off to study some of those old threads.

Martyn T. Griffin
griffinmt@mindspring.com

[griffinmt]

When you expand the .T files in the Tiles folder, near the top is a token that list like the following:

terrain_sample_floor ( 2400.000 )

I haven't found any direct reference to the terrain ceiling, so assume it is factored from the floor??!!

Would you think that changing the above by +10 on every .t file would raise all the terrain?

Martyn T. Griffin
griffinmt@mindspring.com

[lfriddle]

Yep. Thats how the scaler is calculated. But since you only want to lower everything equally, the scale factor needs to stay the same. A 100 meter peak is a 100 meter peak. You only need to worry about the minimum height.
The formula was TH=TF+(SC*(RB(LB/256))). TF= floor height. Looks to me like lowering it without changeing anything else will just lower the starting height. If the ceiling height is also stored in the t file and a new scale SC calculated, then you would have to also have to lower the ceiling an equal amount to keep SC constant. I thought I understood that the values for TF and SC were stored, but not TC. No need to re DEM at all. (Edited for incomplet sentences from an incomplete mind)
Hope this makes some sense.
Larry

[griffinmt]

I know we sort of 'stole' your topic, and I appologize. But permit me to add a few more posts, since it is 'somewhat' related.

I have a utility 'working' that will lower/raise an entire routes terrain by a fixed amount. It also will lower/raise all world objects, tracks, roads, etc by the same amount. The end result appears to be completely unchanged, until you check the tile heights.

I have tested this on my own routes without any noticable problems, but have no doubt I have overlooked a few items.

I am looking for someone to try this on a 'complex' route with lots of 'stuff' and try to verify it is handling all the various parts.

It will take a while to run on such a route. All files that get modified save the original files with "-org" appended to the extension. Running multiple times will accumulate the changes, but not destroy the original files.

Did I mention that you should have a 'proven' backup/recovery methodology in place before trying!

EDIT:!!! Just after posting this, I realized that the Path files will also need a change made, relative to the start and end of the paths.
Also, I have NOT touched any LO_tiles entries, although now that should be easy. In progress today.

Martyn T. Griffin
griffinmt@mindspring.com

[griffinmt]

Just retested this with lowering the terrain by 500 meters. This included adjusting the paths and any lo_tiles.

It all seems to work EXCEPT for one single (but important) detail.

When I go back into the route with RE, the terrain in the immediate area becomes invisible, although I can see the terrain that is several tiles (128x128) away. As I move the camera, those farther tiles go invisible but the others behind start to appear.

It's almost exactly the opposite effect that other objects cause when they suddenly pop up as you get close.

Anyone haveany ideas??
Martyn T. Griffin
griffinmt@mindspring.com

[LoneWolf]

Well, I don't know Jack but did you remember to reassign the route start tile?

[griffinmt]

There is nothing in the .trk file (which holds the start location) that contains any altitude info.

Martyn T. Griffin
griffinmt@mindspring.com

[davidbeach]

Martyn,

Did you delete the _n.raw and _e.raw files and let the program recreate them? But there's the problem with modifying the lo_tiles, the program won't recreate the _n.raw and _e.raw files in lo_tiles.

[griffinmt]

Yep, The program automatically wipes those files, and they get rebuilt ok (all 1000 files).

Just took that route with the strange behaviour and ran the program over it again, but going back up 500 meters. Afterwards, the terrain appears normal.

So, there must be something else governing the behaviour, and something that is not sensitive to small changes but upset by large ones.

If John is listening, I'll bet he has some ideas!!

Martyn T. Griffin
griffinmt@mindspring.com

[lfriddle]

John,
I feel bad that your thread got hijacked, but it does seem to be a great break through.

Did you at least get your problems solved? If not let's start another thread, and this time we'll keep to the subject!
Larry

[JohnCS]

Hmm, missed this one.

Martyn, you're on the right path and have it down on just adjusting the tile floor - the ceiling will go along for the ride. What you're missing is the max/min/mean height entries for each of the subpatches in the tile (256 of them for a standard tile). I don't have them off the top of my head, but Deanville did document them correctly in that old 'glimmer' thread. You just need to offset them the same as you did for the floor. You might also scan the archives for a post by Dave Charles of DCM which included an attachment with some documentation on the t file format. He got a few things wrong in it, but IIRC that part was ok.

When you get that sorted I'd hold off on deleting the other raw files to force a rebuild. You definitely don't for the _n, and I really doubt it for the _e - though we never got into sussing that one out as it became unnecessary.

Aint no secrets to lo_tiles - I've shared them all here before. The t files are exactly the same as std, just some token parameters are obviously different to account for the differing number of sub-tiles. Here is where you really want to get away from deleting the n & e files as ts won't directly rebuild them for you here.

Oh, and by the way. The Crawford Hill video was made with Fraps (www.fraps.com)

[griffinmt]

John,

Here is a fragment of a .T file:


terrain_patches (
terrain_patchsets ( 1
terrain_patchset (
terrain_patchset_distance ( 0 )
terrain_patchset_npatches ( 16 )
terrain_patchset_patches (
terrain_patchset_patch ( 00000000 64.000000 1.000000 -64.000000 99.481255 0 64.000000 0 0.000100 0.000100 0.062500 0 0 0.062500 1.000000 )
terrain_patchset_patch ( 00000000 192.000000 1.000000 -64.000000 99.481255 0 64.000000 0 0.000100 0.000100 0.062500 0 0 0.062500 1.000000 )
terrain_patchset_patch ( 00000000 320.000000 1.000000 -64.000000 99.481255 0 64.000000 0 0.000100 0.000100 0.062500 0 0 0.062500 1.000000 )

There are 15 numbers for each patch. I treated them all as single float, although some may really be bitmasks or unsigned integer(??)

I assume these are the values you refered to. Have looked at that old thread and not found the reference you indicated. Any clues?



Martyn T. Griffin
griffinmt@mindspring.com
http://www.geocities.com/tcmrrc/

[JohnCS]

I just wanted to see if you were paying attention :)- its actually here:
http://www.trainsim.com/cgi-bin/dcforum/dcboard.cgi?az=show_thread&om=680&forum=DCForumID6

look in msg 9.

Sorry about that.

[griffinmt]

So the offsets of x11 and x1d would make them the third (1.00000) and sixth (64.00000) numbers in each patch. They are 69 bytes each, of which the first 9 bytes are the 8 byte token header and the single byte label length fld. So x11 (17) minus 9 = 8 which is the offset to the third float, etc.


------------------------------------
0x11_float = max_y_of_sub_tile - (max_corner_of_sub_tile - min_corner_of_sub_tile)/2

0x1d_float = (max_corner_of_sub_tile - min_corner_of_sub_tile)/2
------------------------------------

These two values are not as 'clear' as they seemed at first glance. Could you better explain what needs to be done to adjust them?

Thanks,
Martyn T. Griffin
griffinmt@mindspring.com
http://www.geocities.com/tcmrrc/

[JohnCS]

You seem to have the offset counts right.

0x1d is effectively 1/2 the 'thickness' of the sub_tile. Since you're not scaling anything this figure doesn't change.

0x11 is effectively the 'center' elevation of the sub_tile. Its the maximum height - 1/2 * thickness. Just reduce this by your offset.

[griffinmt]

That is all too obvious once you explain it!! :+ :+

While we are at it, have you mapped the other 13 entries, and I am curious WHY the TS needs to know the max height minus 1/2 the height difference?? Has it to do with averaging the view from a didtance?

Martyn T. Griffin
griffinmt@mindspring.com
http://www.geocities.com/tcmrrc/

[griffinmt]

John,

I have made the changes so that the fld at offset x11 in all 256 entries is adjusted. Also made the same change for the lo-tiles, but just for 16 entries.

Have gone back in and verified that the value has changed.

The terrain is still disappearing as I approach it. Actually, not ALL the terrain does this. It would appear that most of the default terrain is ok, as is 'some' of the other terrain selections.
Also, when in F7 mode, I don't seem to be able to select the terrain below me when it does show up, but I can after moving significantly to the side.

I am not deleting any of the _e and _n files.

So, there is more here than meets the eye (no pun intended).
Martyn T. Griffin
griffinmt@mindspring.com
http://www.geocities.com/tcmrrc/

[K36487]

That's OK. Could someone tell me if there is a way to fix the problem(s)? (without ruining scenery...)

And please, tell me in simple (clear) instructions.

Thanks,


http://www.trainsim.com/dcforum/User_files/3e3ec8ab1b5419ab.jpg
Future Cumbres & Toltec or Durango & Silverton Engineer.
http://www.trainsim.com/dcforum/User_files/3e418650495d19de.gif cumbres487@attbi.com http://www.trainsim.com/dcforum/User_files/3e418640490c57d1.gif
Go to my informative K-36 page:
http://www.freewebs.com/drgwk36

For progress on the Cumbres Pass route: http://groups.msn.com/MSTSNarrowGauge/ctsrr.msnw

[JohnCS]

Maybe the _e file does need to be updated, or you're not catching the right offset. Are you just modifying the bytes in the t file, or reading the whole thing in, detokenizing it and then retokenizing it? Certainly that would increase the variables involved.

I'll have to track down my notes on the other parameters.

As far as why the sim wants this information, its pretty obvious by the effects of not changing it. It uses it to clip out the subpatches which are outside the camera view, and also to detect mouse click location when selecting the subpatch in F7 mode.

[lfriddle]

Will the water height points have to be changed also, or is that value relative to the floor?
Larry

[dcm]

Martyn,

Not sure if you have solved this yet, but I had a very similar problem. First off, are you setting each subtile to the exact values for that subtile? I tried to cheat with this at a first attempt and set all subtiles to the same values, based upon the thickness of the whole tile - It didn't like that and things didn't display properly.

The other (odd) thing that I found was that there seems to be some limit on how high you can set the 1/2 thickness value - on one extreme subtile I had a half thickness value of about 300 meters and this seemed to cause strange effects. I found that reducing this value to a smaller number seemed to make things better - AS LONG AS the other value is set to the max elevation minus whatever you have set the half thickness value to.

This is a summary of the values I know about in the patch record (based on the compressed binary structure):


Water/Draw Toggles 4 bytes
water off/draw on = 00 00 00 00
water off/draw off = 01 00 00 00
water on/draw on = C0 00 00 01
water on/draw off = C1 00 00 01

ColumnID 4 (float)
identifies the column for this subtile

meanAlt 4 (float)
max altitude - meanDiff

Row ID 4 (float)
identifies the row for this subtile

unknown 4

meanDiff 4 (float)
(max alt-min alt) /2

unknown 4

TexInd 4
not fully investigated, probably a texture index

unknown 4

unknown 4

unknown 4
connected to tiling factor

unknown 4

unknown 4

TileFact 4 (float)
tiling factor

ErrorBias 4 (float)
error bias


Cheers

Dave C

[griffinmt]

Actually, I got frustrated and shelved it for a while. Think I have everything else covered though.

Based upon the behaviour, it has to also be relative to some other altitude measurement. It has the overall appearance that something else 'believes' the camera has gone below the terrain (actually the original terrain altitude), and stops rendering any terrain in the nearby vicinity.

Martyn T. Griffin
griffinmt@mindspring.com
http://www.geocities.com/tcmrrc/

[dcm]

I wonder whether some of those other unknown parameters comprise some kind of vector which describes the direction from which the terrain is visible. I'll have a bit more of an experiment with this.

Dave C

[K36487]

Great! NG Rolling Stock!! Andy, check out the K-27 that jonathanmlewisrgs and I are making! (not much yet...)

http://groups.msn.com/MSTSNarrowGauge/k27formsts.msnw

EDIT: Thanks guys!! :D