Glad it wasn't just something stupid I had done.
NYC is my 'home' area, this was the first thing I looked for on a machine that was built specifically for FS2 with an initial Steam 'stock' install. No user generated 'anything'. It's definitely 'broken', and has been for some time.
-- Rich
Didn't the GW bridge used to be there? It has been missing from my sim for a while now.
I agree. I recently built a second machine with a fresh FS2 install and, as with my other machine, the GWB directory is present but the bridge does not display. This has been a problem for some time.
-- Rich
Install Avare and the I/O plugin on an android device.
Join via wifi the same network that your FS2 machine is on.
Start FS2 and go to settings. My network is a typical 192.168.1.xxx, FS2 defaults to 192.168.1.255 as the broadcast IP and port 49002. Don't change anything (unless of course the first three numbers of the dotted quad don't agree with your network).
Enable the broadcast output. That's it.
Set a location for a flight and start it idling on the runway. You should be streaming udp packets.
Pick up your android device.
Start the avare i/o plugin. You should see the android device's IP. Set the correct listening port number 49002. Press the 'Listen' checkbox. That's it.
Watch the data flow. It's a simple JSON string {name:value, name:value}
Next step get into your development suite open a socket, setup a listener, decode the JSON string... and do something spectacular.
You might want to actually try out Avare as it is pretty great in itself.. also the price is right.. Free.
Good Luck
-- Rich
I use Avare on my my android tablet ( https://apps4av.com/ ) along with the avare external I/O plugin which is used to listen for an X-Plane or Flightgear host machine.
This works flawlessly (and for free) with FS-2. So indeed, FS-2 is spewing data out in X-plane/Flightgear format. What that schema is, I can't tell you ( I haven't tried to track it down).
-- Rich
edit:
Actually I'm looking at the data streaming into the avare x-plane connector. Looks like a JSON string with 'type', 'longitude', 'latitude', 'speed', 'bearing', 'altitude', 'time' being the parameters streamed.
Here's a link to a post I made on the subject last year. It might offer some insight.
-- Rich
Glad I could help out. Looks good. 
-- Rich
Vincent,
Here is an example that will ignore all polygons tagged natural = "bare_rock" within landuse="forest" polys.
## ----------------------------------------------------------------------------------------------------------------------
# osm
ImportOGR|C:\Users\rgord\Desktop\Test_NATURAL\test_bare_rock.osm|*|*|NOREPROJ
# clear all 'bare_rock'
SubtractFeatures|landuse="forest"|natural="bare_rock"|1
# TREES
PlacePointsInPolygon|landuse="forest"|0.0001;0.0001|1.0;1.0
# this line generates a broadleaf tree for 2% of the tree coordinates with each tree between 58 to 65 feet tall
CreateAF2Plant|FRAND < 0.02|17.67;19.812|0|broadleaf|3
# this line generates a broadleaf tree for 18% of the tree coordinates with each tree between 40 to 55 feet tall
CreateAF2Plant|FRAND >= 0.02 AND FRAND < 0.2|12.19;16.76|0|broadleaf|0
# this line generates a broadleaf tree for 75% of the tree coordinates with each tree between 32 to 45 feet tall
CreateAF2Plant|FRAND >= 0.2 AND FRAND < 0.95|9.75;13.71|0|broadleaf|2
# this line generates a broadleaf tree for 5% of the tree coordinates with each tree between 20 to 30 feet tall
CreateAF2Plant|FRAND >= 0.95|6.096;9.144|0|broadleaf|12
# Export the AF2 TOC file
ExportTOC|C:\Users\rgord\Desktop\Test_NATURAL|test_bare_rock
## ----------------------------------------------------------------------------------------------------------------------
-- Rich
In my situation Steam didn't download the new jul25 WMRforSteamVR with default.vrsettings (sans renderTargetScale), until I opted in to the WMRforSteamVR beta. I had only always been in SteamVr beta but never realized there was a beta checkbox for wmrfsvr. It seems to work much better.
I also changed WMR setting from Very high (beta), to High. There were a lot of artifacts in very high and changing got rid of almost all of the sparkling swimming edges and harsh vegetation transparency issues I was having.
I also currently have steam ss dialed back to100% and rsf at1.55 in fs2.
Performance seems better with much lower frame times and clearer image.
I'm also getting better performance with ogl vs vulcan. This is not my main rig but one just built with now blow out bargain amd 2700x and my old strix 1070.
-- Rich
The fewer layers the better I feel.
FS2 -> SteamVr -> [WMRforSteamVR] -> WMR -> your eyeballs.
I agree with you, too many moving parts.
I seem to remember it working much better in earlier iterations. I'm opted into the SVR beta and that seems to change almost daily now. It can certainly be frustrating.
-- Rich
upscaling the near stuff (cockpit) more than the far stuff
Yeah, well that's why all the effort into eye tracking and foveated rendering. Concentrating the rendering power on what you are actually looking at.
-- Rich
Dave,
I first want to say that my response was a result of initially interpreting your RSF as a juxtaposed abbreviation for renderTargetScale as mentioned by Jake a few responses earlier. "Render Scale Factor inside of Aerofly FS2" in your last post put us on the same page and clarified for me where you were going with your table post. I mistakenly thought we were going down the renderTargetScale bunny hole.
---
"I would like it if fpsVR did that but I don't think it adds up all the factors - both Steam VR Video and Application plus the in-game scale factor."
I also use fpsVR and, as you point out, really represents only about a third of the puzzle. The Microsoft 'WMR for Steam VR' plugin performs it's own scaling based on buffer size and the app rendered content that it is handed.The app in our case, FS2, gives you the ability to upscale the initial rendered output source fed to . You've got all these moving parts with slider options on both ends (SteamVR and FS2) and middleware plugin that lets you manipulate a buffer (renderTargetScale) that can, if misconfigured , 'trigger blurriness and image quality issues'. (face palm)
Wouldn't it be great if SS at both ends of the render chain could be changed in real time with a pair of sliders that you could fiddle with simultaneously as you balance visual quality vs hosing performance. It would be like turning the tuning knob and fiddling with the rabbit ears on an old analog TV. LOL
---
-- Rich
I feel compelled to jump in here regarding renderTargetScale 's role in the 'WMR for Steam VR' configuration file.
-----
Rather than paraphrase.
Dan Conti, Microsoft dev, posted in the 'WMR for Steam VR' forum:
"Short description is it ( renderTargetScale ) controls the size of the buffers we hand to SteamVR for app rendered content. If you set too small a value then the buffers will be smaller than the what the content was originally rendered at and you get downscaling. If you downscale too much, then we later have to upscale to match the resolution of the displays, and you will see blurriness and image quality issues. If it's set too high, you end up with a much larger buffer than is needed.
There is a point on SS where you'll need to increase renderTargetScale, or you will trigger a downscale. If you try 2.5 or 3.0 you should see the drop-off go away. This is assuming you aren't hitting performance issues.
In terms of tuning, what you are looking for is the point of diminishing return on upping SS. At some point any value of doing a higher quality initial render either isn't noticeable or impacts your ability to maintain framerate."
------
He also made the point that renderTargetScale has a maximum value of 5 and the current default value for All wmr headsets is 2.0. That's your minimum.
It would also be helpful to not use percentages for SS. I've noticed in the past (especially in the beta version of steam vr) that 100% equated to different pixel counts with different version releases. Currently Steam vr beta renders 1660x2076 per eye for my Ody+. With hardware native being 1440x1600, that is already a 115% super sample.
The slider at 200% shows me 2348x2936 per eye, a 1.63 ss ratio.
The steam vr 100% base rendering resolution is an arbitrary figure based on their expected baseline 'performance' of the headset, not the native hardware resolution.
-- Rich
Because I find that IPacs managers, do nothing to help on this point.
While with the tool FSx AIrport Design Editor we made tracks with taxiways and other objects gas station, parking etc .. a super easy tool to take in hand.
Without a similar tool and the same level I give up any realization of scenes under AFS2. For me the limits of what I can accept are crossed.
In a particularly generous post Antoine attempted to gently point out to you that Micosoft never lifted a finger to create any of the tools you mention. They were all produced by third party enthusiasts spanning multiple generations of simulator and decades.
-- Rich
Turman,
As a sanity check I decided o give the file a try. I downloaded the DEM and did a gdalwarp reprojection from Lambert-93 to WGS84 before loading into QGIS.
I exported as a rendered GEOTIFF and processed as I would any other mesh.
Looks like a similar result.
<[file][][]
<[tmcolormap_regions][][]
<[string] [folder_source_files][./input_aerial_images/]>
<[bool] [write_images_with_mask][false]>
<[bool] [write_ttc_files][false]>
<[bool] [do_heightmaps][true]>
<[string8][folder_destination_ttc][X:\Mesh\target\]>
<[string8][folder_destination_heightmaps][X:\Mesh\target\]>
<[bool] [always_overwrite][true]>
<[list][region_list][]
<[tmheightmap_region][element][0]
<[uint32] [level] [7]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
<[tmheightmap_region][element][0]
<[uint32] [level] [8]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
<[tmheightmap_region][element][0]
<[uint32] [level] [9]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
<[tmheightmap_region][element][0]
<[uint32] [level] [10]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
<[tmheightmap_region][element][0]
<[uint32] [level] [11]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
<[tmheightmap_region][element][0]
<[uint32] [level] [12]>
<[vector2_float64] [lonlat_min] [6.743398876 44.365688310]>
<[vector2_float64] [lonlat_max] [7.467851776 43.630469982]>
<[bool] [write_images_with_mask][false]>
>
>
>
>0.0000503057
0
0
-0.0000503057
6.743398876
44.365688310BTW pixel coefficients will be identical if you are dealing with square pixels.
Well I don't know what the problem is. But it sure does look like there is a wacky coefficient being applied to the vertical component of the data.
-- Rich
Antoine,
I am super impressed with the effort you made to integrate and consolidate information and tools regarding the mechanics of AFS2's world and geoconversion. Outstanding work. Thank you so much for this reference document.
-- Rich
Here's a working snippet from one of my scripts:
--
# this line generates a broadleaf tree for 2% of the tree coordinates with each tree between 58 to 65 feet tall
CreateAF2Plant|FRAND < 0.02|17.67;19.812|0|broadleaf|3
# this line generates a broadleaf tree for 18% of the tree coordinates with each tree between 40 to 55 feet tall
CreateAF2Plant|FRAND >= 0.02 AND FRAND < 0.2|12.19;16.76|0|broadleaf|0
# this line generates a broadleaf tree for 75% of the tree coordinates with each tree between 32 to 45 feet tall
CreateAF2Plant|FRAND >= 0.2 AND FRAND < 0.95|9.75;13.71|0|broadleaf|2
# this line generates a broadleaf tree for 5% of the tree coordinates with each tree between 20 to 30 feet tall
CreateAF2Plant|FRAND >= 0.95|6.096;9.144|0|broadleaf|12
--
The last value 'broadleaf|2', 'broadleaf|12' will evaluate to 'T02' and 'T12'.
-- Rich
<[string8][filename][Brest_4.582,48.361_-4.346,48.45]>
<[string8][filename][brest]>
You're defining the tsc filename not your toc file name ('brest')
-- Rich
That sound pack by blackmouse is only for the toy planes, isnt it? I am waiting for something for the bigger ones aka Boeing and Airbus.
http://skysongsoundworks.com/product_info.php?products_id=198
773 not working
814, 816, 820
These are a moving target. They disappear and increment.
-- Rich
