2.4.0 RC1 is ready - Need feedbacks!

[HanselVB]

Oh i downloaded it. Errm do i have to delete my existing flightgear to use this one!

That's completely up to you. For example, if you notice this new version doesn't work as smoothly as the previous version, you could keep the old version to use that one for flying regularly and the newest one for testing or for being able to have a look at the newest aircraft in FlightGear (they might not work on the older version). If you do so, rename the old version to FlightGear 2.0.0 and the new one to FlightGear 2.4.0, or simply put them in separate folders.

[ThorstenB]

So i need to disable this nice light-blue sky effect?

It might solve it, but in return we loose a nice new feature in FlightGear...

The sky dome effect is actually experimental. There was a discussion whether to include this in FG or not, since using it results in a few issues. It was decided to include it anyway - so that the work done on it isn't lost and hoping for someone to resolve the remaining issues.

[someguy]

Alrighty. I stumbled across the dialog for setting a path to the Scenery-TerraSync folder. The default *should* be "/Applications/FlightGear.app/Contents/Resources/dataScenery-TerraSync" and not blank, IMHO. Now it works.

[fmg]

Hello,

here the issues I noticed on a first look. Some of them are also reported by others, but I think its better to leave them in to get a better overview.

Testmachine: MacPro 3.2 GHz Quad-Core Xeon, 8 GB RAM, ATI Radeon HD 5870, MacOS X 10.6.5, FG 2.4.0 RC1.

1. TerraSync don't work on startup. It only start working after specified a path in the environment scenery-download dialog (data/scenery-terrasync in my case). Maybe putting this in for default could solve this?

2. Can't cycle through the HUDs anymore. The only existing HUD is in most views to large, so you can't see the compass-rose. I prefer to use the old HUD that is is visible in all view-angles. This is very helpful for working on FDMs because it also show the AOA value. Now its gone

3. A B747 is parking on runway 28L at KSFO when not in multiplayer-mode. Takes some seconds before it appears.

4. Local weather sometimes cuts frame-rate to the half (At KSFO 60 to about 29. From 36 to 17 in multiplayer environment). Looks like it permanently building up new clouds. Appears very nervous and seemed to be less often in former versions. More details see 14.

5. You can see where water tiles are stitched together. They have slightly different colors.

6. Ignores the path for screenshots that are given in preferences.xml. Always puts it into resources.

7. Binds the generic RGB-profile into screenshots instead of the monitor-profile. Former test-versions from the Hudson-server don't bind a profile so that the monitor-profile is used by other software like it should be. So it would be better not to add a profile to the screenshots because color look ugly if you have a monitor with a wide gamut with the generic RGB-profile.

8. In view mode you can't rotate your point of view in a full circle around any more. At some positions it flips about 90 degrees.

9. Starting it as it comes all windsocks are gone. Also some other scenery element like pylons are missing. They appear later after putting <use-custom-scenery-data type="bool"> to false and managed to get TerraSync to work. But they also stay if you put <use-custom-scenery-data type="bool"> to true afterwards. So I am not sure for what is really responsible for that.

10. Misses to activate to follow you in the multiplayer moving map. You have to select you manually each time again. This worked fine until version 2.0.

11. The cockpit of the Cessna C172 is invisible.

12. Ignores selection of parking position or a runway specified in the launcher.

13. Seems to write a rather detailed log-file even if no logging is chosen. During the few tests I've done it produces a log-file of 607 MB size. This may be triggered from playing around with the scenery download dialog? Don't have tracked this further.

14. Frame-rate is significant lower then in V2.0.0. During a flight from EDFM to EDDK it went down 3 fps and stayed around 5-7 fps (Multiplayer while TerraSync was running).
Another test-scenario: J7W Shinden standing on starting position in EDDI 27L. TerraSync scenery, cockpit view.
Normally used rendering options: Particles, Precipitation, 3D Clouds, Material Shaders: Crop Texture, Water reflection, Transition effects and Persistent contrails. The rest is off. Here are the results:

Normally used settings as above: 10-11 fps.
All rendering options off: 12-13 fps
Normal settings + Local weather METAR: 6-7 fps
Normal settings + Local weather without METAR: 7-8 fps. During flight this went down to 5-6 fps, up to 218 ms latency.

In V 2.0.0 this is 15-16 fps with local weather and above rendering options on and a scenery which contains about 1256 additional trees compared to the TerraSync scenery. In V2 local weather (newest possible version) runs for me without a loss in fps.
But it would be one of my greatest pity not to have the local weather
Interesting thing is, that one my old machine Mac QuadCore G5 with MacOSX 10.4.11 the hole thing is about quite as fast or even a bit better thought this machine should be about a factor 3 slower then the new one (sadly without 3D clouds. But turning them off isn't the clou for fps now it seems).

15. FW 190 consumes no fuel anymore (Yasim). Someone told me some time ago that other planes have the same issue, but I don't remember which.

16. Selecting Live data in global weather dialog again after it somehow had turned of wont find any METAR.

17. Taxiway lights look red from the distance (during approach).




And I am one of the few that missed the version for MacOS X 10.4 PPC.


A bit off topic: a comment to V2.0.0 r284 which works almost fine for me except this:

Crashes while loading the Concorde v 2.6. Same plane works fine in the previous version and works fine in v2.4 also.


f-)

[bschack]

Some notes from my experience of of using the OS X 2.4.0 RC1:

Machines:

2011 iMac with ATI Radeon 5750 (1 GB VRAM)
2006 MacBook Pro with ATI Radeon X1600 (128 MB VRAM)

(1) Speed - It depends a lot of configuration of course, but in a standard out-of-the-box setup, the iMac is very good (60 fps most of the time). The MacBook Pro is basically unusable (< 10 fps much of the time, with some looong delays when switching views).

(2) Lights at night - the iMac draws nighttime runway lighting correctly, the MacBook Pro doesn't (this is with the "use sprites" rendering option checked).

(3) Mouse jumpiness - both Macs exhibited the mouse jumpiness others have noted - when the mouse is moved to near the edge of the screen, it suddenly jumps to the centre, and the stick (or whatever you're controlling) jumps along with it.

(4) Parking positions - I tried selecting a parking position at KSFO on the interface, but always ended up on a runway. I checked how FlightGear was being started, and saw that it wasn't being told about a parking position (I presume this is done with a command-line option).

(5) ATC chatter - now works (on both machines)

I had no problems with seeing the exterior of the B1900, as others have reported. On the MacBook Pro, I noticed the skin of the C172p was not smoothly coloured - it looked like some surfaces were bleeding through. Curiously, the skin discolouration pulsated regularly (about once a second), but in synch with what I couldn't tell.

Many thanks go to Tat for getting the release candidate out, and for all that he's done in maintaining the OS X side of things.

Brian

[Thorsten]

4. Local weather sometimes cuts frame-rate to the half (At KSFO 60 to about 29. From 36 to 17 in multiplayer environment). Looks like it permanently building up new clouds.

Depends on options - if dynamical convection is on, it actually should continuously build new clouds and eliminate old ones. Framerate cut in half sounds like all dynamics on - the easy fix is then to switch dynamics off.

Dependent on actual weather, especially METAR can seriously screw with framerate, and you have to manually reconfigure view ranges. I once had a METAR report building four (!) 8/8 layers - the system is designed to run full view range with one and some scattered clouds in addition... naturally this runs you from 60 into single digits without a problem.

So - in order to understand if your framerates are normal or not, your set of options and the actual weather you had would help.

[fmg]

4. Local weather sometimes cuts frame-rate to the half (At KSFO 60 to about 29. From 36 to 17 in multiplayer environment). Looks like it permanently building up new clouds.

Depends on options - if dynamical convection is on, it actually should continuously build new clouds and eliminate old ones. Framerate cut in half sounds like all dynamics on - the easy fix is then to switch dynamics off.

Dependent on actual weather, especially METAR can seriously screw with framerate, and you have to manually reconfigure view ranges. I once had a METAR report building four (!) 8/8 layers - the system is designed to run full view range with one and some scattered clouds in addition... naturally this runs you from 60 into single digits without a problem.

So - in order to understand if your framerates are normal or not, your set of options and the actual weather you had would help.

Hello Thorsten,

thank you very much for your reply and for the local weather also of corse. When I started testing the V2.4 RC1 Mac I just kept the settings that I used with v2.0. But in version 2 METAR for local weather won't work anyway. So I never run into this before. Terrain presampling, dynamical weather, dynamical convection and detailed clouds were turned on. This worked pretty well in v2 without a significant loss in fps.
But if the weather is given by METAR then it makes no sense to create an dynamical weather also. So I turned all off except detailed clouds. This stopped the nervous cloud-building. Maybe it makes sense to turn this off automatically after selecting METAR?
But the frame-rate don't went up like hoped for. This depends on the detailed clouds. Here the results from a short test this morning.
J7W from KSFO, METAR on.
Global weather 39 fps
local weather without detailed clouds 31 fps
local weather with detailed clouds 19 fps (went down to 13 in some situations during curving)

So now I know how to optimize the frame-rate, but I prefer the detailed clouds anyway. They look much better in my opinion. See example below. Without detailed clouds are on top.

Frank

P.S.: I've also cleaned the cloud-pictures used by local weather from artifacts. If you like, I can send it to you. When I remember it correctly this was reported to be done in v1.18 also. I don't know, which version is included in the V2.4 RC1. But here are some artifacts still there.

[Thorsten]

But if the weather is given by METAR then it makes no sense to create an dynamical weather also. So I turned all off except detailed clouds. This stopped the nervous cloud-building. Maybe it makes sense to turn this off automatically after selecting METAR?

We seem to have a terminology mismatch here, so let's clear this up first:

* 'dynamical' = 'time dependent', i.e. largely clouds, rain and weather effects move with the wind
* METAR = 'conditions based on live weather reports'

Now, the METAR mode makes an assumption, and that is that either you are going from A to B or there is sufficient wind, i.e. weather changes because the airmass changes, not because the conditions in a given airmass change (that's as far as I know physically reasonably well motivated under most conditions). In practice, METAR information is used only when a new tile is created, but not to change a tile that's already there (if you would change a tile already created, you'd see a discontinuity as in Global Weather when the layer altitudes are recomputed - all clouds suddenly disappear and different ones reappear a moment later) - that's *very* bad for soaring for instance.

Thus, once a tile is built (regardless if by METAR or offline weather system) it stays the way it is forever unless there is dynamics on, i.e. clouds, thermals, rain are glued to a spot when dynamics is off. If you select dynamics off, get a METAR report for a location and stay there, subsequent METAR reports from the same location will not change what you see because the tile never drifts off your location. The underlying justificationn is that this doesn't matter because Flightgear is a Flight simulator, not a parking simulator, so because you usually fly out of your location anyway, and since the plane is much faster than the wind, you will see different weather because you go to different places.

When dynamics is on, all things are allowed to move with the wind (change elevation where applicable, ...). That's the leading change term - what you see changes as the airmass (= wind) flows by. When you have METAR on and stay at a location, a new METAR report will change what you see as soon as the wind drifts a new tile to your location.

Convective dynamics captures the next-to-leading change term, i.e. change within the airmass - convective clouds in nature are continuously born and decay. So with convective dynamics on, staying at any given location you will see changing conditions even if there is no change in the METAR report - just as in nature, while gross conditions may stay the same, two pictures of the sky taken 15 minutes apart will never look the same.

Having said that:

Terrain presampling, dynamical weather, dynamical convection and detailed clouds were turned on. This worked pretty well in v2 without a significant loss in fps.

This is very weird and suggests it never worked before. For practically everyone else, moving clouds the old-fashioned way was associated with drastic loss of framerate (1/2 is a typical factor).

Global weather 39 fps
local weather without detailed clouds 31 fps
local weather with detailed clouds 19 fps (went down to 13 in some situations during curving)

Here the visibility range of the clouds is the decisive factor - it only makes sense to compare the same range for both weather systems. Global Weather is limited to 20 km max. in 2.4 (I think). Just visually from your screenshots, it seems to be much larger, possibly maxed out at 45 km. If so, your numbers make a lot of sense to me, and I suspect if you would limit Local Weather to 20 km visibility range then you'd see a framerate well above 30 even with detailed clouds.

[HanselVB]

Alrighty. I stumbled across the dialog for setting a path to the Scenery-TerraSync folder. The default *should* be "/Applications/FlightGear.app/Contents/Resources/dataScenery-TerraSync" and not blank, IMHO. Now it works.

Doesn't work for me...

[ThorstenB]

(2) Lights at night - the iMac draws nighttime runway lighting correctly, the MacBook Pro doesn't (this is with the "use sprites" rendering option checked).

The idea of introducing the switch was to disable the sprites for graphics cards who have runway light issues - so mainly for a range of ATI graphics cards. The option should be safe to enable for all NVidia and some ATI cards. Unfortunately there was no way to automatically detect supported systems - since this is a very specific graphics card/driver/FG issue. But I haven't heard of anyone having issues when the sprite effect was disabled. If that's different here, let me know.

(3) Mouse jumpiness => This is definitely fixed for the final release.

(4) Parking positions => Apparently that is a launcher issue. FG works fine when run by command-line. Which launcher is used for Mac? FGRun? Or a Mac-specific launcher?

[clrCoda]

(4) Parking positions - I tried selecting a parking position at KSFO on the interface, but always ended up on a runway. I checked how FlightGear was being started, and saw that it wasn't being told about a parking position (I presume this is done with a command-line option).


Brian

Hi Brian. I know this is a thread for release candidate 1, and I am about to mention release candidate 4, and this info you may already have found, but I thought I'd pitch in 2 cents worth, here goes...

Look in the file (flightgear-directory)/terrasync

Mine is empty.
In the 2.0 version of flightgear it was necessary to put a properly set up "parking.xml" in this folder, under sub folders that would be like, for instance for KSFO

(flightgeardirectory)/terrasync/Airports/K/S/F/KSFO.parking.xml

That file would sometimes contain other things as well as the parking positions available to start parked, including the groundnet taxi ways for AI planes and also default radio settings for the airport.

That file would put the parking position and those other things I mentioned into the "world".

Another file, identical, would be required to put the parking positions in the selection box of FGrun and the path would look like... again for KSFO

(flightgearDirectory)/data/ai/airports/KSFO/parking.xml

The two parking files would be identical, but one would be named KSFO.parking.xml and the other just parking.xml but in a folder for the airport, in this case KSFO.

Okay move on to version 2.2 and the file names had changed. Still called parking.xml in the data/ai/airports/**yourairportfolderherefolder**

but now named KSFO.groundnet.xml in the terrasync folder, recall the subfolders are Airports/K/S/F...

Okay, release candidate 4 and the terrasync folder is blank. nothing in it. So as I write this, I decide to see if I can add a working parking position and...

It works!

You need your Parking Index number and a name and a parking place number, parking co-ords == the lat the lon, and the heading you want to face, for the position in a file that looks like ( this one for CYUL Montreal). You can add as many parking places to this as you need by incrementing the parking index number.

Code: Select all

<?xml version="1.0"?>                                                   
<groundnet>                                                             
  <parkinglist>                                                         

    <Parking index="0"
         type="gate" 
         name="1RAY"     
         number="1" 
         lat="N45 27.569"
         lon="W73 45.296"
         heading="180"     
         radius="70"       
         airlineCodes=""   
         pushBack="right"/>

  </parkinglist>
</groundnet>


You need one version of this file named parking.xml in the folder: ( note you will most likely need to add the folder)

(flightgearDirectory)/data/ai/airports/CYUL/parking.xml

and another file in a folder in the terrasync folder like:


(flightgeardirectory)/terrasync/Airports/C/Y/U/CYUL.groundnet.xml

Same file, different names, like I said earlier, one puts the location in FGrun parking select box, the other puts the position in the world.

If you already have a file with an airport nameDOTgroundnet.xml that does not include a parking position you want, you can always copy the above format and add it into a DOTgroundnet.xml file or otherwise alter an included parking position. ( was that way too obvious )

Hoping this helps.
Ray

[fmg]

Terrain presampling, dynamical weather, dynamical convection and detailed clouds were turned on. This worked pretty well in v2 without a significant loss in fps.

This is very weird and suggests it never worked before. For practically everyone else, moving clouds the old-fashioned way was associated with drastic loss of framerate (1/2 is a typical factor).

Global weather 39 fps
local weather without detailed clouds 31 fps
local weather with detailed clouds 19 fps (went down to 13 in some situations during curving)

Here the visibility range of the clouds is the decisive factor - it only makes sense to compare the same range for both weather systems. Global Weather is limited to 20 km max. in 2.4 (I think). Just visually from your screenshots, it seems to be much larger, possibly maxed out at 45 km. If so, your numbers make a lot of sense to me, and I suspect if you would limit Local Weather to 20 km visibility range then you'd see a framerate well above 30 even with detailed clouds.[/quote]

Thank you for all the explanations. Now I'm a bit wiser and have done one short test with setting the visibility slider in the middle. In this case fps are about 30. The slider was set to max, as the setting was before in V2. Now I'm about leaving for vacation and don't have the time to investigate things further, but I'm afraid my local weather installation in v2 don't work like it should be. This may be the reason for it's uncommon frame-rate values. Unfortunately I don't copy the METAR string of my V2.4 tests. So when tried to produce a similar scenario in V2.0 I discovered that creating clouds in the local weather dialog don't do anything. The installation never worked for me via the install-add-ons button in the launcher. So I copied the files manually in the specific folders. Maybe there went something wrong. I'll have to look for this later.
I won't be able to answer in the next weeks, but won't leave you without a response for so long.

Frank

[tat]

Thanks guys for feedbacks.

What I did during 2.4.0 RC1 and 2.4.0 were:
- made terrasync option work with integrated in-sim terrasync
- fixed real weather fetch option (enabled by default, uncheck to disable it )
- renewed anti-aliasing option (2 or 4 is recommended for MacBook Pro (except 13")/Mac Pro/faster iMac, OFF for other Macs)
- fixed scroll up/down issue with Track Pad.
- some other minor fixes.

If you have further problems with 2.4.0 official release, please make a new thread on this forum or email me.
If your problem doesn't seem Mac specific (like high altitude scenery problem above), you can report it via flightgear bug tracker:
http://code.google.com/p/flightgear-bugs/issues/list

Best,

Tat

[Lightman]

Hi Tat,

Thanks for all your work. Tat I get the message fgfs quit unexpectedly. I posted a log in the forum, but not under your topic starter, lol

Lightman