geolpilot

Hi Dave Using 2.0.1.5 with P3DV3.3. If an airport is not in the Sim database (wxstationlist.bin I assume?) then if ever Pilot2atc needs weather info, an unhandled exception error like below is generated. ************** Exception Text ************** FSUIPC.FSUIPCException: FSUIPC Error #11: FSUIPC_ERR_TIMEOUT. Weather station FASZ is currently unavailable or is invalid. at FSUIPC.WeatherServices.GetWeatherAtLocation(FsWeatherHeader header) at FSUIPC.WeatherServices.GetWeatherAtLocation(String ICAO) at P2AWeather.SIMWeather.GetSimWeather(String ICAOCode) at P2AWeather.XPWeather.GetWeather(String ICAO) at P2A_Controls.ucMapInfo.DisplayWeather(Airport tApt) at Pilot2ATC_200.ucMap.a() at Pilot2ATC_200.ucMap.c(Object A_0, EventArgs A_1) at System.Windows.Forms.Control.OnClick(EventArgs e) at System.Windows.Forms.Button.OnClick(EventArgs e) at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ButtonBase.WndProc(Message& m) at System.Windows.Forms.Button.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam) The above error was generated when preparing the flightplan, with weather set in config to use sim weather, and clicking the weather button for FASZ (not a metar reporting field). If I reload Pilot2Atc, and use the inbuilt NOAA weather, I can click on weather for FASZ, and it just says "No Weather" (no exception error thrown). Other times have had this in flight, as whenever Pilot2atc needs weather info (like determining RW for approach / landing, or asking for altimeter setting), and flying into a non-METAR reporting field, I get the same crash (only if using Sim weather, default Pilot2atc weather works fine). Pilot2atc carries on running if I click continue on the error screen, but speech engine is dead, and I cannot seem to get any responses using "Sayit" either. So both times I have flown into such fields, that has been the end of using Pilot2atc. Can you trap for this exception please, so Sim weather behaves just as the Pilot2atc default weather does? I realise right now it is probably too much work to read the weather files that add-ons like AS16 generate with interpolated weather at non-reporting stations (so many addons, so many formats!), but this may ultimately be the only way to handle sim weather completely. Thank for the many improvements you continue to make so regularly. Pilot2atc is really shaping up nicely now. Regards Rob

I have noticed on a few occasions that Pilot2ATC is reporting an active Runway (at either departure or destination, sometimes both) that is not correct given the METAR for the airports in question (both NOAA in Pilot2ATC and ASN's weather). Provided one has set the ATC determines SID, STAR and APPROACH config. options off, one can, in some cases overide this. In certain instances one cannot (see later), and this also means that leaving the STAR and APPROACH selection up to ATC leads to problems - being assigned an approach that is downwind for a tailwind landing that in some cases may be minor tailwind that one can accept, at other times is dangerous. In both cases this leaves one coming headon at approcah into AI traffic. One case I have experienced where one cannot overide the runway selection, even on departure, is FALA (Lanseria International, South Africa). The navigational database (both the one PIlot2ATC is using and the Navigraph data I have of the same date that I am using till Navigraph supports Pilot2ATC), only has an approach for RW07 (no STAR). Confirmed also on the approach chart for FALA. RW 25 appears to be a purely visual take-off and landing runway. So it seems that, since there are no SIDs at FALA, and RW25 has no defined approach RW25 is, to all intents and purposes, invisible to Pilot2ATC. No problem on departure, as I have found that even after being told to expect taxi to RW07 (with westerly winds), if I ask for taxi to RW25 I am given that, and after contacting tower I am cleared for take-off RW25. But coming in to land is another matter. I cannot manually select RW25, and on those flights where I have left approach and RW selection up to ATC, I only get the RNAV into RW07, despite westerly winds. I suspect in the real world, RW25 would be a visual approach if not IMC (straight in, or pattern entry), or one can use the LIV VOR (positioned at the end of RW25) for an instrument approach, but with higher mimimums. Else divert. But none of these options are available in Pilot2ATC. Another example is FVBU (Joshua Nkomo, Bulawayo, Zimbabwe). RW 13 has defined approachws (ILS, LOC and VOR). RW 31 has none, so with winds from the NW one is stuck (cannot manually select RW31, or allow ATC to select, as it will take the only RW it knows of, RW13). Maybe in more developed parts of the world one does not encounter this problem. Sorry for the "Darkest Africa" examples, but I think many simmers fly these regions, and it would help to cater for these situations. Would it not be possible to allow an overide of RW selection to handle such cases. So when one opens the APPR window, and selects a RW other than what Pilot2ATC has determined as the active, that user-selected RW actually gets selected (at the moment it does but only if the NAV database has a defined approach for it). If Pilot2ATC cannot find an approach in the database for the selected RW, the "Approaches" dropdown gets populated with four selectable, fallback options; "Straight in Approach" "VFR Pattern Approach", "Non Procedural VOR Approach", or "Overhead Approach", the latter catering for NDB overhead and procedure turns. That way one should have full control over the approach selection to handle all wind scenarios. Another case where this will be useful is at smaller airports and fields that do not report METAR, so that NOAA and Pilot2ATC simply have no weather information. Programs like ASN/AS16 interpolate weather at such fields, so the simmer has weather info available on which to make a suitable RW selection. In "No Weather" available situations, Pilot2ATC simply seems to select the SIM "default" RW if there are no defined SIDs or Approaches for the into-wind runway, so that one is presently stuck with the default RW selected. Rob

Yeh - my co-pilot was complaining he could not see FTX-AU today, between Melbourne and Sydney! First time I have ever seen solid cloud deck in years of simming! AS16+ACSA - Full Dynamic (clouds to 100Nm). P3D V3.3.5, iFly NGX. Climing through 32000 for 35000. Frames at 30-32 (locked at 33). I feel Hi-Fi have definitely improved performance. I do not have the best graphics card either, so I do not use SGSS, this is just 4X MSAA. Earlier over Pattaya in the PMDG 777, out of Bangkok headed for Changi (Discovery Theme). So solid overcast, for me is at last a feasible reality. Thank you HiFi Rob

The Avatar is really a lot of fun, especially when flying choppers. Been visiting some of my old mountain haunts, and then taking the avatar for a hike along some trails and climbs I have been on - makes me quite homesick and also a bit sad that age has caught up with me and I cannot ever do those trails again for real. Yes it is always a long "run" back to get close enough to the chopper to be able to get back in, and fly home! A sort cut key to get back quickly would be great. Guess many will only have been exploring around airports so will not have tried this.... Walk or run the Avatar into the sea / lake / major river. Beside the initial shock of the "big splash" sound, a nice surprise awaits anyone trying this! Will not spoil the fun by saying what happens next - give it a try! Very capable fellow that Mr Avatar. Rob

Dave I have it installed in V3.1 and can confirm it works fine (I use the BM mainly, so cannot comment on the tow and cable launcher). I manually installed mine from FSX into V2.4 way back, and have carried it forward into V3.0 and 3.1. If you have it installed in FSX or another P3D version its relatively easy, since the gauges are self-contained in the aircraft (Aerosoft_DiscusB, BT and BM) subfolders. Wish all would do this rather than have gauges all over the show. Simply copy the /simobjects/airplanes/Aerosoft_DiscusB, Aerosoft_DiscusBM and Aerosoft_DiscusBT folders from FSX into the standard P3dV3.1 airplanes folder, or into an external airplanes folder if you have one set up and configured outside the P3D core. In your FSX install look into the "Modules" folder. There should be a "b21_vario" folder. Copy that to the P3D3.1 "Modules" folder. Open c:\users\yourname\appdata\roaming\Lockheed Martin\\Prepar3D V3\dll.xml in notepad and add these lines <Launch.Addon> <Name>b21 vario sound control</Name> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Path>Modules\b21_vario\b21_vario.dll</Path> <DllStartName>module_init</DllStartName> <DllStopName>module_deinit</DllStopName> </Launch.Addon> Then the only really tricky bit is to set the sound files path up properly. In each variant's folder under simobjects\airplanes there is a "panel" subfolder. Open this folder and look for the file asc.cfg ; open that with notepad. The second line of this file under [GENERAL] starts with wavdir= "somedirectory" The "somedirectory" this points to must be where you have installed the aircraft eg D:\Prepar3D V3\SimObjects\Airplanes\Aerosoft_DiscusBM\sound\Aerosoft_Sound_System_Discus (for the asc.cfg in the Aerosoft_DiscusBM\panel folder) and D:\Prepar3D V3\SimObjects\Airplanes\Aerosoft_DiscusBT\sound\Aerosoft_Sound_System_Discus (for the asc.cfg in the Aerosoft_DiscusBT\panel folder etc And you are set to go. You can copy the Aerosoft directory in the root of your FSX installation to the P3DV3.1 root; that just has the manuals in it, and does not affect the operation of the aircraft. If you don't have it in FSX, hope you still have FSX installed then can install it there first and do the above. Otherwise may have to use EMT tool. Rob

To quote from LM's site re: the Scenery Update; "Prepard3D Scenery General Updates Minimal accuracy changes for five south-eastern United States of America airports Updated coastlines, lakes, rivers and elevation model in Singapore" So unless you do a lot of flying in/out of/ around Singapore, or in the Southeastern USA (around five mystery airports) then no, I would say installing the scenery module is not worth the "grief". I personally would like the updates to Singapore, but I do not consider that alone worth the grief of re-installing all my ORBX stuff, which I am sure will get overwritten by all the default scenery items again. Which brings me to this; I cannot for the life of me understand why the whole simulator scenery package (the size of those downloads exceeds all else!) has to be supplied just to update the above small areas (well I can understand that for first-time purchasers, they need the whole scenery pack). But since these changes will involve replacing a few cvx tiles , AFCAD and DEM .bgls, surely a small, separate scenery update installer and .cab file/s for existing users would do the trick, and avoid replacing all the other scenery files for established users (i.e. those files that are not updates, and are unchanged from the previous version, so if installed again simply set all scenery back to the default state). Would also save a load on LM's servers! Just my 2c on this. Rob

Yes, if using REX4 Texture Direct to inject a water animation, it creates a WaterConstants.xml file in the same directory as your Prepar3D config file. V3.1 has, as you point out, a new WaterConstantV3.xml file. After injecting a water animation from REX4TD, I simply delete the WaterConstants.xml file REX creates, and then go fly. Have tried out several different REX animations so far and all is fine, so not sure why you had to reinstall the content again. I see water motion at 25000 feet, highest I have tested so far. Also all waves move with the wind, so the wind/wave direction problem has been fixed. Must say this was the easiest sim update ever for me. All my settings, add-ons etc. stayed intact. Admittedly I did not install the scenery module, only client and content. The scenery can wait. Considering it is the Christmas week, and all are getting into the holiday "gees" (South African for "spirit"), I personally think the 3rd party add-on developers have done a great job in updating all their stuff to work in V3.1 so quickly (within a day!). So to LM, HiFi Simulations and FSDT, a big thank you from me! Rob

The <fWindOffset> values you highlight are supposed to change the angle of the waves to the wind direction. Try as I might, I have never got those values to do anything (the values look like they are radians), but last time I tried was in 2.4. For example I tried to use those to get the waves to go 180 degrees opposite to the wind direction, in an attempt to fix the problem of the waves moving into the wind - no go. Its the <fWindScalar> values that get the waves moving at different speeds and the <fWindScalar4> is the one that really gets the prominent water texture moving. Rob

@Christopher and other having this problem I spent some time over the weekend investigating this, and would have liked to make a video, but just did not get around to it. So here is what I think is the problem, and has not been mentioned in this thread. It also clear a bit about why some say REX4TD works, but REX3 does not. Have a look in your Users/username/AppData/Roaming/Lockheed Martin/Prepar3D folder for a file WaterConstants.xml (make a backup if you are going to try my suggestions) Note that if you have injected water textures and animation with REX 4 Texture Direct, you will see a WaterConstants.xml and a WaterConstants.xml.org file. REX4TD overwrites the original LM version, and saves the LM version in the .org copy, so to see what LM did in the original, you need to look at the .org version OK lets look at LM's original WaterConstants.xml (or .org if you have used REX4TD) <?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="WaterConstantFile" version="1,0" id="WaterConstants"> <Descr>AceXML Document</Descr> <Filename>WaterConstants.xml</Filename> <WaterConsts.ConstantSet> <ShaderP3D> <fSpecularPower>124.0000</fSpecularPower> <fSpecularBlend>0.2750</fSpecularBlend> <fSpecularBoost>1.0125</fSpecularBoost> <fWhiteCapPower>1.0000</fWhiteCapPower> <fTextureScale0>128.0000</fTextureScale0> <fTextureScale1>48.0000</fTextureScale1> <fTextureScale2>16.0000</fTextureScale2> <fTextureScale3>5.0000</fTextureScale3> <fTextureScale4>1.0000</fTextureScale4> <fWaveDistance0>250.0000</fWaveDistance0> <fWaveDistance1>1100.0000</fWaveDistance1> <fWaveDistance2>4000.0000</fWaveDistance2> <fWaveDistance3>16000.0000</fWaveDistance3> <fWaveDistance4>24000.0000</fWaveDistance4> <fWindOffset0>0.0489</fWindOffset0> <fWindOffset1>0.0489</fWindOffset1> <fWindOffset2>0.0489</fWindOffset2> <fWindOffset3>0.0489</fWindOffset3> <fWindOffset4>0.0489</fWindOffset4> <fWindScalar0>-0.1000</fWindScalar0> <fWindScalar1>0.7500</fWindScalar1> <fWindScalar2>0.2500</fWindScalar2> <fWindScalar3>0.3250</fWindScalar3> <fWindScalar4>0.3750</fWindScalar4> </ShaderP3D> <Wave> </Wave> </WaterConsts.ConstantSet> </SimBase.Document> The <fWindsScalar4>0.3750</fWindScalar4> is the problem in a default installation. This value controls the speed of scrolling of the dominant wave texture and the one seen from greater heights. The default value is far too small, an​d results in a completely static pattern seen from higher altitudes - as Christopher describes like waves on a mudflat when the tide goes out. Even if you use REX 3 Essential to inject a new pattern, it is frozen, because REX3 does not modify the default WaterConstants.xml file! Now REX has recognized this problem, so if you inject a texture and wave animation with REX4TD (REX3 is due for a SP4 fairly soon that may do something similar to REX4), you will see this file modified to look like this; <?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="WaterConstantFile" version="3,0"> <Descr>AceXML Document</Descr> <WaterConsts.ConstantSet> <ShaderP3D> <fSpecularPower>124.0000</fSpecularPower> <fSpecularBlend>0.2750</fSpecularBlend> <fSpecularBoost>1.0125</fSpecularBoost> <fWhiteCapPower>1.0000</fWhiteCapPower> <fTextureScale0>128.0000</fTextureScale0> <fTextureScale1>48.0000</fTextureScale1> <fTextureScale2>16.0000</fTextureScale2> <fTextureScale3>5.0000</fTextureScale3> <fTextureScale4>1.0000</fTextureScale4> <fWaveDistance0>250.0000</fWaveDistance0> <fWaveDistance1>1100.0000</fWaveDistance1> <fWaveDistance2>4000.0000</fWaveDistance2> <fWaveDistance3>16000.0000</fWaveDistance3> <fWaveDistance4>120000.0000</fWaveDistance4> <fWindOffset0>0.0000</fWindOffset0> <fWindOffset1>0.0000</fWindOffset1> <fWindOffset2>0.0000</fWindOffset2> <fWindOffset3>0.0000</fWindOffset3> <fWindOffset4>0.0000</fWindOffset4> <fWindScalar0>-0.1000</fWindScalar0> <fWindScalar1>-2.7500</fWindScalar1> <fWindScalar2>-1.2500</fWindScalar2> <fWindScalar3>3.3250</fWindScalar3> <fWindScalar4>3.3750</fWindScalar4> </ShaderP3D> <Wave> </Wave> </WaterConsts.ConstantSet> </SimBase.Document> Note that REX4TD changes the <fWindScalar4> value to 3.3750, 10X more than the default (as they do for the other values as well). They also change the <fWaveDistance> values, in the case of no-4 to a value in lower earth orbit, which I think is a bit needless. Does this work? Well yes, but you still have to look very carefully in slew to see that wave texture moving, and it does - at a snails pace! But users of REX4TD are probably happier that users of the default, who only see movement in the sun-reflection area. So I have experimented more, and based on the theory that these bigger ocean waves (longest wavelength) in reality do move at rather high speeds, I have a MOD for the WaterContants.XML file that looks like this; <?xml version="1.0" encoding="UTF-8"?> <SimBase.Document Type="WaterConstantFile" version="3,0"> <Descr>AceXML Document</Descr> <WaterConsts.ConstantSet> <ShaderP3D> <fSpecularPower>124.0000</fSpecularPower> <fSpecularBlend>0.2750</fSpecularBlend> <fSpecularBoost>1.0125</fSpecularBoost> <fWhiteCapPower>1.0000</fWhiteCapPower> <fTextureScale0>128.0000</fTextureScale0> <fTextureScale1>48.0000</fTextureScale1> <fTextureScale2>16.0000</fTextureScale2> <fTextureScale3>5.0000</fTextureScale3> <fTextureScale4>1.0000</fTextureScale4> <fWaveDistance0>250.0000</fWaveDistance0> <fWaveDistance1>1100.0000</fWaveDistance1> <fWaveDistance2>5000.0000</fWaveDistance2> <fWaveDistance3>10000.0000</fWaveDistance3> <fWaveDistance4>40000.0000</fWaveDistance4> <fWindOffset0>0.0000</fWindOffset0> <fWindOffset1>0.0000</fWindOffset1> <fWindOffset2>0.0000</fWindOffset2> <fWindOffset3>0.0000</fWindOffset3> <fWindOffset4>0.0000</fWindOffset4> <fWindScalar0>0.1000</fWindScalar0> <fWindScalar1>2.7500</fWindScalar1> <fWindScalar2>1.2500</fWindScalar2> <fWindScalar3>3.3250</fWindScalar3> <fWindScalar4>5.5000</fWindScalar4> </ShaderP3D> <Wave> </Wave> </WaterConsts.ConstantSet> </SimBase.Document> I up the <fWindScalar4> value to 5.500, can even can try values as high as 6.3. I also change the <fWaveDistance> 1 to 4 values to a set that experimentally gives me what I like, but you can play with these. Now I get action. No matter what texture I inject from REX4 or REX 3 it moves obviously against reference objects (coast, ships, and in slew a static plane has obvious relative motion against the texture background). Obviously when injecting with REX4TD, it now copies my modified .xml to .org, so I have to keep restoring the .org file as the .xml file. with REX3 I just inject and go. Some notes; When making changes to WaterConstants.xml, delete the shader files in Users/yourname/AppData/Local/Lockheed Martin/Prepar3D V3/Shaders and let Prepar3D rebuild them on the next run. The texture can only be made to scroll N to S or S to N (+5.500 for <fWindScalar4> is a N-S scroll, a -ve 5.500 will give S-N scrolling). This is fixed, and the wind-direction and speed have no effect on this. Kind of like big ocean swells may not be affected by local wind, but I still wish more directions could be used, or there was some modification of the wave-direction against a coastline. That would also give more "sense" of movement. Your small inland rivers, dams and ponds will have the same fast-moving mega-waves. A bit off-putting. The fully animated, smaller waves are affected by wind, but in the wrong direction (a wind from the north will make the waves move towards the north, etc), and LM have noted this, found the problem, and say it will be fixed in 3.1. Still looking forward to see what improvements are made in 3.1. If major changes are made, the WaterConstants.xml file may go out the window. If not, keep a backup of any mods you make that work for you, in case they release the same old version and it goes back to being a static show. Let us see. So Christopher, please try my mods and see if that works for you! Rob

This from http://www.freemars.org/jeff/planets/Luna/Luna.htm "The Sun happens to be 400 times the Moon's diameter, and 400 times as far away. That coincidence means the Sun and Moon appear to be the same size when viewed from Earth. A total solar eclipse, in which the Moon is between the Earth and Sun, blocks the bright light from the Sun's photosphere, allowing us to see the faint glow from the corona, the Sun's outer atmosphere." The defaults settings in Prepar3dV3 suneffect.cfg are (the one in the programdata folder must be changed); [general] SunSize=900 MoonSize= 2072 This is patently incorrect, hence the very small sun (43% of moon size)! just changing sunsize to equal moonsize [general] SunSize= 2072 MoonSize= 2072 and the sun will be as in the image below - much better! This assumes the moon size is correct of course. If you think moon is too small just up that a bit, and adjust sun to same. Don't know how the value of 2072 for MoonSize is calculated; if we knew we could use the exact arcsecond sizes of sun/moon as seen from earth to compute the real value! sun max 31.6 minutes = 1896 seconds of arc 0.5267 degrees moon max 33.5 minutes = 2010 seconds of arc 0.5583 degrees So sunsize is really 0.9433 of moon size Thats when both closest to earth. Doubt P3D simulates elliptical orbits of either. The "real" 2010 seconds of arc for moon size is in same ballpark as the MoonSize=2072 P3D value. Maybe these are arc second values? So one could also try [general] SunSize= 1896 MoonSize= 2010 and see if these look "real" With sunsize at either 2072 or 1896 sun will be double the defualt size so maybe GSALDEN will have to reach for his polaroids when flyiing towards a setting sun in that great cockpit of his! Rob

Have been using both FSx and P3d 2.4 on same machine for a while now - no problems, but as Rob says be careful what you are updating and to where. I was only keeping FSX going for PMDG planes, but now that they are arriving for P3D, am getting to the point of ditching FSX, only because keeping addons updated for both systems is becoming a real time consuming task (pain) these days (ASN x 2, PMDG 777 x 2, iFly 737 x 2, GSX x 2, MCE x 2, DX10 Fixer for FSX, EFB x 2, Navigraph FMS data x 2, and the list goes on!). Got to move on with one system now. Rob

I have done a lot of testing on VAS loading using a LUA script to record and monitor VAS loads as I fly towards a large payware airport, or overfly complex scenery addons, even high altitudes. My testing showed me that within 60nm of an airport (even default) a hit on VAS occurs, even if overflying at 35000 feet (or any cruise alt). As one gets to within 20nm of an airport, VAS drops signficantly in proportion to the detail modelled / user-selected detail turned on at that airport. So my rule is to turn off all unused "heavy" airports within 60nm of my flight path, except for the departure and destination airports, if using a detailed aircraft simulation (eg.PMDG model). If flying into a heavy metro area, where you may have both detailed city scenery and several closely sited payware airports, this is crucial. For example if I fly into FAOR (Johannesburg, NMG payware), I must turn off FALA (Lanseria, NMG payware) if approaching from the north, as on approach I will be within 20nm of both airports, and incurr an extra hit on VAS as FALA loads, even though I am not using it or even wanting to see it in any detail. Rob

Much confusion here! With Rex Essential SP3 installed you will still need to modify the WaterConstants.xml file yourself (the one in the Appdata/Roaming/Lockheed Martin/ Prepar3D V2 folder where your .cfg file is, NOT the one in the root folder of P3D). I too only had Rex ESS + OD SP3 installed when I posted my trial mods to this file in this thread. I also have Rex Texture Direct, and the latest service pack for TD fixes the animations automatically for you by modifying the WaterConstants.xml file when you install the update. You need do no more, except modify the file if you want to change the height at which various scales come in of the water texture (is same texture sheet used eg "sparkling" or "cinematic", just at different scales), or if you want to change the speed of scrolling motion for the larger-scales of the water texture. Two things I want to stress, because I think people have some unrealistic expectations here; The animations you see at low altitudes ARE NOT visible from high altitudes (above around 2000ft) unless you look straight down below the plane, and even then, as one goes higher they are only seen if looking at where the sun reflects off the water, or straight down below the plane, and then you will only see the reflections "dancing", not the full motion of the detailed, tessellated water surface. The distance factors in the .xml also affect distance looking out diagonally from plane to water surface. So in spot view at say 2000ft, in the foreground you see the advanced animations, in the distance the only animation is the scrolling of wave / swell patterns embedded in the larger-scaled texture sheets. Stronger the wind the easier it is to see this water surface animation, as the surface topography grows in amplitude. Prior to modification of the .xml file (either by yourself or by Rex TD SP4), what was broken was the scrolling of waves in the distance / at higher alts, so the scene looked like a painted, static blue sheet. The fix is that these now scroll, so you will see the swells and larger wave crests and troughs move. With the REX fix in the XML, scrolling is still slow, and you will not see this while flying very easily. If stationary in SLEW you should see this movement if you watch carefully against some shoreline marker, and if you look at your plane in outside view against the water background, you should see an apparent drift of the plane. This is texture scrolling animation. Again YOU will NOT SEE the heaving, moving waves of the tesselated water surface (water surface animation) from higher alts or in the distance, though it is still there, but can only be seen in reflections, and very close / directly below the plane. We can debate how realistic this is, my feeling is that it is perfectly realistic as you would need mountainous, tessellated water topography to see this from high altitudes (tsunami, "Perfect Storm" waves sizes constantly??). Next time you are at say 5000ft look at how large/ high a 3-story static-scenery, add-on airport building looks (not autogen so much, they appear oversized in P3D ). How often have you seen 3-story high waves (surfers paradise!). For that matter how often have you seen waves 6ft high, and how easy it is to spot a person from 5000ft (no shadow, and waves only cast shadows at very low sun angles!)? Remember also that waves at sea are lower amplitude than when they approach the coast, where they grow in amplitude as water-particle motion changes from circular to an exaggerated ellipse as the motion is slowed by sea-floor topography. At sea, in mild to moderate weather its things like wind-spay, foam patches and streaks moving on the surface, white caps, and changing hues and reflections due to water movement that expose the movement and waves, not so much their height. In strormy weather the previous effects as well as the wave height are obviously both increased, and more obvious (but from 30000 feet you'd still have to look rather carefully to see individual waves down there, and spot their motion!) The slow movement (scrolling) of waves and swells in the distance? Well I have speeded mine up, but even then, while flying one does not see them easily, but what pilot has the time to gaze at waves moving against the shore-line in a fast plane? I do find water effects are much better now when flying around low and slow, in that you do not get the same wave in the same dang place all the time, so the scene is definitely more dynamic. The static waves were very obvious in small inland bodies of water, now at all alts I can see them moving (REX4 TD also seems to have scaled them down); just do not use the movement you see to decide on wind direction for landing at uncontrolled airfields! White caps are still missing. I think what people mistake as white caps are isolated reflections ocassionally caught off waves, that you usually see near to the plane, and some REX coral textures have white foam spots/caps as part of the texture itself, that bob around on surface, but do not fade or move position like proper animated white caps. Shore line waves are still missing - an old 2D effect that was probably removed because it clashed with the new 3D water surface, just as ship wakes used to - have not checked if that was fixed. Both the above would definitely add to the sense of water movement. I suggest those who do not see the animations as others do, after modification of the WaterConstant.xml file, have unrealistic expectations, or are not distinguishing between the detailed water animation of the tesselated surface (water surface animation) and the large-scale scrolling of the water textures at higher alts and greater distances (texture scrolling animation), which was broken by the strange, very low values of fWindScale factors in the released WaterConstants.xml file. I wanted to make a movie this weekend explaining all this visually, and pointing out some errors I still see. Unfortunately I was mugged at knifepoint on Friday evening, and have spent the entire weekend with police, banks, etc. Just happy to be alive, it was close! So will try to get some time in the next few days to do this. Rob

For CFG settings you must have; Tesselation factor - Ultra Mesh resolution - 1m Texture Resolution - 7cm Water Detail - Ultra REX also advise; HDR - ON (I do not have it on as I do not like it - personal perference) Level of Detail Radius - Max (I have mine at Ultra and animations work, but maybe in you want to push the distances out further and can afford the FPS then try Max) Other settings I have are; Special effects detail - High Special effects distance - High Have not changed these while experimenting with water animations so do not know if they play a role in this) I find having Reflections for clouds enabled also helps as can see waves altering edges of cloud reflections on rough water. Rob

I really cannot understand why you are unable to see animations form above 1000ft, even with the new REX update. Puzzling as I can see them clearly. Yes at 2000-3000 feet one looses the animation effect of the smaller-scaled sets (#0-3), that are wind controlled, but the larger wave patterns are moving on my system (slower with REXs fWindScale values, so not that obvious) Please try again and look carefully. You need to position yourself over water where you have reference points (coastline with some features, or a harbour wih jettys) - static points against which you will detect the water/waves moving. You need to be in Spot View and look around, carefully. Trying to see the slow motion (gets slower the higher you are, relatively). Trying to see the movement while flying is hard. Or if you are hot-shot at hovering a chopper, try that! I never was. If you still cannot see water/wave motion at higher altitudes, 5000 to 20000ft (lets not talk Jet FLs here - one would not see them really anyhow at the speed one's going), then something must be wrong in your setup. Re: colors there are still SpecularPower, SpecularBlend and SpecularBoost settings in the .xml that one could play with - I have not tried. All the other settings (UV etc), and Low, High, Mid groups that used to be in the old FSX, root version, are gone. Obviously a modification by LM, plus moving the xml to Appdata, that they had their good reasons for doing I guess. Colours are fully controllable in REX ESSENTIALS (where you can recolour water to whatever you want by plankton content, and change brightness, saturation and contrast) or Texture Direct (more limited, but still 18 sets to choose from, with bright, medium and dark variations), so I personally have no problem getting the colour I want. Hope you can find a "happy" setting sooner rather than later!