It's been a couple years since I've updated WFH, but there's now a new version available at DigitalRails.com for a $10 donation.
Updates in V3 include:
* Automatic removal of ViewDB's
* Ability to select alternate content locations as opposed to only the MSTS folder located in the registry
* Support for multiple placement files (e.g. one for berms, one for stations, one for power lines, etc...)
* Ability to remove all companion objects referenced in a placement file
Used in conjunction with TSRE, it's no longer necessary to use the MSTS-RE to perform a TDB rebuild after removing interactives, as the AutoFix function in TSRE will clean up TDB entries that no longer have a corresponding W file entry.
Page 1 of 1
New Version of WorldFileHacker Available
#3
Posted 26 February 2021 - 02:30 PM
They're the cross reference file that gets read to say shapefile X should get shapefile Y cloned to it.
V2 could only use a file named bermplace.txt - V3 can use any properly formatted txt file.
V2 could only use a file named bermplace.txt - V3 can use any properly formatted txt file.
#4
Posted 26 February 2021 - 10:48 PM
Can you specify an offset? Place more than one add-on .s file?
#5
Posted 27 February 2021 - 07:39 AM
Genma Saotome, on 26 February 2021 - 10:48 PM, said:
Can you specify an offset? Place more than one add-on .s file?
I've not tried a horizontal offset because the vector math to convert the X/Z values is way more than I've tried to work out (although if someone has the formula, I'm willing to give it a shot). I found it easier to simply build shapes with an offset axis, which has worked well enough up to now.
It does support a vertical offset e.g. my berms get placed 0.12 higher than the Y position for trackbj's because Scalerail sits higher.
For your road conundrum, it could support the 0.2 to overcome that built-in fudge factor. The offset is set per-object as opposed to a global.
And yes, you can do more than one add-on per source object.
For example... My station platforms are two to four objects depending on situation. The platform plus the ballast or a viaduct. Some get a crosswalk between the tracks.
That works out to two to four rows of data in the placement file, and each can support their own vertical offset as well as their own "ignore elevation" so you can have some items flat and others follow the track (e.g. line or light poles that are upright and wires with the same axis point that follow the elevation of the track/road or other associated object).
#6
Posted 27 February 2021 - 12:22 PM
What I had in mind is something I talked to Chris J. about some years back -- placing one object (a container) that carried with it a collection of other objects. I was thinking in terms of everything on a city block. It sounds like your utility can do that.
The other aspect I had in mind then was inside of OR: Use the individual .s files for LOD recognition but render all of the data at the container level. Such a device would be very useful where textures are shared across the many objects within the container -- cement for instance, roof materials, reflective glass....
The other aspect I had in mind then was inside of OR: Use the individual .s files for LOD recognition but render all of the data at the container level. Such a device would be very useful where textures are shared across the many objects within the container -- cement for instance, roof materials, reflective glass....
#7
Posted 28 February 2021 - 05:37 AM
Attached is an Excel file I use to plan and build the text for my placement files... (sorry, it's not OpenOffice or Google Docs, but those might still be able to decode the formulas safely)
It might look overwhelming but it helps break down the data elements that need to be included in the format string that WFH parses to do it's job.
In the case of your city block, you could have a benign shape define your common axis point, and then glue everything to that by including a row per component.
Decide to add/remove later? Update the row, re-run the utility.
Want to do an edit session without having buildings in the way? Run the utility to remove companions, do your work, and then re-run.
WFH-PlacementFile-Calculator.zip (711.47K)
Number of downloads: 12
It might look overwhelming but it helps break down the data elements that need to be included in the format string that WFH parses to do it's job.
In the case of your city block, you could have a benign shape define your common axis point, and then glue everything to that by including a row per component.
Decide to add/remove later? Update the row, re-run the utility.
Want to do an edit session without having buildings in the way? Run the utility to remove companions, do your work, and then re-run.
WFH-PlacementFile-Calculator.zip (711.47K)
Number of downloads: 12
Page 1 of 1