Hi Nick
There seems to be an issue in the incremental download scenario
If I download and convert one "Level 13- Small" tile, and when that completes, select a second tile to download and convert , the first tile will be downloaded again along with the second.
If I reset the selection to "Level 9 - Large" and back to "Level 13- Small" and select my second tile only the new tile will be downloaded.
Looks like stale context somewhere from the prior run.
/Stu
I also used 0.1x0.1 degree tiles for cultivation.
This was primarily for tree cultivation in the Alps.
I used a combination of OSM data and tree detection filter depending on the character of the tile area.
Tree detection gives a much more realistic distribution for sparse vegetation at higher altitudes, but yields a lot of false positives for mixed agriculture areas.
For the valley floor I switched to OSM.
This tile size made for easier to cultivate tiled strips along major valleys and for cultivation verification and regeneration if there is a problem.
I created a utility app and some batch files to make it pretty much "enter tile center coords and press go"
Stu
Unfortunately too late to change it as everyone's folder names would be wrong.
Hi Nick
I think it is a little early in the beta process to be locked into legacy.
For the long term ease of use, intuitive name conventions are worth their weight in gold.
After building software for 20 years I can't count the number of times we said "I wish we had cleaned that up before it got cast in stone"
Stu
PS AeroScenery looks very promising so far.
As of the last update TSC files can be decoupled from an airport definition
See Antoine's (Trespassers) entry in this thread
Stu
I agree with sentiments above.
The VR hands provide a significant part of the immersion.
However being limited to a controller in one hand and stick (or yoke) in the other breaks the immersion.
I would be willing to give up on the haptic feedback from the controller in exchange for bare hand tracking as with LEAP
If glove technology improves to provide a good compromise, all the better.
if ever to be honest
It is discouraging to hear that VR hand extensions or control alternatives are potentially a closed topic.
Stu
Sometimes reloading the aircraft or restarting the simulator can fix these kinds of issues.
Has the shadow been ok prior to the changes you made to the tmd file?
If you made a mistake whilst editing the tmd file it's not really our fault...
Reboot and restart and the same problem appears.
Not a tmd issue since it renders fine in OpenGL
Switch over to Vulkan and weird shadows appear, back to OpenGl and it is fine!
Stu
Update
Problem occurs in low and medium Shadow quality
High, ultra and insane are OK
I was configuring for the ASG29 which only has CameraPilot so I did not realize you could specify alternate cameras for ShowInside.
Learn something every day (if you are lucky)!!
Stu
PS
ghost shadows with Vulkan?
I have noticed other shadow rendering oddities.
Strange shadow rendering with Vulkan (with or w/o AA)
All change position with pilot head position
Appears in 2d and Rift
GTX 1080TI with 398.36 driver
nothing unusual in tm.log
In addition to a package based scenery organization as Antoine suggests it would also be useful to have an easy way to disable packages,
A folder name convention hook such as
!package
___elevation
___ images
___...
or
#package
___elevation
___images
___...
would not be loaded.
package
___elevation
___images
___...
would be loaded.
That would make it easier to quickly enable/disable packages rather than moving them to an out of the path location.
The ShowInside property only seems to affect the PilotCamera view.
Other views will still show the pilot.
/Stu
In the xxx.tmd
<[graphics_human][Pilot][]
<[string8][GeometryList][ PilotBody ]>
<[uint32][PositionID][Fuselage.R]>
<[uint32][OrientationID][Fuselage.Q]>
<[uint32][ShowInside][0]>
the ShowInside value of zero hides the pilot. Blank value show the pilot.
Cut and paste glitch on the link. Fixed now.
Pilot error. Read flight manual BEFORE starting engines.
See my original post for an example of a flight path record.
I used the free (and great) Eclipse development environment to build a small Java app.
The core of the app is
Open a DatagramSocket for port 49002 on localHost
Reading the socket yields alternating lines of the form
XATTAerofly FS 2,170.9,-17.02,3.62
XGPSAerofly FS 2,11.6079,46.7867,1312.0,170.7,35.0
The XPGS tokens are longitude,latitude,altitude,?,?
Write the KML header to a file.
Parse the XGPS events and write the coordinate values to the KML file
Write the tail of the KML file when you stop recording.
Load the KML into Google Earth
<?xml version="1.0" encoding="utf-8" ?>
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document id="root_doc">
<Folder><name>flight_path</name>
<Placemark>
<Style><LineStyle><color>ff0000ff</color><width>4</width></LineStyle></Style>
<LineString>
<altitudeMode>absolute</altitudeMode>
<extrude>0</extrude>
<coordinates>
11.511824999999998,46.868275,1324.2749999999999
11.511849999999999,46.868199999999995,1323.8249999999998
...
...
...
</coordinates>
</LineString>
</Placemark>
</Folder>
</Document>
</kml>
Most of the code was for handling exception conditions for stopping and restarting recording.
Getting the curtain effect required a lot more fiddling to generate two line strings in the KML.
I have experimented with the yaw, pitch and roll data in the XATT event but KML is a rather blunt tool for complex graphics.
And I have yet to wrap my head around the transforms required to locate the wingtips in lat,long and altitude space starting with lat,long and altitude of the CG and yaw,pitch and roll data.
cheers
/Stu
Hm yes, a better mesh (without spikes and other anomalies) would be nice. Does anybody have a free source to build it for Europe? I will be interested.
There is also some good 1" mesh data for the Alps here http://viewfinderpanoramas.org/dem3.html
/Stu
if you are interested in seeing what I have so far contact me directly. Email is in my profile.
/Stu
I wrote a small recorder app that formatted the broadcast positions into KML for display in Google Earth.
I found a fair bit of jitter in the positional data. I ended up doing a 8 point rolling average to get a smooth flight path.
Now I was interested in glider fight path not snap rolls so sample rate was not an issue.
cheers
Stu
Big thanks to querty42 for the tutorial. Particularly the part on .tfw (which does seem redundant)
With new knowledge in hand and armed with some open source 1" height maps for the Alps I was able to turn this moto-cross course
into this
A great improvement!!
There were some NotANumber pixels in the data that turned into space elevators when geoConverted, but QGIS has a Raster menu function that interpolates over those pixels and that fixed the problem.
cheers
/Stu
In the software business you can can either have product done quickly or you can have product done correctly. Choose one.
I choose the second.
IPACS favors the second approach as well.
Stu
There are a couple of applications that will currently allow for this using our provided feature.
I was aware of the moving map / sectional tracking through apps like FSWidgets.
What I missed was the 3d rendering of a soaring flight as viewed in Google Earth via IGC Flight Replay.
/Stu
One of the add-ons I used with FSX was the IGC Flight Replay. Through various machinations you could get a FSX flight log into IGC format.
While the application provided analysis of soaring performance the part I used the most was the ability to view your flight in Google Earth.
Unfortunately due to a deprecation of the Google Earth API the application ceased to be functional several years ago.
As an experiment I started looking to see how much of the IGC Flight Replay display functionality could be
replicated though just KML.
I created a small Java app that captures Aerofly FS 2 broadcast data and formats it as a KML linestring.
The resulting display is not too far off the basic flight path display functionality of IGC Flight Replay.
The screen capture shows a short soaring flight at LOWI
cheers
Stu
