[Genma Saotome]

Ok, here are some more .w file tips then:

When adding street trackage you want the rail shape to be a specific distance below the street shape so only the top of the railhead shows. It actually needs a bit more than the top in order to be seen over distance and the amount of that "bit" is subjective. Here's what you do:

Add a single track of the same length as your street segment, placed about at the end and rotated roughly to be the same angle as the street. Do not worry about grade. Just ONE track. Then save.

Now open the .w file and locate that track segment (usually the last entry). Also locate the street segment, using the x position value as the the search method (one decimal place preswision is good enough). Verify you found the correct street segment by checking the y and z values in the .w file agaisnt the shape in RE. You want to do that as sometimes several shapes might have identical x values.

Having verified you found the right shape, copy the position and qdirection lines of the street shape and paste them over the same lines in the track shape. The Y value in the position line is altitude. For street trackage, subtract between 0.25m and 0.3m from the Y value to lower the track shape. The amount is up to you. Whatever value you use should be used at all times. Since this distance is a matter of personal taste, try 0.25 first. You can change it later. The qdirection value determins direction and grade. By using the values taken from the street shape, the track will now be perfectly aligned. Now save your .w file.

Return to RE. What you want to do now is force RE to re-read the .w file data. You do that by jumping several tiles away and back again. Jump at least 4 tiles. When you jump back, RE will need to re-read the .w file and when it does it will use the pasted in values. This step will go faster if the tile you jump to is empty. It is ok to jump off the route too.

Having jumped out and back again, to ensure the .tdb knows what you did in the .w file, you must mouse click the track once. You can see the .tdb action by noticing the thin, white, path lines above the track shape are not properly aligned before you click the track... and are aligned afterwards. That click tells the software to update the .tdb and redraw the path lines. Having done this, now assess whether the revised Y position value is suitable. If not, edit it again in the .w and repeat the jump away, back, and mouse click steps until you're satisified with the results. Then continue w/ the next steps.

Having aligned the one track shape in all ways -- length, direction, and grade, you can now add more tracks using RE. As you set down track shapes, I recommend you use the exact same length and grade as what the street does. The end result should be properly aligned track positioned an identical distance under the road because all of the new track shapes are position off the first one -- the one you placed so carefully.

A few warnings: the repositioning of the first track, as described above, will only work if the track shape is all alone. As soon as you add a second shape, connected to the first, you'll have all sorts of very bad problems is you edit the x, y, or z values. So don't do that. Get it right before you add any other tracks. If you add tracks and then decide the altitude should be different, pull out all but one of the street tracks, save in RE, and then start again to edit in the .w file. That'll be ok.

Sometimes street shapes are odd lengths, such as crossings. Just try your best to get the tracks shapes the same length as the street. Minor differences are ok... but they will add up.

Same problem as above... sometimes you cannot get the slope value of the track to match up perfectly to the road. Accept it and move on. It'll cause some discrepency over distance but at least you can compensate a bit as you go.

Last thought: Virtually all street shapes ignore the reality that streets have a "roadbed". Roads are not thin, flat shapes after all. This can be a problem if the terrain pokes thru these thin shapes and from what I've seen, selecting a street shape and pressing the Y key to adjust terrain often causes more problems than it fixes. So... if you want you terrain to stay down and not poke thru your street shapes, run some track under the streets, exactly as described above. Then, by pressing the / key, you can dip your camera underground and look up from below. Here, it's very easy to mouse select the track shape instead of the street shape. Select the track and press the Y key. As the track is lower than the street, the terrain movement will be to the lower altitude. When you are done, use RE to delete all those track shapes -- they've been used as tools, nothing more, so pull 'em out.

[Larry_M]

august1929, on Jun 22 2008, 12:21 PM, said:

...a plan so cunning you could stick a tail on it....

Well Bazza, at least one American friend did :shock6:

Cunning plan #2 is fairly simple, but it works.

To get rid of objects or replace them...

1. Open the World Tile in Wordpad (having backed it up first, of course).

2. Open the RE

3. Highlight the object you want to remove in the RE and right click - this will give you the co-ordinates.

4. Select the first number and do a CTRL>F search for the number in the open Wordpad doc.

5. Check the name of the object and other co-ordinates to ensure it is the correct one.

6. To replace - replace the Filename with the name of your new object (e.g. FileName ( Pine2.s ) )

7. To remove - it seems, from the limited testing that I have done of this (one object only! ) that the World tile doesn't seem to mind a gap in UiDs either - in other words having 4567, 4568, 4570. - If that is the case, then delete the object - This needs to be tested further with backup ready to replace.

8. Save

You are then back into the same sequence of copying and pasting into the full world tile using wordpad.

I have replaced 10 items tonight (tree billboards I didn't want in a particular location), then I have gone back into a deliberately clean wiped world tile, and have placed further tree objects around the rough location of the replaced billboards.

Net result - at long last this grossly overloaded tile is finished :unclesam: :stop: 1,929 objects in total.

Tested in sim and appears to be o.k. - Framerates the same as before (I am essentially placing the same group over and over - repeated textures etc.).

Tim - it seems to work - hopefully, though, with a bit more care, I won't have to resort to these underhand tricks again.

Rod

I installed the MSTS Patch 1.7.22, seems to give the ability to place a huge number of objects! I am well over 2200 on a few tiles with no sign of a save problem.

Larry

[Larry_M]

Larry_M, on Jul 7 2008, 12:46 PM, said:

I installed the MSTS Patch 1.7.22, seems to give the ability to place a huge number of objects! I am well over 2200 on a few tiles with no sign of a save problem.

Larry

I just located this bit of information in the Patch Manual. "number of item in Placement in Route Editor increased from 5 to 60"

And the patch does not need to be installed to run the route after the build is complete!

Larry

[Coonskin]

Many years ago a similar technique was used to pack more into tiles. Worked great until the route was compressed and packed for release. Once end users begin to download/unpack/install there were buildings floating in the air and all sorts of other weird stuff.

However, it could be that MSTS Bin has aided that issue IF the issue exists with what Rod is describing.

WHAT kind of machines do you guy's have that will DECENTLY run routes with 2500+ objects in tiles??????

Andre

[SAR704]

I don't agree with overloading tiles until they burst at the seams. I've tried this before, and the result is objects that won't load once you go over a certain threshold. There are countless threads everywhere that condone this, but the result is a route that is unpredictable, and prone to misbehaviour, as well as potential bad press post release. If a tile is massively overloaded, then you may find that half your objects are missing depending on where you load an activity or path. MSTS bin will increases the number of objects that can be saved. But it will not increase the threshold that causes MSTS to be unpredictable on this tile once it is breached.

Some of the time you can get away with a tile with 1600 objects, as long as neighbouring tiles are under the threshold which is usually around 1100 - 1200. But from experience, I have found that adjoining tiles with 1700 objects each is asking for trouble. If I get to more than about 2400 on adjoining tiles, it often means one is overloaded. It's then time to start deleting things.

Now not everybody may have experienced these issues. I am just quoting directly from my experiences over the past 18 months.

[Hack]

Sorry for coming late to the party. Here's a couple more w-file tricks...

One of the tricks I use are in the textures. For new objects, build them as normal, but before you spend the time mapping the object or assigning textures, just assign the same texture to the object, or the same texture for each multi-sub object (you can do this after mapping too). I use a small grey 32 x 32 ace file (temp.ace) for a bunch of buildings, place them using the RE, and once complete, finish off the model with the proper textures and export. The model's already placed, so no worries screwing with further edits in RE. MSTS only has to load one image for all these objects (when using the temp.ace), so the memory footprint is very small.

For models already completed, simply backup the textures to a safe place, and replace all with a small 32 x 32 grey texture and copied to match the names of the texures for the route (lots of itty-bitty textures). The small textures will take up only a fraction of the memory that the other textures would have, so you're left with oodles of memory space for all those objects and any additional RE edits. When done, simply copy the backup textures into the route's texture folder and viola!

Finally, don't add any dynamic shadows or other special object features via RE - add them to the world file once you're satisfied with object placement. Dynamic shadows and other features add bloat to the world file - all that can be used for additional objects instead. Adding features afterward in the safety of Wordpad is much better than risking it all in RE.

I'm kinda' sleepy at the moment, so I hope that all made sense. :blush:

[Genma Saotome]

And a few more: assuming you have used the slider trick I mentioned above, all of the track shapes will be at the top of each world file followed by all of the static shapes. Open up a few busy and adjacent world files and cut out the static shapes, pasting them into new files called whatever-the-original-world-file-name-was.static, and save. When you're next editing that areas tracks or roads you have a far fewer objects to load. You can also do the reverse, edit away the track and road shapes, placing them into whatever-the-original-world-file-name-was.track, but now you must also move the .tdb and .rdb files someplace safe. Then in RE you only have static shapes and again editing is quick as there are far fewer shapes on hand. To put everything together again, just cut whichever content was set aside and paste it back into the world file.

Forests: these are procedural "objects"... one entry in the .w file and the program calculates all of the data needed to let the GPU know where to "place" the trees. IMO forests often look rather poor... dunno why. And they're always just 4 faces, even in situations where 8 would be preferred. So instead of a procedural forest, build a real one: Pick a spot for your procedural forest and place it (the green "cube") then place all of you real (.s) trees in the same area as the procedural trees... right on top of each one and more if needed. Save. From the world file, find the location of the forest "cube" and write it down. Now in cad place something that locates the exact location of that green forest "cube", where ever it is within the tile. Then using all of the xyz data from the .w file, paste in your trees... 16 polys where you need them, 8 where they're farther away. This usually results in a lot of objects way the heck away from 0.0.0, but we'll fix that. When you're done placing the trees in CAD, grab everything and move everything at once such that the thing you placed for the forest "cube" is now at 0,0,0. This gives you an ordinary object that you can now use to replace the forest, with every tree at the same relative location to the CAD 0,0,0 origin as are all of the trees you placed relative to the forest "cube" location. Open up the world file and subsitute your created forest object for the procedural one -- same location. Also, find and delete all of the individual trees you placed to mimic the procedural forest. Next time you are in RE, or playing the sim, you will see your newly created forest located exactly where the procedural forest was, it looks better, and still counts as just one object.

You can do the same thing w/ grass clumps... those things that usually require a handful of objects in order to look right -- find one that looks right and make it all one object instead of collection of many.

[Hack]

Re: Forests. Sounds interesting, Dave, but I'm afraid you lost me on that one. :blush:

[Genma Saotome]

Hack, on 26 February 2010 - 10:51 AM, said:

Re: Forests. Sounds interesting, Dave, but I'm afraid you lost me on that one. :blush:

Yeah, I seem to have a hard time describing this one... basically I'm trying to describe how you can replace a forest with an identical static object of many trees. To do so you need to know where the trees are in the forest and the easiest way to do that is actually plant some temporary object (like a tree) right on top each of the generated forest tree. Their xyz data will then be found in the .w file after you save. You use all that data to determine the location of equivalent trees within your static model.

Because the origin point of forest "cube" is seldom located in the very center of a tile, you will want to move all of your CAD trees, in the CAD tool, in one big movement, over towards 0,0,0. This is how you do that: Say the green forest "cube" is at -645.479 47.7543 307.8743. In Cad you place something at that exact coordinate location. Use the XYZ coordinates of the temporary trees and create (copy/paste) trees at those xyz locations in CAD. They're all going to be off somewhere around -645.479 47.7543 307.874 in your model. When all that work in the CAD tool is done, the last thing you need to do is relocate all the cad based forest trees towards 0,0,0, making sure the thing you placed to represent the forest cube goes right to 0,0,0. All of the trees in your static model must be moved at the same time so their relative location to the origin point remains constant. When you get around to placing this new object into the route you can do it in an editor by using the coordinates of the forest "cube" as the placement location of your static model. Then cleanup by deleting the entry for the forest "cube" and deleting the entries for all the temporary trees. What's left is one instance of your new static shape and when you look at it all of the trees therein will be found in the exact same locations as the original forest. The only differences are your static model will look better and the trees could have 8 faces instead of just 4.

Make sense now?


You can also get tricky about the origin point... ignore the forest "cube" location and instead use something else, such as a track location over on the mainline. With the origin point of your static model over at the track the max distance from camera to object is different... it's going to be closer and so that new object will stay in view a bit longer than had you used the forest cube location as the origin.

[Hack]

Genma Saotome, on 26 February 2010 - 12:04 PM, said:

Make sense now?

Yep - I'm not the brightest bulb in the pack, but given time, I usually come around. What threw me was the mention of CAD, but your recent post pointed out a few things missed in the first.

I did a similar thing when placing some city modules on the Sherman Hill route - each on big fat object to save space in the world file, and noting the x-y-z coordinates to get everything to snuggle up where I needed them. Place one object, and then transfer the x-y-z data into Max. Time consuming, but far better than having to do things over when the RE blows up a world tile - something I've run into from time to time before. Your forest procedure I hadn't thought of, which would have saved some headaces when trying to solve the terrain vanishing at distance below a "normal" forest object. All moot I suppose, as I'm fully entrenched into Railworks. Nevertheless, your idea helps to keep me thinking outside the box when editing.

[Eldorado.Railroad]

august1929, on 20 June 2008 - 06:43 AM, said:

In the thread "Microsoft Terrain Simulator" in screenshots, I was bemoaning that, even using Swissie's approach to getting beyond the 500-550 kb size limit for the World Tiles, I was getting 3 out of 4 save attempts still wiping out all objects. (not a problem as long as you remember to backup after each successful save - just slow).

I have read this post a couple of times and I am curious if "500-550 kb size limit for the World Tiles" means before or after the file has been compressed? This makes a big difference of course!

I have tried to limit objects to not more than 2500 objects (and usually lower) due to random crashes when pressing function keys. As Lukas has discussed elsewhere, the problem is due to adjacent overloaded World Tiles. In my case, I have had to edit World Tiles with 3200+ objects when adjacent tiles were also in the 2000 objects range (eg: Stowe, Vermont). Once I decrease the number of objects the crashes go with it. I am sure this is "old news" to the "old hands" with MSTS. In my research, there seems to be a bunch of "magic numbers" posted on the internet over various years for object counts on World Tiles and I have settled with as near to 2000 as possible.

[c36dash7]

Eldorado.Railroad, on 31 May 2010 - 02:49 PM, said:

In my research, there seems to be a bunch of "magic numbers" posted on the internet over various years for object counts on World Tiles and I have settled with as near to 2000 as possible.

Feedback : As mentioned as part of this very informative thread, was the presence of MSTS BIN . Using MSTS BIN , instantly allowed the number of world objects per tile , to increase ( from the non- MSTS BIN / Kuju defaults ).

I, too, had read such as "1,350" world objects , and / or , such as 800 Kb for World file size, as being "thresholds" . Experience from many , now shows that both thresholds have been exceeded .

But the fact remains that we often get distracted by the fact that , in Route Ediotr, our "primary" type of view, is along the lines of being in a "construction crane" .

From that point of view, yes, it is very tempting to "fill in" all the space on a Tile, so that it eventually looks somewhow "full" .

Experience in the InGame mode, shows a noticeably diffrent "point-of-view" .

And I must not be the only one creating very interesting and detailed "scenes" , only to realize that , in the InGame mode, at times, up to 85 % or more or that scene (you just created ) , is not even truly "visible" ( from InCab view # 1 ), and / or, the entire scene ( that you spent a day or two to build) , will basically "flash by", in ... one or two seconds .

Therefore, as far as being rational and practical, one should review their Route Editor work, very-very frequently, in the In Game mode... , before attempting to set new world records, for largest number of objects per tile ...

Important to remind ourselves that end users ( besides ourselves ), run trains in the InGame mode, and not in Route Editor ...'-)

Jean Brisson Route Building from 40 to 60 hours @ week