Re: [Flightgear-devel] fgfs on Android source request

[ThorstenB]

On 20.02.2011 15:40, Curtis Olson wrote:
> I know there is one android/flightgear app that serves as a remote 
> control for flying FlightGear via your android phone--perhaps that is 
> what you found?  It uses the network interface which provides good 
> separation of application licensing. 
Yes & no. It's an app particularly marketed as a flightsim for Android - 
named "FlightGear". Pictures promoting the app show the infamous 
ProFl*Sim package. It also has a link to the profl*sim website (e.g. 
FlightGear dot us). So, it's another activity of the ProFl*Sim scammers. 
They certainly haven't ported FG to Android, so it's either a complete 
hoax - or they indeed try to sell the Android remote control (pretending 
it to be a full flightsim). My guess is the latter (since it saves them 
work of creating a hoax application first).

This site offered the "FlightGear" (ProFl*Sim) package for Android until 
a few hours ago:
http://de.appbrain.com/app/flightgear/com.flightgear

Now it just says "This app is unfortunately no longer available on the 
Android market.". Ha...

Partially it's still visible in google's cache:
http://webcache.googleusercontent.com/search?q=cache:9zRzOnUzIVsJ:https://market.android.com/details%3Fid%3Dcom.perfectflight+android+flightgear

cheers,
Thorsten


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgfs on Android source request

[ThorstenB]

On 20.02.2011 16:18, George Patterson wrote:
>> This site offered the "FlightGear" (ProFl*Sim) package for Android until
>> a few hours ago:
>> http://de.appbrain.com/app/flightgear/com.flightgear
> Anything like this one?
>
> http://www.appbrain.com/app/alni-flightgear-control/org.alni.android.fgfs.control

No, Alni is the good guy :). He's the original author of the remote control:
http://www.flightgear.org/forums/viewtopic.php?f=18&t=10761

Also, Alni's offer is for free - and doesn't pretend to be a full 
flightsim...

cheers,
Thorsten


--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] fgfs on Android source request

[ThorstenB]

On 20.02.2011 17:27, Michael Sgier wrote:


let me know if anyone can buy it and show the source. I really was 
surprisedi never would have given this guy such programming knowledge.


In fact i'd want to look at that but am currently stuck at native c++ 
glut via Android's


NDK. Probably it would need to use the glut android port.



Forget it. They haven't ported anything. It's a hoax. The user comment 
that Curt found said it all. The app merely takes you to their website - 
so you can buy another scam product. You don't want the source code of 
such a trivial app.


cheers,
Thorsten
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] New instrument: TCAS

[ThorstenB]

Hi,

I just pushed a new instrument to "next": we now have a TCAS device.
It's a new module providing aural alerts for conflicting traffic. It's
also able to drive TCAS displays, since aircrafts' threat-levels are
exposed to the property tree. The existing wxradar instrument is
updated accordingly, and now has an option to display traffic in
TCAS-style (colorful diamonds/circles showing the traffic's
threat-level). The TCAS is implemented in the FG core and requires
minimal performance - so should be fine even at busy airports.

And it works with AI and multiplayer traffic. As expected, AI pilots
are well-trained, so they always respect TCAS advisories: when you get
a "climb! climb!" alert in your cockpit, you'll also see conflicting
AI planes dive to safety (or vice versa). And since you're a
responsible pilot, I trust you'll also know what to do... :)

There's more info on its features and installation in the wiki:
http://wiki.flightgear.org/index.php/TCAS

I've tried to stick as close as possible - well... reasonable :) - to
the TCAS II standard. The traffic detector shouldn't be too far off.
However, I've simplified the advisory code a bit. A TCAS II only
provides vertical advisories (so it's either up or down...), but
there's still a long list of variations and exceptions in the
standard. Also, determining/predicting an optimal evasive movement for
conflicting aircraft isn't always easy. Well, should be good enough
for most situations as it is now. I might still add a few more
advisories later - as well as improve the MP support.

The TCAS and new display is already installed on the 777 now. And the
cockpit is also extended with an ATC/TCAS panel (more switches!) -
huge thanks to Syd Adams for another nice modeling job! A good area
for test flying the TCAS is EHAM - with lots of AI traffic. Give the
AI pilots a hard time by interfering with their nicely aligned
approach sequence.

The default TCAS voice samples in fgdata are temporary stubs only
(artificial voice). Hopefully we can replace them by more realistic
sound samples soon. But you can also provide custom voice samples for
an aircraft (which is also possible for the GPWS now, see "GPWS" in
the wiki).

Hope the new instrument works for everyone (well, Hudson compiled
it!). And hopefully this won't trigger a new multi-player sport
(proximity flying to trigger TCAS alerts) - otherwise just use the
"ignore pilot" buttons.
Fly safe!

cheers,
Thorsten

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Telnet lag?

[ThorstenB]

On 27.02.2011 15:48, Geoff McLane wrote:
> On Sun, 2011-02-27 at 14:06 +0100, Roberto Inzerillo wrote:
>> Well, it works ... but the telnet connection is very slow
>> and that slows down every intercation, it makes it far less than realtime
> I quickly added some 'timing' to my telnet access,
> through a perl script, and find :-
>
> 39 accesses took 15.57 secs, av 0.4 secs per access...
>

Hi,
a look at the sources shows that a fixed polling interval is used for 
telnet - default is 5Hz. So it cannot process more than 5 commands per 
second. That's why it's slow. There's better methods of implementing 
socket communication instead of polling, but I haven't looked into the 
module and don't know why this was chosen. The polling interval is 
configurable though - so you can speed it up. Use:
 fgfs . --telnet=medium,direction,HZ,localhost,PORT,style

Use HZ to select the polling frequency (e.g. "100") and PORT for the 
telnet port (e.g. ). The other parameters are unused (it seems) when 
using the telnet protocol. Probably there for historic reasons (?). 
Maybe Curt knows. Remember you have to specify 6 parameters separated by 
a "," - otherwise you cannot configure the polling frequency. So call 
something like
 fgfs . --telnet=foo,bar,100,foo,,bar

cheers,
Thorsten


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Logos and licensing

[ThorstenB]

On 27.02.2011 21:18, Gene Buckle wrote:

I for one, do NOT welcome our new Vichy FlightGear Overlords.  Zey hav
vays of makingink you comply.
Until you mouth-breathing back-biters understand the concept of "no harm,
no foul", I don't want to have a thing to do with you.

*« Bravo, vous avez gagné 1 point Godwin.*
Vous pouvez aller le découper au burin
sur votre écran... »
                   
/  __) () () () () () (__  \
|_|  |_|
 _  __   __
| |/ |   _ __   ___ (_)_ __ | |_ | |
| || |  | '_ \ / _ \| | '_ \| __|| |
|_|| |  | |_) | (_) | | | | | |_ |_|
 _ |_|  | .__/ \___/|_|_| |_|\__| _
| | |_|  | |
| |  | |
|_|    _  _  |_|
 _ / ___| ___   __| |_  _(_)_ __  _
| |   | |  _ / _ \ / _` \ \ /\ / / | '_ \| |
| |   | |_| | (_) | (_| |\ V  V /| | | | |   | |
|_|\|\___/ \__,_| \_/\_/ |_|_| |_|   |_|
 __
| |__                  __| |
\) () () () () () (/


So, we haven't solved the issues with trademark law - but at least 
fulfilled Godwin's law. Congratulations.

Another discussion on this list turning ugly/personal/offending eventually.

--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Texture efficiency

[ThorstenB]

On 03.03.2011 09:47, thorsten.i.r...@jyu.fi wrote:
> The total time to load a configuration is really proportional to
>
> (number of objects) x (texture size of a single object)
So maybe the textures aren't really shared. What's worse - and slightly 
related: I ran a memory analysis some weeks ago, to identify "true" 
memory leaks (that is memory leaks triggered at source code locations 
which over time increase indefinitely). I found that the MP aircraft and 
clouds are a major cause for FG memory leaks. The more MP aircraft were 
loaded and unloaded (obviously not properly unloaded though), and the 
more clouds were displayed (and also not properly unloaded), the higher 
the number of leaking memory elements gets (and the higher FG's memory 
consumption gets). Another huge memory leak is caused by properties. The 
leaking properties may be a result of the other leaks though (they might 
still be referenced by leaked clouds or MP aircraft models), though 
there could also be a separate issue.
I only checked the number of memory elements - so not sure which leaks 
will actually hurt memory consumption the most. But at least it was 
pretty obvious that we have some bad issues in these areas.

I'm currently busy with other stuff. But checking on what's going wrong 
with loading/unloading clouds and MP models may be worth a closer look.

cheers,
Thorsten


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Texture efficiency

[ThorstenB]

On 03.03.2011 20:51, Torsten Dreyer wrote:
>> I'm currently busy with other stuff. But checking on what's going wrong
>> with loading/unloading clouds and MP models may be worth a closer look.
> There was a fix for a MP memory leak approx. two weeks ago:
> http://gitorious.org/fg/flightgear/commit/8962477cfa10850cb459d7de754c9a435cc91293
Hi Torsten,

ha!! Yes, I'm getting older, maybe I'm already starting to forget 
things? :-)
But no, this patch only fixed a leak I found in the MP communication 
module. The analysis showed more leaks - but unfortunately I couldn't 
see any obvious fixes for these. There are remaining leaks related to 
the actual model objects (e.g. objects from OSG derived classes) for 
clouds and MP planes. Maybe something with the osg reference counting 
doesn't work there as expected...

cheers,
Thorsten


--
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Serial Connection is broken in Windows binary

[ThorstenB]

On 07.03.2011 22:49, Roberto Inzerillo wrote:
> I'm getting results with Arduino and FGFS, at least in a Linux
> environment, that's good. But I will just shortly mention there's
> something broken in the Windows binaries.
You mentioned using "\n" as a line separator in an earlier email. One 
common source of trouble when moving between Windows and Linux (or Mac) 
are line feed issues. Maybe the fgfs parser is confused by the encoding 
it gets from your port/driver. Windows uses "CR LF" (\r\n) as a line 
feed, Linux/Mac uses "LF" only (\n). A serial port can be configured to 
convert the line feed encoding, i.e. Linux may convert "CR LF" to "LF", 
a Windows driver may do the opposite. I remember configuring (disabling) 
this auto-conversion property for a serial port years ago - when I used 
python for an RS232 interface on Windows and Linux. fgfs probably 
expects "\n" only - even when running on Windows. Just an idea. Other 
than that: I have no idea... ;-)

cheers,
Thorsten

--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] File sizes in fgdata, clean up needed?

[ThorstenB]

On 18.03.2011 17:50, HB-GRAL wrote:
> Today I checked the current fgdata/Aircraft folder for sizes. It’s about
> 4,3 GB here. Nice.
>
> Some of this files are .gz already, when I .gz the rest I get another
> 100 MB, or in other words I get two MiG-15 or another p51d.

Nice statistics! Maybe this motivates some of us to be a bit more 
considerate before committing something to the repo.

However, remember that dropping any file from the repository wouldn't 
help at all now: a git repository never shrinks - it can only grow... 
It's an especially bad idea to drop files and resubmit a 
smaller/compressed version in a futile attempt to shrink the repository.
git contains a complete history of every file. If you dropped files and 
resubmitted a smaller version, the local fgdata directories may at first 
appear smaller - but if you checked the total size (that is including 
the hidden ".git" folders) you'll see that the total size was actually 
increased...

And another warning: the complete history issue also affects personal 
git branches on gitorious. So, if an a/c designer adds 19 versions of an 
image file to his private branch and then placed a "merge request" to 
fgdata/master - then the merge will actually copy the history of all 19 
file versions to the master branch - even the history of files which 
were already dropped on the private branch. So, in such cases it's a 
good idea to not actually "git merge" the complete personal branch to 
our "master" - but to simply take a copy of the latest version of the 
a/c files and to submit them to "master" using a fresh commit (I think 
that's what our fgdata-merge-committers do anyway - at least I hope 
so...). Or maybe any git expert knew if there was a 
git-merge-without-history command?

Indeed, fgdata/master is becoming way too big though. But we can only 
solve this by splitting our current repository - and then push the 
different parts to fresh git repositories. Splitting fgdata was planned 
anyway. The new "--fg-aircraft" options was the first step to make this 
possible. I'm just not sure what the status of splitting fgdata is though...

cheers,
Thorsten


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Instant replay and JSBSim aircraft

[ThorstenB]

Hi all,

I'm seeing an issue with the "instant replay" feature which seems to 
affect JSBSim aircraft. The actual replay works, but once replay is 
finished, the sim locks up or goes wild when trying to resume normal 
flight. Looks to me as if the FDM was somehow messed up by the replay. 
The FDM's update is suspended during replay - but I suspect there may be 
an issue with the tied properties, which still allow the FDM to see the 
replayed movements. YASim aircraft seem to be fine though.

But maybe that's a local problem here only, since no one else reported 
this yet. Would be nice if s.o. could double-check... I've tested this 
with the 747 and F16 - using latest GIT.

cheers,
Thorsten


--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Instant replay and JSBSim aircraft

[ThorstenB]

Hi,
not sure if anyone else had a chance to test the "instant replay" with
JSBSim aircraft - but it indeed seems like a general issue to me. It's
triggered by JSBSim doing a "trim" operation once playback has
finished - which produces an output like this (with the F16 in this
case):

  Trim Results:
  Altitude AGL: 15  wdot: -1.83e+08 Tolerance: 1e-03  Failed
   Pitch Angle:-19  qdot:  9.33e+07 Tolerance: 1e-04  Failed

  Trim Statistics:
Total Iterations: 61
Sub-iterations:
wdot: 0 average: 0  successful:  0  stability: 3.5272
qdot: 0 average: 0  successful:  0  stability: 3
Run Count: 1201

Soon afterwards, the entire sim locks up since the FDM numerics go
wild. I can avoid this issue by suppressing the re-trim when replay
has finished (by forcing "needTrim = false;" in the code). All works
well for me then - but it completely kills the "needTrim" feature in
JSBSim, which was probably implemented for a reason...
The trim is triggered since the FDM still has its property listeners
connected during replay - so it thinks the aircraft position changes,
which sets the FDM's "needTrim" flag. Might be a good idea to
disconnect the FDM property ties during a replay - but JSBSim
currently doesn't allow to reconnect the ties ("bind" method is not
implemented). And the basic problem here probably is just that
something with re-trimming an aircraft doesn't work properly.

Any ideas on what could go wrong when the FDM tries to trim an already
trimmed aircraft?

cheers,
Thorsten

On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB  wrote:
> I'm seeing an issue with the "instant replay" feature which seems to affect
> JSBSim aircraft. The actual replay works, but once replay is finished, the
> sim locks up or goes wild when trying to resume normal flight. Looks to me
> as if the FDM was somehow messed up by the replay. The FDM's update is
> suspended during replay - but I suspect there may be an issue with the tied
> properties, which still allow the FDM to see the replayed movements. YASim
> aircraft seem to be fine though.

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Quiet

[ThorstenB]

Quiet?? Who said quiet? :-)

--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] OSG version (was Auto-hiding the cursor)

[ThorstenB]

On 21.03.2011 21:04, HB-GRAL wrote:
> Just to report: It’s a OSG 2.9.9 issue on OSX, was going back to 2.9.7
> and all works fine. Also the keyboard input.
>
> (I am a victim of the wiki too now :-P , I wrote myself months ago 2.9.7
> is needed and someone changed requirement for OSX 10.6 to OSG 2.9.9.
> Don’t know the reason for this, but beside that, I guess the nightlies
> based on 2.9.9 are also not working correctly ?)
> htgear-devel

Until some weeks ago, there was a standard recommendation in the wiki to 
use latest OSG-svn when running FG git (actually in several places in 
the wiki). But using the bleeding edge OSG sources causes issues, since 
OSG development is pretty active and they have frequent changes. There 
is no way we could keep up/test those changes on weekly/daily/hourly 
notice. And sometimes OSG itself is also introducing new bugs in their 
code (like this probably: 
http://code.google.com/p/flightgear-bugs/issues/detail?id=268). Recently 
we've seen many people reporting issues due to unstable OSG - both, in 
the tracker and on the mailing list.
Also, we found that any "normally advanced" FG git user doesn't even 
need to run the very latest OSG sources. Those very few who actually 
need it (i.e. in order to adapt FlightGear), know anyway what to do (hey 
Tim! :) ).

So, after some discussion we decided to recommend the latest _stable_ 
OSG release by default (which still is OSG2.8.3). And for those, who 
really want to be a guinea pig and test the OSG-developer versions, we 
found that 2.9.9 was the latest (at the time) which was working with 
Linux/Mac/Windows (reported by several people on irc including 
Tim/James, I think). That's why the wiki was changed (default: 2.8.3, 
and 2.9.9 for keen developers). And it was me updating the OSG wiki page:
http://wiki.flightgear.org/index.php/OSG

Personally, I prefer to stick with OSG stable (2.8.3) - which works 
great for me. There are still enough issues in FG git itself to worry 
about... ;-)

I just noticed though, that a number of wiki pages again returned to 
recommend the use of latest OSG-svn *sigh*. I don't know why people keep 
recommending that...

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG version (was Auto-hiding the cursor)

[ThorstenB]

On 22.03.2011 00:08, HB-GRAL wrote:

>  I just noticed though, that a number of wiki pages again returned to
>  recommend the use of latest OSG-svn*sigh*. I don't know why people keep
>  recommending that...

Because it is valid;-)  Maybe not trunk, thats always dangerous, but
2.9.9 seems to work for OSX.


Ok, thanks for clearing that up. Glad that 2.9.9 works fine after all 
then. With "latest OSG-svn" I was specifically referring to the latest 
sources from the OSG subversion "trunk" - which shouldn't be the 
standard for any FG git user (unless you really, really know what you're 
doing).


cheers,
Thorsten
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 22.03.2011 05:24, Robert wrote:
> Ingame (insim) I notice a small stutter that happens once every second.
> Did anybody of you guys notice the same thing?
> What can we do about it?
> I thought it might be something like a timed task. (reading from hard 
> disc + malloc)?
> Please, could someone tell me where I can find this function in the 
> source files?
I don't see this issue here. Are you sure this isn't caused by another 
software on your machine? Some background service (indexing, virus 
scanner)? I don't think you'd be successful just by looking at the code. 
You could test if the effect happens with different planes, i.e. try the 
ufo. If it depends on the plane, try disabling specific instruments 
(modify the XML files), until you found the instrument causing the 
effect. Also check the plane's specific Nasal code: try to disable timer 
related tasks there, and see if this changes the effect.

cheers,
Thorsten

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Texture cache

[ThorstenB]

On 22.03.2011 23:54, Tim Moore wrote:
>> 5, maybe worst: osg plugins which load 3d models seem to load textures
>> >  directly and store them... somewhere. So no caching, if two models use
>> >  the same texture it gets always loaded, no matter what.
> This should not be true in general; the images should be cached and
> the texture objects should be too, unless some parameter is animated
> so the texture can not be shared. Now, I notice that cacheing is
> turned off for a class of models that includes AI models and may
> include models created through Nasal
> (simgear/scene/model/SGPagedLOD.hxx, line 53); I don't know what the
> rationale is for that and that may be the cause of the current
> problems.

The particular line disabling the OSG cache has been there from the very 
first commit (3 years ago to the day). So there is a chance, it was 
never really considered - or there was an issue with OSG library itself 
at the time. On my machine it seems ok to enable the cache - everything 
looks normal with FG.
Maybe someone could do some tests when changing the setting 
(SGPagedLOD.hxx:56) from "CACHE_NONE" to "CACHE_IMAGES" or even to 
"CACHE_ALL" (then recompile/install sg+fg). Would be interesting to know 
how this changed loading times, run-time fps and memory consumption. 
Just make very sure to use a well controlled environment for any 
performance tests (especially no live weather...).

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

Hi,

I've pushed an update to sg/fg/fgdata which enables a (so far well 
hidden) feature of our "subsystem manager" to capture timing statistics.
It''s now configurable at run-time. Use "Debug -> Toggle Subsystem 
Statistics" to enable/disable. It prints min/max/average and 
std-deviation for each of FG's subsystems to the console. The statistics 
interval is configurable via /sim/timing-statistics/interval-s
Since there are a lot of submodules in FG (most of them are very 
friendly and don't consume much time), you can restrict the output to 
modules exceeding a certain minimum execution time - or a certain jitter 
(hey!). Use /sim/timing-statistics/min-time-ms and 
/sim/timing-statistics/jitter-ms to configure the filters (in 
milliseconds, obviously).
Should help finding performance and jitter issues if they were caused by 
one of our internal subsystems.

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 23.03.2011 23:42, Csaba Halász wrote:
> I have found that feature earlier:)
> Also I have actually removed some subsystems, but to no avail.
> Let's see if somebody can produce other results.
Yes, let's see what people come up with :).
I actually see one submodule which produces some jitter. But I'm not a 
squealer.
And my new machine is *very* fast... :)

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Instant replay and JSBSim aircraft

[ThorstenB]

On 23.03.2011 23:22, Bertrand Coconnier wrote:
> Attached is a patch that fixes this bug (#294 in the bug tracker). As
> far as I could test, it restores the functionality of the instant replay
> while keeping the restart feature (CTRL+SHIFT+ESC) functional.
> Furthermore I have implemented the 2 methods suspend() and resume() in
> JSBSim.cxx so that the FDM is actually suspended during the replay.
>
> However this bug fix is not really elegant because the original code is
> not so elegant itself (see explanations above).

Thanks a lot Bertrand! Using the suspend/resume feature of the subsystem 
still is elegant, I think.
During replay, we really don't want the FDM to do anything - preferably 
it shouldn't even notice that anything has changed at all. So, 
suspending the FDM and disabling its callbacks is a good idea. At least 
easier than disconnecting/reconnecting the property callbacks.

It fixes all the issues I have seen and replay works fine now - so I 
pushed it to git. But are the JSBSim.* files officially maintained in 
the JSBSim repo (so the patch also needs to be proposed over there) - or 
are these files owned by FG now?

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 24.03.2011 14:33, Robert wrote:


Timing summary fornasal.
-  mean time: 0.04 ms.
-  min time : 0.00 ms.
-  max time : 2.05 ms.
-  stddev   : 0.24 ms.


I don't think we have to dig into nasal code like Franz suggested 
(please correct me if I'm wrong) because as you can see there is no 
significant amount of time spent in comparison to this:


Timing summary for   events.
-  mean time: 1.09 ms.
-  min time : 0.30 ms.
-  max time : 37.14 ms.
-  stddev   : 4.24 ms.


Robert,
you should still look at Nasal. The event manager handles timers, and 
that's almost exclusively used by Nasal. Almost all the Nasal code runs 
in timers (except for property listeners). So read "events" as the total 
execution time for Nasal (timers).
The timing data shown for the subsystem "nasal" only refers to the 
execution time of Nasal internal house keeping (i.e. some garbage 
collection), but not to the execution of actual Nasal code. Indeed 
misleading.


The "events" subsystem is also showing a jitter on my machine (but not 
as bad).


cheers,
Thorsten

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 24.03.2011 23:54, Robert wrote:
> As you can see Nasal scripts aren't used at all.
No, there are several generic Nasal scripts loaded independently of any 
aircraft configuration files.
I checked my system and saw timers from the "mp_broadcast.nas" (which is 
also active when MP is disabled), wildfire.nas and several others. You 
also need to disable all scripts in "fgdata/Nasal" to get rid of all 
Nasal timers.

Also, I had a brief look at exactly which Nasal timers caused a jitter. 
And the winner is...
... well, any. Any Nasal timer, even if it's almost empty, will every 
now and then consume a much larger amount of time than normal.
Seems to be a general issue with the Nasal execution engine: could be 
triggered by Nasal's garbage collector, which every now and then needs 
to do extra work - and runs within the context of a normal Nasal call. 
It could also be a result of Nasal's critical sections: other threads 
may acquire a temporary lock to alter Nasal data structures - which may 
block the execution of Nasal timers at certain points. Hmm... Best 
practices for debugging a multi-threaded program anyone? :)

Concerning the frequency of the jitter: I guess it isn't related to the 
FDM at all. It's probably just a result of Nasal complexity. The more 
Nasal code is running, the more often/likely garbage collection / 
blocking may occur. Frame rate may also influce it: many Nasal timers 
run at delay 0 (in every update loop).

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 25.03.2011 02 :56, Robert wrote:
Yeah you are right. After removing every script from the global Nasal 
folder, the events subsystem showed it spent 0 ms.
Copying the scripts back to that folder one by one increased the time 
spent.
Indeed the jitter is caused by Nasal's "garbageCollect" method. Simple 
test: add a printf (apply attached "patch" to simgear) and you should 
see the "stutter" is synchronized with it.



Hmm...this problem seems to be unsolvable right now.
Well, there is a workaround! Use a faster CPU :). I see a jitter of 
about 7ms with most aircraft.


However, the garbage collector does a complete scan of all Nasal objects 
to detect and remove unreachable elements. So, the more Nasal data 
elements we have, the worse the jitter gets. Large Nasal data structures 
will eventually break every CPU. And since it's done in the context of 
normal Nasal calls, and not in a separate background thread, it directly 
affects the duration of our main update loop - hence frame rate. Not so 
nice.
Hmm. Other script languages rely on reference counting for garbage 
collection, which means much more stable performance. Python does that 
for example. But, well... GSoC anyone? ;-)


cheers,
Thorsten

diff --git a/simgear/nasal/gc.c b/simgear/nasal/gc.c
index e9d9b7b..0926936 100644
--- a/simgear/nasal/gc.c
+++ b/simgear/nasal/gc.c
@@ -37,6 +37,8 @@ static void garbageCollect()
 {
 int i;
 struct Context* c;
+printf("Nasal garbage collector...\n");
+
 globals->allocCount = 0;
 c = globals->allContexts;
 while(c) {
--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 26.03.2011 06:27, Robert wrote:


However, the garbage collector does a complete scan of all Nasal
objects to detect and remove unreachable elements. So, the more
Nasal data elements we have, the worse the jitter gets. Large
Nasal data structures will eventually break every CPU. And since
it's done in the context of normal Nasal calls, and not in a
separate background thread, it directly affects the duration of
our main update loop - hence frame rate. Not so nice.
Hmm. Other script languages rely on reference counting for garbage
collection, which means much more stable performance. Python does
that for example. But, well... GSoC anyone? ;-)


Python support would be a great feature I think.
Well, yes. But changing current scripts would be a huge, huge project. 
And it'd would require much more maintenance than our tiny Nasal engine. 
It's a better option to improve the existing garbage collector (i.e. use 
reference counting, improve its speed, or make it happen less often). 
But that would also be a very complex change in a very sensitive area of 
our sources.


What I am thinking about is a possibility to convert Nasal scripts to 
C or C++ and compile them as shared objects (.so .dll). Then we could 
load them dynamically at fgfs runtime. So in the end we get raw C/C++ 
performance to our modules.

Is this possible or am I dreaming of something impossible here?
Mainly dreaming. Such things may look simple at first. Easy to convert a 
simple "hello world". But it's very complex when supporting all the 
features of an interpreted script language. And the funny thing is: 
you'd still need to worry about automatic garbage collection and count 
references (though that'd be a lesser issue compared to many others 
then). So, time wake up...


For the time being, we'll have to live with this. We should just be 
aware, that introducing too complex data structures and too 
heavy/complex computations in Nasal isn't a good idea. Even when their 
average execution time looks ok, they will eventually trigger noticeable 
frame rate jitters. The larger the data structures get, the longer the 
jitter. The more heavy the computation gets, the more often the garbage 
collector has to run, the more often the jitter happens...


So, it's still good to implement heavy stuff and common instruments in 
our FG core (C++), and use Nasal mainly for aircraft-specific animations 
etc. Though that may not be the direction our project is heading to 
right now...


cheers,
Thorsten

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

On 26.03.2011 10:03, Tim Moore wrote:
> Reference counting doesn't provide a strong performance advantage over
> conventional garbage collection, and a reference-counting scheme can
> take an unbounded amount of time. Reference counting schemes that do
> have real-time or bounded behavior are very complicated.
Well, the issue with scanning for unreachable objects is that it scales 
with the number of data elements in memory. Even when you aren't 
touching the data structures, they still affect performance. Reference 
counting itself doesn't guarantee real-time behavior, since removing any 
reference may result in deleting large data structures. But it's much 
more predictable and can be influence in the code. When certain code 
doesn't touch anything large, then it isn't affected.
There are real-time systems which have successfully integrated a Python 
engine because of this. Though it doesn't guarantee hard real-time "by 
the book", it still works very, very well, and only require few 
limitations (i.e. you have to avoid cyclic data structures, or accept 
that they are leaking).

> I don't know much about our Nasal implementation, but I suspect that
> the garbage collector could be changed to trace only a portion of
> Nasal's heap at each invocation, at the risk of increased memory use.
Hm, not sure. The garbage collector uses "mark & sweep". It locks out 
any concurrent Nasal execution, marks all reachable elements, then 
removes everything unreachable, finally unlocks the engine. The 
expensive bit is the marking of all elements. It's hard to split such a 
task. You could abort the operation, but then later have to start all 
over again, to be sure that you've really traced all references.

cheers,
Thorsten


--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fuel: Nasal errors

[ThorstenB]

On 27.03.2011 13:48, HB-GRAL wrote:
> I get an error in /Nasal/fuel.nas with current fgdata git:

Time to update fg/next. You're probably missing this commit:
http://www.gitorious.org/fg/flightgear/commit/0114fd962e7450b080e580fe67414ca43cd99bd7

cheers,
Thorsten

--
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Stuttering at 1 Hz rate

[ThorstenB]

Hi,

here's a "few" more comments/hints/warnings on Nasal and simulation
performance in general.

First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples (absolutely
including ThorstenIR's local weather, since he brought that up).

I'm just making a point here that the Nasal engine does have
performance issues, which we should be aware of and care about.

When evaluating simulation performance, don't get fooled by the frame
rate. What's really important to us is the "worst case frame latency".
Even if the system is producing a huge average of 100 frames per
second, it can still look absolutely crappy, if only a single frame
took more than 20-30ms, since that's immediately visible to the human
eye (note to self: add a "worst case latency" indicator). So, we're
building a real-time system here, and 20-30ms is our timing
constraint.

Nasal needs to run a garbage collection every now and then. This means
an extra delay, and may become noticeable, if it causes a frame to
violate the timing constraint. _When_ and _where_ in the Nasal code
the g/c triggers, is almost random, so you cannot attribute the g/c
delay to the point where it happened.

The effect depends on two properties: (1) how long does it take, and
(2) how often does it happen. These issues are triggered by different
properties of the code. If we can keep the delay below the limit,
everything is perfect. If we cannot, than we should at least reduce
its frequency. One stutter per minute may be acceptable. Once every
second looks absolutely intolerable (though you may still get a funky
100fps indication!).

1. The length of the delay depends on the number of references the
garbage collector needs to traverse: variables (data), but also
functions, which are just like variables in Nasal, e.g.
  var myVariable = 42;
  var myFunction = func()...
It doesn't depend on the size of a particular function or basic
variable though. The garbage collector needs to look and follow every
single reference to find out what's still in use. The delay is
proportional to the number of elements which were
loaded/initialized/created in Nasal. It hardly depends on the
length/complexity/frequency of Nasal computation though, since the
average number of references usually won't change too much.

I have instrumented the Nasal g/c to show the number of references
caused by generic Nasal scripts and by different aircraft (subtracting
the references caused by generic scripts) with current GIT:

39128   all generic stuff (i.e. fgdata/Nasal...)
 3475   UFO
 4788   c172p
 6007   SenecaII
 8283   B777-200ER
19270   F14
86122   Concorde

So, for most aircraft, the a/c specific Nasal is negligible. Time
consumed by garbage collection almost depends on generic stuff alone
(40K of references traversed in each run). Only some complex aircraft
significantly influence the g/c performance themselves, e.g. the
Concorde. It's ok if advanced models require advanced CPUs. But it's
not so nice with generic stuff, since it affects everyone and every
aircraft.
Currently, we load all fgdata/Nasal/*.nas at startup. Whether the code
is ever used or not, or a particular feature is disabled, doesn't
matter much. It's loaded and initialized, increases the number of
references, thus delays the g/c.
For the test above, I had _disabled_ multiplayer/wildfire/target
tracking/local weather/redout. The numbers hardly change when enabling
features though.

Since the local weather topic was mentioned: yes, it's large, but only
responsible for about 11K of references, so about 1/4 of current
generic Nasal stuff (when disabled).

2) The g/c frequency mainly depends on how much stuff is done in
Nasal, including the number of timers and the timer frequencies. So,
in contrast to (1), this very much depends on enabled features, and
strongly on specific aircraft (see Robert's email on frequency).
I also added instrumentation here to see how our generic stuff is
doing. There's several timers which run at full frame rate, even when
the related feature is disabled:

fgdata/Nasal/mp_broadcast.nas:146
fgdata/Nasal/redout.nas:93
fgdata/Nasal/wildfire.nas:506
fgdata/Nasal/track_target.nas:194

Even when they're almost doing nothing, it'd still help if they were
stopped or at least slowed down, when the related feature was
disabled. They affect garbage collection since a lot of (useless)
contexts are created and need to be cleared at some point - hence
triggering the g/c more often than necessary.

Typically many of our Nasal timer handlers look like this:
myTimer = func() {
  if (getprop("/foo/feature/enabled"))
  {
 ...
  }
  settimer(myTimer, 0.0); // run again in next update loop
}

This would already improve things (20-100 times fewer contexts being
created/removed):
myTimer = func() {
  if (getprop("/foo/feature/enabled"))
  {
 ...
  

Re: [Flightgear-devel] Replay system

[ThorstenB]

On 31.03.2011 17:01, Robert wrote:
> Hi everyone,
>
> I'd like to share some thoughts with you on how we can improve the 
> replay system.
> Right now only the last minute is recorded at full precision. After 
> that minute we get a precision of 1 fps. And after 10 minutes we get a 
> precision of 1 frame per 10 seconds (please correct me. this number 
> may be wrong).
>
> FIRST SOLUTION:
> Streaming the replay data to the hard disc drive always at full precision.
Streaming data to disc would be nice - but should be optional and not be 
enabled by default. It would also be nice to have an option to save a 
recorded instant replay buffer (when you haven't enabled the 
stream-to-disc feature earlier).

I can't comment on the different interpolation methods. But what would 
also help is to change the recording scheme:
Currently the valuesof a fixed set of properties is recorded at each 
frame. However, most properties rarely change. Only the a/c position and 
speed properties tend to change in every frame. Properties like gear 
position and control surfaces are almost constant (from frame to frame). 
So, it might be a good idea to record all properties in an interval of a 
few seconds only, while only recording properties that have actually 
changed with every frame. That should allow to drastically reduce the 
amount of recorded data - and allow much longer high resolution memory 
recordings. And you could still fast-forward within the buffer, since 
you'll have a complete set of properties every now and then. It's a 
simple but effective compression method which is used in many areas.

It would also be nice to support recording of custom properties. We 
already have a similar solution for multiplayer mode. If the replay 
system recorded the same properties configured in the "aircraft-set.xml" 
(the "generic" int/float/string properties), it would mean a nice 
improvement. It would also have other advantages, such as allowing 
simple tests of an aircraft's multiplayer configuration.

> p.s. I also thought that it woud be nice if the nearest tower would be 
> automatically computed in replays (as it is done in x-plane), so you 
> don't have to enter the airport code every time.
Indeed. That feature would also be nice for "normal flight". I never 
understood why the tower view sticks to the initial airport. Switching 
to the "departure airport's tower view" doesn't make much sense after a 
long distance flight. A general "use nearest tower" option would be nice.

I don't think anyone is working in these areas right now. So if you are 
(or anyone else is) interested on working on these, let us know.

cheers,
Thorsten


--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Nasal submodules / folders and optional loading

[ThorstenB]

Hi,

I've pushed an improvement to our Nasal script loading process. Should
help with some of the issues we recently discussed.

1. Nasal scripts can now be grouped into submodules stored in separate
folders (fgdata/Nasal/MyModule/*.nas). This has several advantages:

- Better structure. Things like multiplayer, local weather, ... are no
longer mixed-up in a single directory.

- Better sequence. The Nasal scripts within a directory are loaded in
random order. As soon as a script relied on other (basic) scripts, you
had to delay initialization, to be sure all dependencies are
available. The new subfolders are loaded after the base directory, and
all the basic scripts remain in the Nasal root directory. So,
submodules can now rely on all the basic stuff (like props.nas,
math.nas, debug.nas, gui.nas, ...) to be already present, and don't
need to delay anything with timers/listeners - at least not just to
resolve dependencies.

2. The submodules are also visible in the property tree below
"/nasal". There are properties showing which modules are available and
which are loaded. There's also a persistent "enable"-flag for each
module, so loading specific modules can be optional now. We could add
a generic GUI to enable/disable specific addons. Loading can also be
controlled automatically. I've tested loading the multiplayer scripts
depending on whether the multiplayer feature is actually enabled.
Specific GUIs are also possible of course (such as a loading switch in
the local weather GUI).

Currently all module loading is done in the start-up phase. But we
could easily add listeners to the modules' "enable"-flags though, so
that they can be loaded any time - even if they were disabled during
start-up (without restarting fgfs).

Not loading unnecessary Nasal scripts has performance advantages (see
our lengthy 1Hz stutter / garbage collector discussion). Of course,
performance improvements would be even higher in the first place, when
more bulky/complex things were implemented in... well, I guess that
point was pretty clear now...

This is the relevant commit:
http://www.gitorious.org/fg/flightgear/commit/298f832d4313cdba882ca5a398efdbc7a3599789

Comments welcome. If there are no objections, I'll update fgdata/Nasal
shortly, moving some initial modules to separate folders. I've tested
this locally with the multiplayer, local weather, wildfire and ATC
chatter scripts.

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)

[ThorstenB]

 On 30.03.2011 08:31, thorsten.i.r...@jyu.fi wrote:

How do arrays and objects count? If an object counts as one reference,
then it's very efficient to use I guess - if every key in the hash counts
as one, then certainly less so.

 Right. I believe arrays and hashs may both be implemented efficiently - so
may count as one Nasal object only. But I haven't looked into the details of
the Nasal engine itself - I just checked the discussed performance issues
and briefly looked at the garbage collector. I'm sure Andy would know all
the tricks and details, of how efficient specific constructs are :).

Can loops pile up garbage checks only for elements referenced
(theoretically) within the loop (regardless if they are actually
executed), or do they trigger the whole possible pile of Nasal to be
searched? So if someone fixes a badly written script which runs every
frame although it really doesn't need to - will that affect the load
generated by that particular script, or will it have a more general
effect?

 Garbage collection is a global thing and cannot be restricted to a local
context. It always requires a complete search. Even if "usless" handlers are
executing, eventually their repeated execution will also trigger the garbage
collector, which then needs to recurse through all references. The load
(delay) caused by the garbage collector will hit a random Nasal line, which
happened to be running out of "certain resources". Again, Andy would
probably know the details of what exactly the conditions for triggering the
garbage collector are, and what kind of operations consume these resources -
so make the g/c happen more often.

However, I have attached a simple patch which I used to generate the
statistics. So, if you're interested in optimizing the performance of your
module, apply this locally and see how the numbers and the g/c frequency are
influenced by specific changes. You'll see how many unique objects were
found, how many references had to be searched (which is what consumes most
of the time, since every reference has to be traversed), and of course
when/how often the garbage collector runs.

cheers,
Thorsten
diff --git a/simgear/nasal/gc.c b/simgear/nasal/gc.c
--- a/simgear/nasal/gc.c
+++ b/simgear/nasal/gc.c
@@ -1,9 +1,16 @@
+#define NASAL_GC_STATISTICS
+
 #include "nasal.h"
 #include "data.h"
 #include "code.h"
 
 #define MIN_BLOCK_SIZE 32
 
+#ifdef NASAL_GC_STATISTICS
+static int g_ObjectCount = 0;
+static int g_RefCount = 0;
+#endif
+
 static void reap(struct naPool* p);
 static void mark(naRef r);
 
@@ -37,6 +44,11 @@ static void garbageCollect()
 {
 int i;
 struct Context* c;
+#ifdef NASAL_GC_STATISTICS
+g_ObjectCount = 0;
+g_RefCount = 0;
+#endif
+
 globals->allocCount = 0;
 c = globals->allContexts;
 while(c) {
@@ -74,6 +86,11 @@ static void garbageCollect()
 globals->deadBlocks = naAlloc(sizeof(void*) * globals->deadsz);
 }
 globals->needGC = 0;
+
+#ifdef NASAL_GC_STATISTICS
+printf(" Nasal garbage collection statistics: objects: %u, references: %u\n",
+g_ObjectCount,g_RefCount);
+#endif
 }
 
 void naModLock()
@@ -226,11 +243,21 @@ static void mark(naRef r)
 {
 int i;
 
+#ifdef NASAL_GC_STATISTICS
+// count every traversed reference
+g_RefCount++;
+#endif
+
 if(IS_NUM(r) || IS_NIL(r))
 return;
 
 if(PTR(r).obj->mark == 1)
 return;
+
+#ifdef NASAL_GC_STATISTICS
+// count unique objects
+g_ObjectCount++;
+#endif
 
 PTR(r).obj->mark = 1;
 switch(PTR(r).obj->type) {

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Replay system

[ThorstenB]

On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson  wrote:

>> So, it might be a good idea to record all properties in an interval of a
>> few seconds only, while only recording properties that have actually
>> changed with every frame. That should allow to drastically reduce the
>> amount of recorded data - and allow much longer high resolution memory
>> recordings. And you could still fast-forward within the buffer, since
>> you'll have a complete set of properties every now and then. It's a
>> simple but effective compression method which is used in many areas.
>
> Pluses and minus to every approach ... determining if a property has changed
> by enough of a threshold amount to log the change would be extra work and
> could also complicate the playback, so that would have to be balanced
> against the potential pay off.  When you get away from a fixed record
> format, then you need a way to identify/tag each data value along with a
> corresponding time stamp, so you have to give some of the space savings back
> ... and I would imagine to do this efficiently (space and time) could lead
> to some pretty complicated errr sophisticated logging code.  I'm not saying
> that's bad, but this is a pretty complicated proposal I think when you start
> digging into the details.

In fact, frames of tagged values is the same method we're already
using in encoding data for multiplayer transmission. Though that
module could also do with some improvements (*yikes* it's currently
packing each 8bit string character into a 32bit value for
transmission). Also, it doesn't reduce traffic by detecting unchanged
values yet (UDP transmissions loose some data, so that's more tricky
here, though also not impossible).

Yes, the tags are additional overhead. But I'm quite convinced that
this schemes outweighs the disadvantage - if we used this to encode
changing values only. I checked our current recording data structure:
it has a huge size of 1160 bytes for every frame. Also, the fixed
structure needs to reserve space for the maximum number of
wheels/engines/tanks etc - so even if an a/c has fewer tanks/.., it
still uses up the space. And it doesn't work for aircraft which
somehow exceed the default (btw, I saw a maximum of 4 tanks and 3
wheels is configured, so that is why there are gear replay issues with
4 or 5-gear aircraft, like the Concorde...). And looking at many of
the recorded properties, I think many of them indeed will hardly ever
change from frame to frame, so this 1K structure could probably be
reduced significantly - despite extra tagging bytes.

Thinking about it, it should also be possible to join some of the
multiplayer and replay code. The replay system could use the existing
encoder of the multiplay manager to generate the data packets - but
then record them locally instead of transmitting them via UDP. During
replay, these packets could then also be decoded by existing
multiplayer code. Might be worth a thought, if someone wanted to dig
in this area.

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Generic Protocol Input - Float weirdness

[ThorstenB]

> Every standby-mhz value Arduino is sending has been previously formatted so 
> that it has at most three decimals, something like that: 139.775 or 129.675.
> Problem is FGFS shows /instrumentation/comm/frequencies/standby-mhz as 
> 139.7749939 or 129.6750031. There's something wrong with that and I have no 
> idea what it is. It looks like FGFS is receiving 139.775 and stores it as 
> 139.7749939 (some float rounding up) ... but why? Suggestions?
It's an issue with the finite precision of floating point variables. 
Everyone is suprised when first seeing this. Only values which happen to 
be a sum of "binary fractions" (e.g. 1/2 + 1/4 + 1/8) can be represented 
accurately. Everything else, even simple _decimal_ values such as "0.1" 
or "0.775" cannot be represented exactly in _binary_. Usually this 
doesn't matter, since when you print a value to screen - or to a string 
buffer, you'll limit the precision. Something like 0.7749998175 will be 
printed as "0.775" if you limit to 3 digits. Obviously the property 
browser doesn't limit to 3 digits, but shows more, hence you see a 
difference.

See here:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Also, the properties use double floating points (64bit). You're protocol 
uses float (32bit) - so you loose some precision, which makes the effect 
slightly worse.

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] OSG caching (was: Texture cache)

[ThorstenB]

>>> Maybe someone could do some tests when changing the setting
>>> >>  (SGPagedLOD.hxx:56) from "CACHE_NONE" to "CACHE_IMAGES" or even to
>>> >>  "CACHE_ALL" (then recompile/install sg+fg). Would be interesting to know
>>> >>  how this changed loading times, run-time fps and memory consumption.
> After 30 minutes more of testing: It also works in practice. I have seen
> no averse side effects, and the performance drop from loading new clouds
> is now almost completely gone - the framerate drops I still see are mainly
> associated with terrain sampling.
>
> The actual rendering performance is, as far as I can see, not changed,
> i.e. once everything is there, it is there. But all in all this makes
> things way smoother. It should be most pronounced on single CPU machines.
I've also been using CACHE_ALL since then - not seeing any problems. But 
I haven't checked memory consumption. So, what's the status about the 
OSG caching options, should we enable these? Tim?

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

On 03.04.2011 16:18, Torsten Dreyer wrote:
> Me, too. I had a few coredumps with the 4-nvidia-cards, 8 monitors
> (multithreading=automatic) setup since I had that enabled. I was not able to
> backtrace and blame it to the CACHING-Option, however. So this might just be a
> random correlation.
In fact I haven't seen any crash for a very long time now (yay!). But 
I'm not using multi-threading, as that never worked for me. FG starts, 
but the scenery doesn't look right: the surface is all black and many 
models are only visible partially. Does this work for everyone else - 
maybe depends on newer OSG versions (>2.9.x)?

> How about checking a /sim/rendering/cache property at startup?
Good idea. I'll be adding this and enable it by default. Let's see if we 
get any user reports... (of course I'm thinking about the "usual" 
thank-you-messages from people being extremely happy with the 
improvements :) ).

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Generic Protocol Input - Float weirdness

[ThorstenB]

Roberto,

> though on the wire I send precisely 7 digit numbers: 3 digits
> followed by a dot and 3 decimal digits);
As you describe correctly, you're transmitting strings (= series of
ASCII characters).

>>> int
For an input protocol this is the _target_ type. With "int" your
_string_ is parsed and converted to an _integer_. No fractions.

Keep sending strings representing integers (no dot "." characters in
the string) but specify the _target_ "double", using
offset/factors as described by Torsten. FlightGear will then parse
your string, convert it to double precision floating point, and apply
factors and offset.

Make sure you're using FlightGear 2.2-pre-release or the current GIT
version to achieve double precision. FG2.0/1,9.x only supported single
precision with the generic protocol, so there was no difference
between "float" and "double".

This is the commit which made double precision work for the generic
protocol, and it was not part of FG2.0 yet:
http://www.gitorious.org/fg/flightgear/commit/d0f6f748ed7a2ad34159e18d352e4df6c11e2cde

cheers,
Thorsten

--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself; 
WebMatrix provides all the features you need to develop and 
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..simgear(?) link error, undefined references to SGPagedLOD

[ThorstenB]

On 10.04.2011 13:29, Geoff McLane wrote:

> As far as I am aware we can _NOT_ presently use
> later that OSG-2.9.9 ;=((
Yes, we can. But 2.8.3 + 2.9.9 are used by the automatic "download & 
compile" script, since these versions are known to work fine. And as we 
noticed, we have a lot of people running the FG git version right now, 
not all of them are actually FG developers or even familiar with 
building their own binaries (which is why the build script is there in 
the first place). So, it's good to have something that's stable and 
known to work for them.

> On a general note, I would ask are there any thoughts to
> modify simgear to use later, or even the trunk versions
> of OSG?
It always takes some days to adapt sg/fg to OSG changes, but right now, 
it compiles just fine, as the Hudson builds show: 
http://flightgear.simpits.org:8080/job/Simgear-with-OSG-svn/

I wouldn't recommend using OSG trunk to any "normally advanced" 
flightgear git user. Those who need it know what to do - and won't be 
using the convenience "download&compile" script anyway.

cheers,
Thorsten

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] ..simgear(?) link error, undefined references to SGPagedLOD

[ThorstenB]

On 10.04.2011 15:02, Geoff McLane wrote:
> On Sun, 2011-04-10 at 14:34 +0200, ThorstenB wrote:
>>> As far as I am aware we can _NOT_ presently use
>>> later that OSG-2.9.9 ;=((
>> Yes, we can.
> Huh? Then WHY does Arnt have a LINK problem with OSG-2.9.11?
I don't know. The error Arndt is seeing is a _linker_ error - not a 
compile error. Csaba has already given the reason in his earlier email: 
mismatching OSG header and library files (messed up local installation). 
Another possibility is an incomplete build after changing the OSG 
version (run "make clean" in sg/fg).
In any case, that's not "our" fault. If sg/fg wasn't adapted to the OSG 
version, you would get a _compile_ error - not a linker one.

> Yes, I know it can take 'some days', and no criticism
> is intended, but 2.9.10, the first after 2.9.9 was released
> 3rd December, 2010, and others 2.9.11, etc later... maybe you
> meant 'some MONTHS' ;=))
No.

> Both Brisa's and my script use 2.8.3 or 2.9.9, but have
> a switch for 'trunk', and would code for later if workable...
No. After getting lots of reports and complaints due to OSG-trunk 
issues, we changed the Brisa's script to stop using OSG trunk:
http://www.gitorious.org/fg/fgmeta/blobs/master/download_and_compile.sh

> When you suggest Hudson is using OSG-svn - If _NOT_ trunk
> then exactly which version of OSG-svn is used by Hudson?
"OSG trunk" = "OSG svn". It's compiling (and linking) fine.

cheers,
Thorsten

--
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] download_and_compile.sh script link

[ThorstenB]

On 11.04.2011 17:29, Francesco Angelo Brisa wrote:
> well ,I will make some experiments on 2.9.10  if it finds out to
> compile easly and to be quite stable, I will make it the default
> behaviour, with 2.8.3 as stable option.
When we last discussed this (February), 2.9.9 was reported to be stable 
with FlightGear on all three platforms (Linux/Mac/Windows) with fg/next 
- no issues were reported since. But meanwhile we've updated FlightGear 
to also support the latest OSG interface (>= 2.9.10). Concerning the 
OSGText issue, there is also a bug tracker entry on this:
http://code.google.com/p/flightgear-bugs/issues/detail?id=268
We don't know if OSG 2.9.10 is also affected - or only >= 2.9.11. Would 
be good if someone could verify.

 > > While, as you point out, using OSG-2.8.3 stable will
 > > ALWAYS works, and I know OSG-2.9.9 also works, recent
 > > posts indicate OSG-trunk will _ALSO_ compile, but I have
 > > yet to fully personally 'verify' this... But perhaps this
 > > should be a user 'option' to the script...
Well, OSG-trunk compiles - today. If an option to use OSG-trunk is 
really necessary (is it?), then please hide it well enough so that 
normal users won't find it. :)

cheers,
Thorsten

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

On 13.04.2011 13:46, Frederic Bouvier wrote:
> To reduce memory footprint caused by model caching, I added this code to the
> begining of the main function of fgrun :
>
> osgDB::Registry* registry = osgDB::Registry::instance();
> registry->setExpiryDelay( 0. );
>
> I suspect we can control the amount of caching the same way in FG

The default expiration delay is 10 seconds. Any texture/image/... which 
isn't referenced any longer should automatically be purged after 10 
seconds. Reducing it to 0 shouldn't help too much - just save 10 seconds 
worth of memory. But it would void performance benefits when stuff get's 
dropped and then reloaded immediately, e.g. you do a sim reset or the MP 
connection has a brief drop-out (I sometimes see MP models disappear and 
reappear after a few seconds).

The real problem should be elsewhere:
* either the whole OSG caching system just doesn't work at all, i.e. it 
never purges unreferenced and expired data (I somehow doubt this).
* we somehow haven't implemented the caching thing correctly (no idea 
what we could be missing)
* or it's all our fault, our leak alone - more or less unrelated to caching.

I think the latter is (still) the case. I already posted some weeks ago 
that I was seeing loads of leaked objects. I managed to fix a few things 
at the time

http://www.gitorious.org/fg/simgear/commit/44f27b23d0209d2ee9f508c43def5636564bb302
http://www.gitorious.org/fg/flightgear/commit/4761a3cdcf04771819b3a8de9d018fca20c90ca6
http://www.gitorious.org/fg/flightgear/commit/8962477cfa10850cb459d7de754c9a435cc91293

but that wasn't all of it by far. Still looked "leaky as a sieve" to me 
:| and mainly affected MP models, clouds (global weather based) and SG 
animation stuff - and thousands of properties connected to these. The 
longer FG was running (or the more players joined and left) the more 
objects were leaked. And that was long before we enabled the OSG cache. 
I never ran FG for 6 hours with clouds & MP enabled though. But are we 
sure that the OSG cache itself really made a major difference now?

The thing is that we do have a lot of "automatic pointers" (objects with 
reference counting) in our code. It's all our classes based on OSG and 
all the SGShared... properties/classes. It's very tricky to find out if 
everything is working as expected here, since it's hard to tell when 
something should be removed. A simple mistake somewhere (like a 
non-virtual destructor in a base class), a single object which doesn't 
get disconnected - and a huge object tree connected to it never get's 
removed. It'd certainly be worth to investigate further and fix more 
leaks - but debugging these issues is painful and requires a long and 
tricky hunt. Any help would be appreciated...

cheers,
Thorsten

--
Forrester Wave Report - Recovery time is now measured in hours and minutes
not days. Key insights are discussed in the 2010 Forrester Wave Report as
part of an in-depth evaluation of disaster recovery service providers.
Forrester found the best-in-class provider in terms of services and vision.
Read this report now!  http://p.sf.net/sfu/ibm-webcastpromo
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Joystick axis issues

[ThorstenB]

Hi,

I'm having joystick issues: on start-up, all axis are in 
left-most/lower-most position (reporting "-1"). Only once I have moved 
each axis for the first time, do I get valid positions. Hardly 
noticeable with most planes, since "-1" means throttle is idle - so full 
left-rudder/pushed-aileron has no effect. But starting the UFO is 
annoying, as it's spinning around all three axis at full speed by 
default - until I have moved all joysticks. Wasn't like this maybe a 
month or two ago. And I have tested different joysticks.

Anyone else seeing this? Test: start the UFO, keep away from joysticks, 
see what happens...

I have a local patch which fixes things for me - but I may be fixing 
local/system issues here.

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] release discussion (was: Simple atmospheric scattering shader)

[ThorstenB]

On 14.04.2011 18:22, Curtis Olson wrote:
> Yeah, we should get back to that. What is the current status? I have
> spend a lot of time doing the prepatory work for an eventual release
> during my holiday, but apparently no release has happened during my
> absence. Are there still any showstoppers?
>
>
> I seem to recall James mentioned the a couple issues remained, but I
> don't recall ever hearing specifically what those issues where.  He has
> been buried by real life lately so he hasn't had the chance to jump in
> much lately.  I haven't heard much from Tim either.

The remaining issues James was working on were concerning the automatic 
build process. He was close to finishing and make Hudson provide 
_complete_ (that is including _basic_ fgdata) installers for 
Mac/Windows. There were remaining issues due to the huge size of the 
installers though - since data gets copied over the network. And then he 
got buried under a pile of RL work for a while.

The 2.2 release itself was branched in January (first sg+fg and a few 
weeks later also fgdata). And I think we've fixed all the show stoppers 
for the 2.2 branch. We've had a few more fixes on the "next" branch 
since, but these mainly affected new code issues, which were not yet 
part of 2.2. I think the release branch got a fair amount of testing - 
and is very stable (feels much more stable than 2.0 to me, if I may say 
:) ).

So, as far as I'm concerned, if we can manually provide Mac/Windows 
installers, we could just tag and release now (come on, let's have a new 
release to show off at LinuxTag! :) ).
The 2.2 branch may look a little outdated to git/next users by now. But 
I'd still stick with releasing the existing branch as 2.2. We've already 
committed lot's of new code to "next" since, so that would take more 
work/time to be ready. And we can still have another release (2.3/2.4) 
in a few months - and don't need to wait for another year again...

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] release discussion

[ThorstenB]

On 15.04.2011 01:22, Martin Spott wrote:
> Note that there are a couple of updates/additions (and removals) to the
> Base Package which have, as far a I can tell, not yet been migrated to
> the release branch. At least the stuff Jon Stockill and I have
> committed to the Models/ subdirectory is affected.

Ok, not sure what has changed there, but is it important enough to be 
migrated to 2.2? I know it's tempting to make all the new features 
available right now (I'd like to see my new TCAS in the release, we've 
had 2 JSBSim updates, new HLA support, tank properties, joystick 
reloading, of course many many really nice Aircraft updates...). But 
they are not release-blocking.

Last 2.2.0 fixes were applied on February 19th. I'll have a look at the 
commits on next/master since then. Anyone else aware of missing and 
release-blocking commits apart from the Models subdirectory?

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Valgrind logs

[ThorstenB]

On 15.04.2011 11:11, Andreas Gaeb wrote:
> The input value lists seems to fulfil both conditions (SGSharedPtr
> pointing to SGReferenced), so in theory, automatic deletion should work
> here. Still, valgrind complains. Could the problem here be related to
> calling the componentForge functor?

Remember that SGReferenced does reference counting. In theory, the root 
cause could be completely elsewhere in the code, if there were other 
references to the same "InputValue". If only a single of these 
references wasn't removed, then the actual "InputValue" object is never 
deleted (and let's hope there are no cyclic references anywhere...).

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

On 13.04.2011 22:52, Csaba Halász wrote:
> On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB wrote:
>> I never ran FG for 6 hours with clouds&  MP enabled though. But are we
>> sure that the OSG cache itself really made a major difference now?
>
> Yes, pretty sure. I fly FG during the monthly TGA events, and it was
> never even half as bad as this time. Except for the one massive leak
> you fixed, but luckily I didn't try to run that version during an
> event :)

I looked into OSG's cache behaviour when running FlightGear. Worked as 
expected though: I see the objects being dropped once they are no longer 
referenced and have expired.
However, I saw the same issue which my memory debugger had reported 
before: some scenery elements, mainly related to MP aircraft, don't 
(always) get deleted. Indeed, these elements stick in the OSG cache now. 
But they stick since their reference count proves that they are still 
referenced elsewhere - so the cache holds on to them. It wouldn't help 
to drop referenced objects from the cache - they wouldn't be deleted 
anyway. So, yes, there's a leak related to MP aircraft - but the cause 
seems to be independent of the OSG cache. I'll be doing some more tests 
though.

I've also pushed an update to clear the entire OSG cache when reloading 
scenery (see menu "Debug" => "Reload Scenery"). If memory consumption 
explodes, try triggering a scenery reload to wipe the cache. I doubt 
this would reduce memory though - but maybe there's a surprise.
Csaba, which OSG version are you running anyway?

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] XML formating Was: [Flightgear-commitlogs] FlightGear Base Package branch, master

[ThorstenB]

Mixing spaces and tabs is really ugly - I think cleaning up such a mess is good.
Many people like tabs, but disadvantage is that everyone uses a
different tab settings. Most editors I know use 4 or 8 spaces/tab as
the default. But since it's different for everyone, I personally
prefer spaces - at least for collaborative projects. Guaranteed to be
working for everyone and looks the same with every editor.

cheers,
Thorsten

On Sat, Apr 16, 2011 at 2:24 PM, Heiko Schulz  wrote:
> Well, at least it explains for me the many "whitespace errors" when updating 
> my datas
> To be honest, I'm not happy about this.
> And I never had probelms to read the files.

>> > > Fred wrote
>> > > > Is it wise to reformat preferences.xml with
>> a tab length set to 2 ?
>> > >
>> > > Well, it's better than the current mess of spaces
>> and tabs. At least
>> > > we can now read it.
>> >
>> > *You* can read it with your own MSVC preferences
>>
>> Yes, I know that very well. But I hate a mess - it looks
>> unprofessional. I'd
>> fix up the rest of the mess given half a chance.
>>
>> Vivian

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

Hi,

had another look at memory consumption. The FG multiplayer (=AI)
aircraft classes seem fine - they are created/removed as expected. But
there are problems with some of our OSG-based simgear classes: they
are never removed at run-time - hence memory is eaten up.

Problems start at simgear::Effect. Their parent objects
(simgear::EffectGeode) are still removed when the related model
disappears from the scene graph. But simgear::Effect objects stick in
memory, until exiting FG. Their reference counter shows that there
must be (forgotten) references to each of them somewhere (but they are
no longer members of the scene graph). Attached is a simple patch
logging Effect constructor/destructor calls. Shows that not a single
Effect::~Effect destructor is called at run-time - though we
continuously create new objects. Effect objects own 2D textures
(images), techniques, etc - so they have considerable memory impact.

Any suggestions on how to trace the cause?

New Effect objects are created when new MP aircraft join or new
scenery areas are loaded. So, no surprise there are issues with large
MP events/long distance flights.

Another observation: I started an MP session at KSFO (lots of MP
aircraft), then warped to the middle of nowhere (no MP aircraft).
After about 30min I dumped the scene graph. Surprisingly, loads of
osg::particles were still *in* the scene graph, referring to aircraft
specific smoke and contrail textures. I would have expected them to be
dropped from the scene graph after some time - or when we move to a
very distant position. Maybe there's another issue.

For me, this is all independent from enabling/disabling the OSG cache.
But maybe it's worse now, since we have more advanced aircraft, making
more use of effects and particles. And I guess the pretty local
weather clouds also make use of these.

cheers,
Thorsten
diff --git a/simgear/scene/material/Effect.cxx b/simgear/scene/material/Effect.cxx
index 6517bd2..314d131 100644
--- a/simgear/scene/material/Effect.cxx
+++ b/simgear/scene/material/Effect.cxx
@@ -83,15 +83,19 @@ using namespace osgUtil;
 
 using namespace effect;
 
+static unsigned long EffectCount=0;
+
 Effect::Effect()
 : _cache(0), _isRealized(false)
 {
+printf("%4lu Effect::Effect()\n",++EffectCount);
 }
 
 Effect::Effect(const Effect& rhs, const CopyOp& copyop)
 : root(rhs.root), parametersProp(rhs.parametersProp), _cache(0),
   _isRealized(rhs._isRealized)
 {
+printf("%4lu Effect::Effect(..)\n",++EffectCount);
 typedef vector > TechniqueList;
 for (TechniqueList::const_iterator itr = rhs.techniques.begin(),
  end = rhs.techniques.end();
@@ -149,6 +153,7 @@ void Effect::releaseGLObjects(osg::State* state) const
 
 Effect::~Effect()
 {
+printf("%4lu Effect::~Effect(..)\n",--EffectCount);
 delete _cache;
 }
 
--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] release discussion

[ThorstenB]

On 15.04.2011 22:22, Bertrand Coconnier wrote:
> Yes, a bug fix has been committed to fix instant replay with JSBSim
> aircraft (bug #294)
> https://gitorious.org/fg/flightgear/commit/11320e6b008eb85b8dff66a137f671743cc04580
>
> I think it should be applied to 2.2.0 as well.

Ok, thanks Betrand! That would also be on the list.
But we should decide first if and when we're going to have a release
(well, do we want one at all? :) ). No use to spend more time on the
branch, if we're not going to use it.

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] props protocol problem

[ThorstenB]

On 16.04.2011 02:06, Pascal J. Bourguignon wrote:
> The props data protocol ls command has a problem: there's no way to
> determine that its output is complete (unless we use a timer, which
> would mean that all ls commands would suspend the client for the time out
> duration).
>
> I'm proposing to add a lsx command, similar to ls, but that will
> terminate its output with an empty line.

Hi Pascal,
before we duplicate commands: couldn't you detect output completion by 
reading until the prompt? When output is complete, the server prints a 
linefeed ("\n") and a "/" (followed by an optional property path and 
">"). Should be easy to parse.
Ok, the prompt is only printed in PROMPT mode (obviously). There is no 
prompt in RAW mode. But then it might be better to add another output 
mode, i.e. a mode similar to RAW which completes _every_ existing 
command with a specific character sequence, such as an additional 
linefeed. Adding another command ("lsx") wouldn't cost much - but then 
we should also add new versions of all other commands ("getx", "dumpx", 
"runx", ...) for the same reason.

So, a different output mode seems a better solution? Or also possible: 
just add a new option to configure the prompt in PROMPT mode. So 
everyone can configure this to his needs.
To see what I mean, try
export PS1="FOO\nBAR\n"
in your linux console - or
set prompt="#FOOBAR#"
in your Win-DOS box.
Might be a better solution if you added something similar to props.cxx. 
Any other thoughts?

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

On 16.04.2011 16:24, Anders Gidenstam wrote:
> On Sat, 16 Apr 2011, Anders Gidenstam wrote:
>
> Hmm.. I should have added that I looked at this in early September last
> year so it is not fresh in my memory.
>
> IIRC the current code already does the fundamentaly unsafe operation of
> adding items to a STL vector (in the loader thread) while concurrent
> traversals of the same vector are possible (by various parts of OSG
> rendering). That is NOT SAFE but a lot less risky than deleting from an
> STL vector with concurrent traversal (consider the most likely internal
> representation of a STL vector to see why).
Ok, thanks a lot Anders for these hints! I'll open a tracker issue for 
the particle issue - so we won't forget these details. Can you estimate 
on how bad this issue could get? Does it only mean a minor memory leak - 
or could it get really bad over time (maybe eat some gigabytes in a 6 
hour TGA shift? :) ).

Not sure, but I guess the issues with "Effect" objects is probably worse 
than with particles. There's a larger number of Effect objects - and 
each is connected to a texture (.rgb/.png images) - which may occupy a 
lot of memory. Just by starting at KSFO, loads of KSFO terminal textures 
- and textures of 15 different MP aircraft immediately stick in memory...

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] OSG caching

[ThorstenB]

On 16.04.2011 21:16, Anders Gidenstam wrote:
> If I'm not mistaken the particles issue has been around since we got
> particles, so it is apparently not that bad (leak and race
> condition) in practice.
Ok, thanks! I've create a bug issue as a reminder, in case someone else 
noticed the issue some day.
http://code.google.com/p/flightgear-bugs/issues/detail?id=305

>> Not sure, but I guess the issues with "Effect" objects is probably worse
>> than with particles. There's a larger number of Effect objects - and
>> each is connected to a texture (.rgb/.png images) - which may occupy a
>> lot of memory. Just by starting at KSFO, loads of KSFO terminal textures
>> - and textures of 15 different MP aircraft immediately stick in memory...
> Yes, the big textures will eat memory fast. Particle systems usually use
> small textures (the effect of the accumulation of particle system updaters
> is noticeable with wildfire, though - but you'd need a lot of MP aircraft
> passing through to generate anywhere near those numbers of particle
> systems).
The effect/texture "mystery" is also solved - alas - explained. There is 
a global cache in simgear/makeEffect.cxx (effectMap), and it has no 
condition to ever drop anything. So, created effects always stay in 
memory until shutdown - hence also their textures. If that's used for 
scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim 
might know more about this :).

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YASim issues

[ThorstenB]

On 18.04.2011 14:51, Adrian Musceac wrote:
> On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote:
>> I had a fix locally but with the patch fixing the YASim issue I have now to
>> begin again. I see the problem in the airfoil, but a change to this means
>> that I have to change a lot of other parameters as well to keep the
>> behavior 100% correct. Means a lot of tuning
> I took a quick look inside the FDM file. Unless your version is significantly
> different than mine, this patch should not affect the behaviour. There is no
> mention of cruise glide angle or approach and cruise fuel levels inside the
> file.
> The defaults provided inside FGFDM.cpp are the same as those that were
> previously hardcoded in Airplane.cpp. Maybe the problem is not at all related
> to this change?

And you also checked that approach glide angle isn't used? Otherwise, 
the new default cruise angle (0.0) might not match the original approach 
angle setting...

Anyway, we've committed the patch since it was assumed to not cause 
major differences. These bugs have been there since the beginning of 
YASim - so for 10+ years.
If it's confirmed that the patch actually caused major differences, then 
we should "improve" the patch. We could restore the old "buggy" 
behaviour by default and only use the new "correct" FDM configuration 
behaviour for new FDMs, e.g. add a switch, such as a new FDM parameter 
or YASim FDM version number in the xml file to enable the bugfix.

Heiko, and anyone else: if you think there is a major change, then 
directly compare the FDM behaviour with and without the patch - and let 
us know if there was trouble.

And that's the relevant patch:
http://www.gitorious.org/fg/flightgear/commit/7f5a0e35184677c21f1eafdfbe6438eb644cdbff

cheers,
Thorsten

--
Benefiting from Server Virtualization: Beyond Initial Workload 
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve 
application availability and disaster protection. Learn more about boosting 
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] crash sort of related to sound on exit

[ThorstenB]

On 03.05.2011 17:05, Curtis Olson wrote:
> My git build here recently started crashing on exit again.  I've been
> looking into it and I think I traced it to
> simgear/environment/visual_enviro.cxx in the destructor around line
> #190.  This module builds up sound effects for thunder/lighting,  in a
> "weather" sample group.  The module keeps a pointer to the sample group
> and then tries to delete it in the destructor.
Really weird. Are you running pure GIT - or also some local 
enhancements? The sampleGroup pointer is always NULL on my system - and 
it seems we currently don't even create a "weather" sample group 
anywhere in the current code. So, *possibly* the root cause of your 
issues could be completely elsewhere (such as memory corruption issue 
overwriting the "sampleGroup" variable...).
Also, "sampleGroup" isn't even used within the visual_enviro module - so 
we could probably even drop the pointer from the sources.

> Anyway, would it be safe to remove this call to delete in the
> visual_enviro.cxx destructor and depend on the sound manager destructor
> to clean it up?  Or should we try to do something fancier?
If "sampleGroup" was used, then it indeed should _not_ be removed in the 
~SGEnviro. The SGEnviro object doesn't create the object itself - it's 
just given a pointer to an object from the outside. And such object 
would/should be owned by the sound manager. So, I think it's a good idea 
to remove the "if (samplegroup) delete ..." line in any case.

cheers,
Thorsten

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] crash sort of related to sound on exit

[ThorstenB]

On 03.05.2011 19:42, Curtis Olson wrote:
> The code seems pretty definite that it would execute here, so it's odd
> that you are getting NULL there ... unless the sgmgr->find() call is
> returning null for you?  Or if like you say, somehow our source trees
> have diverged.  But I do think I'm 100% current with git.
Ha. I hadn't pulled the latest GIT update for wind-moving-clouds yet. 
fgclouds->init() was never called in earlier GIT versions, so indeed 
sampleGroup was always NULL so far. That changed with the recent FG 3D 
cloud update - hence the sampleGroup issue appeared. So, it's good 
you've found/fixed this.

cheers,
Thorsten

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] OSG caching and other OSG issues

[ThorstenB]

On Mon, Apr 18, 2011 at 9:55 AM, Tim Moore  wrote:
> On Sun, Apr 17, 2011 at 6:10 PM, ThorstenB  wrote:
>> There is
>> a global cache in simgear/makeEffect.cxx (effectMap), and it has no
>> condition to ever drop anything. So, created effects always stay in
>> memory until shutdown - hence also their textures. If that's used for
>> scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim
>> might know more about this :).
>
> It seemed like a good idea at the time :)
>
> The Effect cache could be changed to use osg::observer_ptr, which is a
> weak pointer.

Good idea. Here's a patch using observers instead of references for
caching. Puts some live into the effect/texture destructors - so these
can finally free up some memory once the objects are no longer used
anywhere:
http://www.gitorious.org/~thorsten/fg/thorstenbs-simgear/commit/71d14629076b3a56c40cc0309b42b3a22d579bec

Patch is in my local branch (not in next). Any comments?

It indeed improves memory consumption when switching (or flying :) )
between airports. However, I'm still seeing memory growth/leaks (and
I'm really starting to dislike all these "smart" auto pointers -
searching the last reference causing an object to leak, is a really
annoying job...).

I also noticed a bad leak in older OSG versions - including the stable
release (2.8.3). It's fixed by now (OSG svn), but I haven't checked
for which version it was fixed first. However, we've lost 3D cloud
support with latest OSG trunk (not a single 3D cloud visible,
everything fine with recent OSG devel releases though). Might be
temporary OSG trunk issue... Also, osgText still isn't working for us
with latest trunk (see
http://code.google.com/p/flightgear-bugs/issues/detail?id=268 ). There
were several fixes and updates to osgText just before we started
seeing the issues. Since it still isn't fixed on the OSG side, it
might also be our problem after all: maybe we're relying on an old
osgText bug - or we need to adapt something. We'll probably need to
look into this...

cheers,
Thorsten

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Who turned the sun off?

[ThorstenB]

On 07.05.2011 10:20, Alan Teeder wrote:
> Ever since the atmospheric scatter patches went in I have had black sky,
> instead of blue.
>
> If I turn on material shaders, then there is a small area of blue close
> to the horizon, but that is the best I an achieve.
>
> The attached is from my TSR2 cockpit with shaders off.

Which OSG revision? Saw the same effect when I experimented with latest 
OSG trunk last week. Sky turned black when attempting to render fog. 
Since there were also other issues (text display and clouds not working) 
I reverted back to OSG 2.9.9. Not seeing any issues now.

cheers,
Thorsten

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] YASim issues

[ThorstenB]

On 18.04.2011 23:13, Maik Justus wrote:
> By the way: I would prefer to use the old default values for the gear
> solver. The spring constants of a gear should not be a function of the
> approach fuel settings. Maybe some gears would need some tuning with the
> patch otherwise. The
> _approachWeight = _emptyWeight + totalFuel*_approachFuel;
> should be moved behind the gear solver call.

What's the status here, do we want to change this? Would anyone provide 
a patch?

cheers,
Thorsten

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] keepingup with OSG(was Who turned the sun off?)

[ThorstenB]

On 10.05.2011 10:36, Alan Teeder wrote:
> How is FG going to progress if it is stuck in a time warp with an old
> version of its key graphics library?
> Are  the FG code developers liasing with their OSG counterparts, especially
> in the area of backwards compatibility?
First of all, 2.9.x are OSG developer releases (unstable). The stable 
OSG release was 2.8.3 for a long time - now there's 2.8.4 (since April). 
I'm not aware of major issues concerning stable OSG.

We're checking "compile-compatibility" against OSG trunk regularly 
(automatic Hudson build). When necessary, we're adapting to OSG changes 
- though that will take a few weeks. Sometimes bugs are also introduced 
on the OSG-side - like
http://code.google.com/p/flightgear-bugs/issues/detail?id=268
Incidentally, I have just invested a lot of time this weekend, tracing 
the specific OSG commit causing the problem and debugging it. The 
problem is now identified (OSG forgot to update one of their font 
plugins) and thankfully the OSG maintainer is now looking into this. 
There's also a temporary patch in our tracker.

If the black sky issue persists for some time (i.e. OSG isn't fixing the 
issue themselves - which they often do, since most bugs aren't 
FlightGear-specific and there are a lot of active OSG devs/testers), 
then someone of us will also need to look into this.

So, we're not "stuck in a time warp" just because there are occasional 
OSG issues. But it's tiring to be a constant OSG beta-tester. Seems we 
have enough own issues to take care of. Anyone volunteering though is 
welcome to test OSG trunk regularly, check for new issues, trace 
conflicting changes and report problems - preferably on a level which 
can be reported to OSG directly.

Indeed, I guess Tim would be happy for any help in maintaining the 
FG/OSG code. And remember: you're not getting any new features just by 
installing a fancy new OSG library. We'd also need someone to add new 
code to FG in order to take advantage of available OSG features.

cheers,
Thorsten

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] A proposal for a Nasal based Honeywell/Boeing-style CDU for FG

[ThorstenB]

Hi Claus,

adding support for more complex cockpit instruments, like the CDU, 
indeed sounds very exciting! And I think we have a lot of users here who 
enjoy advanced and realistic cockpits. So any help in this area is 
highly welcome!

I'll hopefully find some time during the next days to test and look at 
your CDU. The only thing which generally concerns me about larger Nasal 
additions are some unresolved performance issues. Will be interesting to 
see what impact the new CDU module has.

Anyway, performance issues might also be topic for the next few days at 
LinuxTag. I hope to see a lot of active FGers in Berlin.
Anyone else: don't forget, it starts tomorrow/today - and a visit is 
worth it:
http://www.flightgear.org/forums/viewtopic.php?f=42&t=11881

cheers,
Thorsten

On 09.05.2011 23:50, Claus Christmann wrote:
> Good Day everybody,
>
> first of all, let me introduce myself:  My name is Claus, I am an aerospace
> student at GeorgiaTech and recently got into FlightGear in relation to one of
> my research projects. I have been not so good on reading the FG-devel email
> list, but have had quite some interactions on the FG IRC chat with other FG
> enthusiasts.
>
> For my research project I need(ed) a somewhat functional Boeing style CDU.
> So I got into contact with Gijs de Roy and started to learn about his CDU
> project, then still in this git repo for the 744.
>
> I started to make a wiki writeup for Gijs CDU
> (http://wiki.flightgear.org/Howto:_Development_of_the_CDU, not up to date
> anymore) to learn about how Gijs implemented the CDU.
>
> As I needed the CDU to be fairly "flexible" - particularly in respect to [ages
> outside the currently implementation - I decided to change from a XML approach
> to a more Nasal based approach.
>
> I have finished a first draft of my code and started to write some
> documentation for it in the FG wiki.
>
> I would like to ask for some dev's to check out my code and make any
> suggestions for improvements. As I have the clearance to release the code
> under GPL v2, I also would like to offer to merge this into the main FG
> repository.
>
> You can find my code at
> https://gitorious.org/~hcc23/fg/hcc23s-fgdata/commits/cdu-development
>
> The docu is contained in these two wiki pages (and will be expanded)
> http://wiki.flightgear.org/Nasal_CDU_Framework
> http://wiki.flightgear.org/Howto:_Coding_a_Boeing_CDU
>
> I am very much looking forward to hearing back from you, particularly with
> comments and improvement suggestions.
>
> Regrads,
>
> Claus
>
> PS: for those of you active in IRC, my nick there is hcc23

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Abstract of three days at LinuxTag 2011

[ThorstenB]

Hi,

LinuxTag 2011 is over - here are some more photos on what was going on 
at our booth:
http://img684.imageshack.us/g/00linuxtag1.jpg/

It was fun to meet several FlightGear developers/pilots, and also (and 
I'm pretty sure about it) find a number of future FlightGear pilots :).
A few of them were so enthusiastic that they seemed to keep orbiting 
around our booth all day - waiting for another chance to fly the large 
sim. I'm ready to accept any bet, they've downloaded FlightGear 
_immediately_ once back home.

As Martin already mentioned, our "large" setup worked like a magnet. On 
the last day an exhibitor from a nearby booth (won't name the company) 
actually approached me saying: "Ok, we've had a pretty quiet event here, 
few people at our booth, and we got pretty bored. But we watched your 
booth being busy all the time - this actually made us really jealous...".

We also had a few *I'm-a-pro-Your-GAME-doesn't-challenge-me* visitors 
(Uh oh, did he say "game"?). Well. Our netbooks were always ready to 
secretly telnet into the sim. Surprisingly, their flights were hampered 
by failing instruments, stalled engines or stuck gear (or any 
combination for really hard cases). To me it looked like a challenge to 
all of them eventually.

And we haven't revealed yet how we lost one of our graphics cards: it 
overheated when it's fan blocked. Ironically, the fan had sucked in a 
warranty sticker which somehow had peeled off. Is that covered by 
warranty? (Or is "warranty void if removed"?).

But, to honestly also mention some not so great facts: The FlightGear 
performance on the multi-display setup wasn't too great - though we were 
already using an extremely powerful machine and high end graphics cards. 
We had to disable 3D clouds (even the standard global weather ones) and 
when flying in more complex scenery like at LOWI, we also disabled more 
options, such as random vegetation. And yet, we had individual frames 
with 60-70ms delays - meaning the human eye only got a sloppy 14fps 
impression (actual frame rate was a bit higher but that doesn't help 
when frames aren't evenly distributed). Also, every now and then, the 
entire simulation was freezing for several seconds.
These issues were also noticed by several visitors. Of course, a ten (or 
eight eventually) display setup is a bit extreme. But still, it shows 
that our performance is at the limits and larger screen sizes / 
multi-display setups aren't really supported too well. And the 12 CPU 
cores couldn't really help us (enough) here - due to our current concept 
of using a single main loop to run almost everything. Without 
performance improvements, we will hardly be able to add many more 
features to FG - or we will soon also see issues on smaller machines / 
with "normal" screen counts. Also, new CPUs will rather increase their 
performance by increasing the number of CPU cores - not so much by 
increasing individual core performance. Hoping for new CPUs alone won't 
help much in resolving our current issues. So, there's work to be done.

Anyway, it was a fun event - and, I believe, also a very effective one 
in promoting FlightGear.

cheers,
Thorsten

--
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

Hi,

good and bad news: Robert Osfield (OpenSceneGraph maintainer) kindly 
looked into our OSG text issue and fixed the character spacing problem 
(an issue introduced with osg 2.9.11 causing text to be "scattered" 
across the screen). The actual problem was an update to the osgText 
which also required updated font plugins - and the osg::txf plugin was 
forgotten (which is the font format we're using).

While fixing this issue he also found another bug, which apparently had 
meant that the actual font size of osgText::text wasn't correctly 
matching the specified size. This issue was also fixed.
However, this triggers new issues in FlightGear since font sizes have 
changed: fonts are larger in some places now, and they are a lot smaller 
in other places. Looks strange to me - but apparently that's supposed to 
be the "correct" behaviour now.

We should find out what impact that change has on us. I've found a few 
places where fonts a messed up now, i.e. see:
http://code.google.com/p/flightgear-bugs/issues/detail?id=268#c14

We could ask osg to introduce a switch in order to restore the original 
font size behaviour (to avoid a regression) - but that'd probably be a 
lot of hassle. And I'm not sure they'd really do us the favour.

It be great if a few more people now tested latest osg trunk and report 
places (aircraft) where fonts are messed up now. If I don't get any (or 
very few) reports, I assume that it's not a huge problem for us (we'll 
have to live with it). If there were many reports, I'll try to ask osg 
for another solution.

Also: it seems 3D clouds are broken with current OSG-trunk. Works well 
for me with older OSG versions. Can anyone else confirm the issue?

In order to test all this, you need to use latest OSG-trunk (i.e. 
revision 12419) and be at ease with compiling/rebuilding 
osg/simgear/flightgear.

Thanks,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 18.05.2011 01:42, Csaba Halász wrote:
>>> Also: it seems 3D clouds are broken with current OSG-trunk. Works well
>>> for me with older OSG versions. Can anyone else confirm the issue?
> Downgraded to svn rev 11900, got 3D clouds back. Note, I am not saying
> the breakage occurred there, I just randomly picked that as a testing
> point.

Ok, thanks. We'll probably have to narrow it down to the exact OSG 
commit to see what changed there. If anyone else has a 
working/non-working OSG revision in between 11900 and 12419, you're 
welcome to let us know. Also, maybe someone has an extremely powerful 
machine and could help with testing different OSG revisions.
I've created a tracker issue - you could just post working/non-working 
revisions there:
http://code.google.com/p/flightgear-bugs/issues/detail?id=317

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 18.05.2011 19:29, Csaba Halász wrote:
> On Wed, May 18, 2011 at 8:45 AM, ThorstenB  wrote:
>> working/non-working OSG revision in between 11900 and 12419, you're
>> welcome to let us know. Also, maybe someone has an extremely powerful
>> machine and could help with testing different OSG revisions.
>
> My machine is not extremely powerful, but 12300 works while 12330 doesn't.
Thanks Csaba, that's already close! I looked at the commit logs but 
didn't find any obvious culprit. A good next test would be r12312 - 
which is the OSG 2.9.13 dev release. Everything before 12312 was actual 
development (nothing obvious), everything after 12312 were code changes 
to fix compiler warnings and Coverity code analysis issues. This one 
will be fun... ;-)

> Message understood ;-)
> I'll have al look during the next days. There is not much spare time to
> dedicate to fg, though but I'll give it a try.
Thanks Torsten, though the message wasn't specifically for you. But our 
FlightGear monster server could probably be helpful here indeed.

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 18.05.2011 18:16, Alan Teeder wrote:
> As requested I have today tested with VC2010 and all the pre-compiled
> versions of OSG that I have available.
>
> These are OSG 2,8.4 and OSG trunk (at present OSG 2.9.12) from
> http://openscenegraph.alphapixel.com/osg/downloads/free-openscenegraph-binary-downloads
> and  and OSG 2.9.10 from
> ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/).
>
> I have black sky in all 3 as we have discussed in
> http://sourceforge.net/mailarchive/message.php?msg_id=27467054.
>
> I did not bother with a cmake for each of these , just copied the OSG bin,
> include and lib directories to my
> C:\FlightGear\install\msvc100\OpenSceneGraph directory and then did a
> build-clean followed by a build and install of both simgear and flightgear.
>
> The random yelllow text bug was apparent on the splash screens as well.

Ok, thanks for testing Alan. At LinuxTag we actually noticed an issue 
that happened when 3D clouds were disabled. Whenever flying in between 
2D cloud sheets, the sky turned black (with white 2D clouds) - really 
ugly. Didn't happen with 3D cloud support enabled. And we figured that's 
a genuine FG bug, which must have been introduced only recently. Might 
be the result of some shader change (maybe by introducing the new sky 
dome shader, but not sure). Do you see a difference when 
enabling/disabling 3D cloud support?

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Modified download_and_compile.sh script

[ThorstenB]

On 18.05.2011 01:08, TDO_Brandano - wrote:
> I have applied a couple of small modifications to the script to fix
> FGCOM and ATLAS compilation with the current repository versions of
> both. The changes are relatively small, just a couple of sed rule
> changes for the FGCOM makefile and a renamed function in ATLAS to match
> the updated SimGear. I have also altered the script version string and
> name to avoid confusion with Brisa's original, but I have no idea on who
> decides what is the current version of the script. Could someone have a
> quick look at the attached copy and see if the changes can be ported
> over to GIT?

Hi Brandano,
I placed the script in GIT since
a) we want all build scripts to be part of the new "fgmeta" GIT 
repository, which at some point will also reference consistent 
simgear/flightgear/fgdata sets (and keep the history of matching 
revisions) - so anyone can just pull "fgmeta" and always get a 
consistent snap shot - including the build scripts.
b) we needed a repository where we can change all required versions 
(flightgear, osg, ...) used by the build script whenever there's a need 
to change. And we needed to stop it from using osg-trunk by default.

What I didn't intend was to fork the script - so changing the name would 
go in the wrong direction. It'd be great if you could try to contact 
Brisa first and ask him to review or merge the scripts - so we avoid 
maintaining separate branches here.
I'm happy to add any updates/improvements to fgmeta. You or Brisa could 
send updates to me (or even place a GIT merge request). But I'd prefer 
if Brisa stayed in the loop.

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 18.05.2011 20:39, Curtis Olson wrote:
> I seem to recall we changed the clear color to black recently.  It may
> be that with 2d clouds we were depending on the clear color matching the
> fog color for correct rendering?  I'm not sure what the motivation for
> changing the clear color was, but I'm guessing it was related to the sky
> dome or drawing space views???

Thanks Curt, that sounds very much like a possible reason. Was that a 
change to fg/sg or fgdata? Anyone remembers the exact commit? Again, 
would be great if s.o. could test the 2D cloud / sky-color behaviour 
with and without the specific "clear color"-patch. If that patch was the 
cause, then we may need to revert it - and find a better solution.

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

Ok, the black sky issue was indeed caused by changing the clear color.
The effect is really ugly - black sky when flying through clouds or
fog. Also black sky when flying above a cloud layer. And it's not
restricted to 2D clouds alone.

That's the relevant commit:
http://www.gitorious.org/fg/flightgear/commit/b36b33f716031ef5933d41a1e5c17c6be3e54c28

Apparently the change was introduced "only" to turn the color of space
black instead of gray. I think flying through clouds/fog is more
important than space-flights for now, so I'm planning to revert that
particular commit shortly until we have a better solution. I know it's
a pity and I apologize to all Vostok-1 cosmonauts. :-)

Any objections (preferably accompanied by a patch ;-) )?

cheers,
Thorsten


On Wed, May 18, 2011 at 9:58 PM, Alan Teeder  wrote:
>
> --
> From: "Martin Spott" 
> Sent: Wednesday, May 18, 2011 8:15 PM
> Newsgroups: list.flightgear-devel
> To: 
> Subject: Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268
>
>> ThorstenB wrote:
>>
>>> Thanks Curt, that sounds very much like a possible reason. Was that a
>>> change to fg/sg or fgdata? Anyone remembers the exact commit?
>>
>> As far as I remember, it's related to "Lauri Peltonen" and "sky dome",
>> it's implementing a shader (among other stuff) and was indeed meant to
>> bring FG closer to how the sky looks in real life: black  :-)
>> I'd have a few commits on offer which might be related, but at least
>> one of them is hiding the possible changes in a big reformatting rush
>> (preferences.xml).
>>
>
>
> Thorsten, Martin.
>
> There is a reference to the black sky problem on the forum at
> http://www.flightgear.org/forums/viewtopic.php?f=47&t=11274&start=30 by
> "Zan", the author of the atmospheric scattering patch .
>
> I have been trying various cloud combinations with an aircraft parked on the
> runway, but so far have not made any visible changes.
>
> Alan

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 18.05.2011 22:45, Csaba Halász wrote:
> On Wed, May 18, 2011 at 8:19 PM, ThorstenB  wrote:
>>
>> Thanks Csaba, that's already close! I looked at the commit logs but
>> didn't find any obvious culprit. A good next test would be r12312 -
>
> ... which is broken.
> Turns out 12303 is the cause for the constant sunshine ;)
Great! Excellent you've found it!

> Specifically, the GLSL version parsing has been broken:
>
> Original code: _glslLanguageVersion = asciiToFloat( langVerStr );
> New code: _glslLanguageVersion = ( asciiToFloat( glslvs.substr(
> glslvs.find( "GLSL "+5 ) ).c_str() ) );
>
> The version string for me here is simply "3.30" (using fglrx 11.4), so
> the old code works but the new one doesn't.
> Incidentally, the GL version parsing doesn't work either, because
> version string is "3.3.10666 Compatibility Profile Context" and the
> code (both the old and the new) expect a decimal number before the
> space.
>
> I can't really believe this is the best way to get version numbers from 
> opengl.

Indeed. And a very good find! I can't believe they've just hard-coded 
some "+5"s and "+8"s to the index to "parse" the version string. Stuff 
like this has to fail.
Can you please post this find at osg-devel? I could cross-post for you, 
but then again it'd be good if you could do the follow ups on this.

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Modified download_and_compile.sh script

[ThorstenB]

Am Donnerstag, den 19.05.2011, 18:34 +0200 schrieb Francesco Angelo
Brisa:
> Hi, I merged the script, applying fixes from Brandano (Who I really
> thank) and moved version number to 1.4
Thanks Francesco, pushed:
https://www.gitorious.org/fg/fgmeta/commit/ae211a06f79aa405273df3d6bfc9963c98b33263

> noob question: how to make a git request ?
Short explanation: you need a private clone of fgmeta:
http://www.gitorious.org/fg/fgmeta
=> "Clone repository"

Then "git pull" your private clone to your local machine, update your
local repository and "git push" the changes back to your gitorious
clone.
Once your private clone on gitorious.org is updated, you can use the
"Request merge" button there.

If that's the only file you're working on using git, it may not be worth
to set this all up. Otherwise it'll be worth looking at the git manual -
or some git-related in our archives.

cheers,
Thorsten



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] heads up: FlightGear release plan

[ThorstenB]

Am Donnerstag, den 19.05.2011, 17:47 +0100 schrieb Vivian Meazza:
> I think the question we have to ask is not "when" but "how". Until that is
> solved, the "when" is pretty meaningless. 
And the last release got stalled more on a "who" than a "how" alone,
when several people became too busy/blocked with RL commitments. You may
not like that, but you can't blame anyone who has done a lot for FG and
who has already invested a lot of "free" time into the project, that
they suddenly need to shift their priorities or need a break for
personal reasons.

The "new plan" alone doesn't exclude the risk of this repeating - but
there more people actively participate in the release, the less likely
we're going to get stalled. So, it's up to all of us.

And all of you can help: you can help by testing FlightGear right now
and of course the upcoming release candidates and file bug reports. Of
course we need as much help as possible for fixing issues. Things in the
FG core will need to be fixed - but also issues concerning fgdata, such
as working on aircraft or GUI. Everyone can look at the bug tracker,
pick issues and submit patches. And even if you can't work on code or
aircraft, you can still help by trying to narrow done what exactly
causes a specific bug issue (such as testing which commit introduced a
particular problem or what command-line/environment/... setting exactly
triggers a certain problem). Or you can help with updating/improving
manuals. Lots to do - any help is welcome!

cheers,
Thorsten




--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Testing OSG-trunk / bug issue #268

[ThorstenB]

On 19.05.2011 20:38, Lauri Peltonen wrote:
> So the solution is either change the clear color to what it was, or make
> it ramp linearly to black or something with altitude.
>
> Or change simgear/scene/sky.cxx around line 117 (repaint method), there
> is a
> if ( effective_visibility>  1000.0 ) {
>...
> } else {
>// turn off sky
>disable();
> }

Great find, Lauri! Removing the visibility condition fixes the issue for 
me - and I haven't seen any side effects (yet ;) ). Not sure why that 
condition was introduced in the first place (suggestions anyone?).
The condition seems a bit of hack to me - why should sky be "switched 
off" for 999 feet, but not for 1001 feet visibility... So, removing it 
may be the cleanest solution to the sky color issue.

My suggestion: we try removing the condition now and see if anyone sees 
new issues. If so, it's probably best to temporarily revert both patches 
for the upcoming release - and try to find a better solution for the 
next one. And if removing the condition does not cause any new issues, 
we've solved the issue anyway (and of course keep it for the release).

Other suggestions? Any background info on the "effective_visibility> 
1000.0" condition? Otherwise I'll try removing it from "sg/next".

cheers,
Thorsten

--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Fog vs black sky (issue #319)

[ThorstenB]

Am Freitag, den 20.05.2011, 19:06 +0200 schrieb ThorstenB: 
> On 19.05.2011 20:38, Lauri Peltonen wrote:
> > So the solution is either change the clear color to what it was, or make
> > it ramp linearly to black or something with altitude.
> >
> > Or change simgear/scene/sky.cxx around line 117 (repaint method), there
> > is a
> > if ( effective_visibility>  1000.0 ) {
> >...
> > } else {
> >// turn off sky
> >disable();
> > }

> My suggestion: we try removing the condition now and see if anyone sees 
> new issues.
After looking into this more closely, I revert my suggestion. Not a good
idea to remove the condition. It's there for several reasons:
* Switches off sun/moon/stars when visibility is low. Looks odd when
there's a bright (red) sun or stars in very dense the fog - so we have
to keep this.
* Also switches off the blue (or colorful) sky dome at low visibility.

Before the patch, the clear color was synchronized to the current fog
color:
SGVec4f clearColor(l->adj_fog_color());
Hence, switching off the sky dome turned all empty bits into fog -
including the entire sky.

So, we need something in the scenery which can be painted with the fog
color. For anyone interested in working on it (Lauri? ;-) ) here are
some options:

* Change the sky dome itself so its color can uniformly be switched to
"fog color" when visibility is low, and then (the easy part ;-) ) move
the sky dome element above the switched sky group (so it's not affected
when the other sky elements are switched off).

* Switch the sky dome off but introduce/enable a new "fog dome" at low
visibility (painted with the fog color).

* Or, change the implementation of FGLighting::adj_fog_color
(and ::sky_color) to return black as the current fog/sky color at high
altitudes - and keep all the other stuff.

The last option is probably the easiest. But not sure what the "right"
solution was - maybe an osg/scenery expert can comment? (Tim/Mathias?)

I've reverted the original patch for now, since we'll need to work on
the particular renderer.cxx lines anyway to solve the issue - and there
were also a few minor "technical" things (see revert-commit comment), so
we should provide a better patch once we know how to solve the fog issue
altogether.

Tracker issue:
http://code.google.com/p/flightgear-bugs/issues/detail?id=319

cheers,
Thorsten



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] heads up: FlightGear release plan

[ThorstenB]

Hi,

since there were no major objections to the release plan, we're
proceeding as proposed.

Current status:

* We've "officially grounded" the releases/2.2.0 git branches yesterday.
The flightgear/simgear "releases/2.2.0" branches were merged back to
"master" (not "next"! "master" always contains the latest release).
However, as proposed, we won't invest any more time into 2.2.0, so
there'll be no binaries on the download page, no updated aircraft
downloads, no announcements, etc.

* git/next is bumped to version 2.3.0 now. Actually we should have done
so when we branched releases/2.2.0 in January. Remember. it's odd minor
versions for the developer version now (git/next), even minor numbers
for releases.

* Hudson is prepared for providing release binaries and installers
(thanks James!). Once we create a new release branch, Hudson should
start building the binaries/installers (see Hudson's "Windows-release",
"Mac-release", "Linux-release" projects). As usual, these will be
updated hourly. We'll also provide complete Win/Mac installers
(including fgdata base package) regularly, maybe about weekly, so these
can be used for wider beta testing. We can't include the base package in
the _hourly_ installers though, due to bandwidth/size limits (almost
400MB for the fgdata base package).

* We also started assessing tracker issues (thanks Gijs!). Some were
already fixed in the last days. And it doesn't look too bad, few issues
are highly critical. However, there are some areas where we're missing
people, for example for some (new) FDM, and a number of ATI-graphics
issues. Have a look at the tracker:
http://code.google.com/p/flightgear-bugs/issues/list


Finally, as a reminder now:
Only 4 more weeks to 2.4.0 feature freeze, remember June 17th, when
we'll close sg+fg "next" branch, and (!) fgdata "master" for 4 weeks.
Only bug fixes should be committed after June 17th.
releases/2.4.0 will be branched on July 17th, when the main developer
branches will be bumped to 2.5.0 and reopen for new features. Beta
testing for 2.4.0 will continue for another month after that, till
August 17th. But all this was already described in the release plan
http://wiki.flightgear.org/Release_Plan

cheers,
Thorsten

On Do, 2011-05-19 at 14:29 +0200, Torsten Dreyer wrote: 
> Hi everybody,
> 
> during this year's LinuxTag, Martin Spott, Mathias Fröhlich, Thorsten Brehm 
> and myself developed a strategy and a concept about how to kick out new 
> releases of FlightGear on a regular schedule.
> 
> Please find our first draft here:  http://wiki.flightgear.org/Release_Plan
> 
> For the impatient reader, this is the abstract:
> We plan to have two releases per year, one in February, one in August. The 
> first scheduled release following this concept will be 2.4.0 in August this 
> year, 2.6.0 is scheduled for February 2012.
> 
> If no major objections arise, we will set the version number on the current 
> development stream to 2.3.0 and will call out a "feature freeze" on June 17th.
> 
> Any comment and certainly any help for actually preparing the release is 
> welcome. 
> 
> Thanks, Torsten



--
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Running FlightGear on i386/linux systems (32bit)

[ThorstenB]

Hi,

is anyone successfully running FG on 32bit Linux (i.e. using i386 - not 
x86_64)?

I guess most Linux users are using 64bit now. We may have an issue 
specific to 32bit/Linux systems - at least that's the only obvious thing 
that all reporters of a particular issue have in common.
See bug #314: http://code.google.com/p/flightgear-bugs/issues/detail?id=314

Issue results in lots of Nasal errors - such as this:

 Nasal runtime error: bad/missing argument to subvec()

May affect multiplayer mode only - or be a general problem.

Can anyone else confirm - or is anyone not seeing it on such a system?

And of course, most welcome would be someone who could reproduce the 
issue - and also knew a bit about gdb...

cheers,
Thorsten


--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Running FlightGear on i386/linux systems (32bit)

[ThorstenB]

Am Donnerstag, den 26.05.2011, 22:31 +0200 schrieb Anders Gidenstam:
> Have you seen this post?
> http://www.flightgear.org/forums/viewtopic.php?f=25&t=11967&p=125409#p125375

No, haven't seen it before. Would always be good to also have such
updates in the tracker - otherwise we spend useless time
tracking/debugging solved/investigated issues.

> It seems to suggest that some code breaks under optimization (on some gcc 
> version?).
Interesting indeed. I think we still have "pointer aliasing" compiler
warnings in the mp module - could easily be related. Sometimes compilers
actually complain for a reason.

cheers,
Thorsten



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] broken textranslate animations

[ThorstenB]

On Sat, May 28, 2011 at 2:09 AM, Roland Häder wrote:
> maybe ThorstenB's commit ca668f8a373190093738a69a5b700d6fcc086c7c does
> cause this? He wrote there:
> Fix bug #285 textranslate and scroll animation with negative numbers

Yes, the commit indeed breaks textranslate for many aircraft -
especially many attitude indicators are affected/broken. I'll reopen
bug #285 - we need a different fix.
(But that commit wasn't mine!!! :-P )

cheers,
ThorstenB

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] screen shots with OSG multi-threading

[ThorstenB]

Hi,
another heads up: I've pushed a patch fixing screen shot issues in OSG
multi-threading modes (see  in preferences.xml).
Please test this on your machines, with your favourite OSG threading
mode. As usual, report any issues - here or there:
http://code.google.com/p/flightgear-bugs/issues/detail?id=127

Oh, and a _complete_ update is required: pull/rebuild simgear +
flightgear + fgdata. Just sayin' it...

cheers,
Thorsten



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Fwd: Issue 184 in flightgear-bugs: JSBSim: command line arguments broken

[ThorstenB]

Am Samstag, den 28.05.2011, 23:20 +0200 schrieb Bertrand Coconnier:
> A number of issues have been reported in the bug tracker #184 about
> the capacity of JSBSim to take some command line arguments into
> account. After investigating the subject, I found that several bugs
> were involved in this issue:

Thanks Betrand, awesome work! Worked for me in a quick test. I've pushed
it to git already - easier testing for everyone else. We could still
update/revert/.. something, if there were major issues.

@TorstenD: please have a look at the part of the patch affecting the
environment manager.

cheers,
Thorsten



--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Segfault with OSG multi threading

[ThorstenB]

On 30.05.2011 19:25, Stefan Seifert wrote:
> The segfault happens when the main loop thread tries to
> access GL information. I know next to nothing about openGL programming but I
> seem to recall that it's not allowed to access the same GL context in 
> different
> threads. So how is this supposed to work?

Well, wouldn't surprise me to find more related multi-threading issues. 
Not sure how long OSG itself supports it, but I guess it wasn't a major 
priority at the time when FG was adapted to OSG. And I'm sure more fixes 
will be necessary to safely support it.
The particular source lines also have an "//OSGFIXME" comment - another 
hint that work was left behind.
Try replacing the calls to SGIsOpenGLExtensionSupported - they provide 
constant information anyway. It'd be enough to check 
version/capabilities once during init and then use constant data at 
run-time. Try if that helps. Patches welcome :).

cheers,
Thorsten

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] - Open Radar development

[ThorstenB]

On 28.05.2011 04:47, Marcel Fernandez wrote:
> Other question I have is where can I find documentation about multi
> playerprotocol. I saw that the documentation I found  in flight gear
> wiki has some differences with the one found in flightgear multiplayer
> server page(fgms.sourceforge.net ).

The wiki description doesn't look to bad. But if in doubt, it's best to 
consult fgfs sources for actual implementation. The multiplayer 
implementation isn't really a beautiful part of our sources, but the 
actual encoder isn't too complex. Have a look at 
FGMultiplayMgr::SendMyPosition in
http://www.gitorious.org/fg/flightgear/blobs/next/src/MultiPlayer/multiplaymgr.cxx

cheers,
Thorsten

--
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery, 
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now. 
http://p.sf.net/sfu/quest-d2dcopy1
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Linker failed to build fgfs

[ThorstenB]

On 01.06.2011 20:48, Roland Häder wrote:
> with the last commit from James Turner I could not build FGFS on Linux.

Fixed now. Friends of CMake forgot about automake... ;-)

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [Fwd: Crash in latest GIT/master]

[ThorstenB]

On 03.06.2011 04:58, Roland Häder wrote:
> I have found more:
> http://pastebin.com/UrE81hNW
Looks like an OSG installation problem. There is always an 
"osgPlugins-2.x.y" subdirectory for an OSG 2.x.y installation. I don't 
think this could be a general error with OSG 2.8.4.

> 2.8.4 is latest stable release.
They are currently testing osg 2.8.5-RC2. Final call for tests has been 
made. You could also try this version. If anything wasn't working there, 
you still have a day or two to raise the issue to OSG.

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Rating System Redux

[ThorstenB]

Hi Stuart and all,

 > http://wiki.flightgear.org/Formalizing_Aircraft_Status

We have some (too few!) aircraft providing documentation / tutorials, 
i.e. how to start, how to use instruments... I like extremely 
detailed/realistic aircraft, and I'm not asking everyone to provide 
cheating autostart options. But realistic FDMs/cockpits/... are still of 
little use when people don't know how to use them. So, wouldn't it be a 
good idea to make the level of documentation/tutorials part of the new 
rating system? Especially since that's certainly of interest to new 
users (new to FG, or just new to the aircraft).

So, how about adding "Documentation and Tutorials" rating section, like:

0: no documentation/tutorials available
1: aircraft key bindings dialog available, basic documentation included 
(i.e. readme.txt)
2: tutorials on basic aircraft operation available (at least start-up)
3: advanced tutorials available (start-up, autopilot, approach/landing 
configuration)
4: highly advanced training tutorials available (i.e. covering 
emergencies/engine-failures etc)

You can certainly argue on how many points these are worth (compared to 
FDM/cockpit realism etc). But it shouldn't be ignored completely.

Any thoughts?

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Please insert disk into drive F:

[ThorstenB]

Hi,
there are issues with some of our models due to texture references with
_absolute_ Windows file paths (using a drive letter). Usually that's not
a problem: OSG tries to load the texture from the given absolute path
first (e.g. "F:\foo\texture.png"), and if that's not available, it cuts
the filename and tries the given search directories (i.e. searches
texture.png in fgdata/Aircraft/bla/Model/..).

However, some poor souls happen to have exchangeable media drives
connected to particular drive letters. Guess what happens... Windows
blocks execution, triggers a "helpful" pop-up dialog:
"Please insert disk into drive F: Click OK to continue..."
Happens for every single texture referencing a media drive. Sounds like
in the good old MS-DOS days - but is reported for Windows 7. Users get
annoyed ;-). Might be possible to disable the pop-up with some Windows
registry magic, or by changing the letter of their local media drive -
but that's not a real solution.

The 1.0.1 scenery release is also affected. Examples:
 Objects/e020n40/e026n44/aacr.ac => F:/Documents and Settings/Mircea/My
Documents/My Pictures/RCAA_inaripatul.GIF
 Objects/w090n40/w088n41/john-hancock-center-fb.ac => i:\modeles 3D
\JohnHancockCenter\john-hancock-center-1.rgb
Apparently, it's better with current TerraSync. But I haven't checked
all files.

I found the same issue with some of our fgdata/Aircraft and took the
liberty of fixing these:
A340-600, A380, B-52F, Dromader, Hunter, Lockheed-NF104, Spitfire,
victor
http://www.gitorious.org/fg/fgdata/commit/2902907538a1fbddecd78c481f18daa2ade7dd14

In two cases the referenced textures aren't even in fgdata. The absolute
file paths made it work on the original author's machine only:
Lockheed-NF104 and victor are missing lava1.png / brushed_alloy.rgb.
Maybe the authors want to add these.

Finally, I found 3 affected global models in fgdata. Martin, can you fix
these please (needs to go to the scenery database):
 Models/Transport/ICE3middlecar.ac
 Models/Transport/ICE3middlecar2.ac
 Models/Buildings/tower-hexa.ac
Remove "D:/Cygwin/FlightGear/data/Models/Transport/" and
"c:/flightgear/cvs/fgfsbase/models/buildings/". A "c:" drive reference
usually isn't a problem - but anyway...

Btw, the model loader is an original OSG module, so we can't just change
the code here (ignore absolute paths). Trying to avoid such references
is the only (short-term) solution I can see. Might also be worth doing a
"grep" on our model/TerraSync database. Maybe there is more...

It's generally a bad idea to use absolute paths in model files (even if
it's unix paths - and there's loads of "/home//..." in our
model), since you can never be sure if it's working for anyone except
the original author (see above). But only the Windows paths are known to
have ugly side effects - so please at least avoid these...

cheers,
Thorsten



--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Please insert disk into drive F:

[ThorstenB]

On 04.06.2011 15:28, Frederic Bouvier wrote:
> The problem is that the Blender AC exporter generates these absolute path.
> In the PLIB days, the loader simply ignored the path to just take the
> simple name.

Right, unfortunately it requires another manual step.
The advantage of not ignoring the path (OSG) though is, that you can 
reference textures in other directories. There is no longer a need to 
copy every texture into the same model directory as the .ac file. You 
can reuse shared textures from other directories (from the same or even 
other aircraft, from a global texture directory etc).

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Object distance fading color

[ThorstenB]

On 05.06.2011 10:26, Erik Hofman wrote:
> There is now a new property /rendering/scene/overcast ranging from 0.0
> (normal behavior) to 1.0 (complete overcast).

Just wondering: we have /sim/rendering, which contains a long list of 
properties - including properties for clouds and precipitation. And we 
have /rendering which contains the scene/dome properties only. Is there 
a specific reasons these are separate?

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Nasal submodules / local weather

[ThorstenB]

Hi Thorsten (& all),

some time ago I had added an option to introduce Nasal submodules, or,
to be more exact, to introduce Nasal modules using fgdata/Nasal/...
subdirectories and add an option to load such modules on demand only
(using a single enable/disable property per module).

This has several advantages:
* Nasal files can be grouped neatly instead of all scripts being mixed
up in a single fgdata/Nasal directory. Grouping makes a lot of sense for
modules consisting of several scripts - local weather is the best
example.
* Guaranteed loading sequence. Submodules are loaded _after_ the main
fgdata/Nasal scripts, so they can rely on all fgdata/Nasal content to be
already present. No more need for awkward listener callbacks, just to
make sure that basic "props" or "gui" modules are available.
* Finally, users have the option to disable loading modules.
Unfortunately, just loading scripts (code/data) into memory already
causes certain _run-time_ performance effects - even if the Nasal code
was never executed (so even when all listeners/timers were disabled).

Admittedly, I'm concerned that the rising number of complex Nasal
modules degrades the simulation performance for everyone. Having an
option to disable modules completely seems a good idea, so everyone can
choose for himself. And when something is not even loaded, it's
naturally guaranteed that it cannot have any performance effects at all.

I'd like to use the local weather module as a good example here. I'm
planning to do the same with a few other modules (tutorial.nas,
jetways*.nas, maybe multiplayer, and the new Nasal Boeing CDU).

I've done some tests with a "local weather submodule" and it seems fine.
Few modifications are required - mainly affects the init handlers (need
to listen to a different signal) and some GUI aspects (add an option to
enable/load the Nasal module, enable/disable menu items). I've attached
the changes. Before applying the patch, move the existing weather
scripts into a new subdirectory "Nasal/local_weather":

# create new subdirectory "local_weather"
mkdir fgdata/Nasal/local_weather

# move existing files to new directory
mv fgdata/Nasal/compat_layer.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_dynamics.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_tiles.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/local_weather.nas fgdata/Nasal/local_weather/.
mv fgdata/Nasal/weather_tile_management.nas fgdata/Nasal/local_weather/.

# apply patch (attached)
cd fgdata && patch -p1 < local_weather.patch

I'd like to push the change to fgdata before the release. Please test if
you're happy with these changes - or let me know if you saw issues.

cheers,
Thorsten

diff --git a/Nasal/local_weather/compat_layer.nas b/Nasal/local_weather/compat_layer.nas
index 0fbd8e4..4605aed 100644
--- a/Nasal/local_weather/compat_layer.nas
+++ b/Nasal/local_weather/compat_layer.nas
@@ -67,8 +67,19 @@
 # The compatibility layer is currently work in progress and will be extended as new Nasal 
 # APIs are being added to FlightGear.
 
+var weather_dynamics = nil;
+var weather_tile_management = nil;
+var compat_layer = nil;
+var weather_tiles = nil;
+
+
+_setlistener("/nasal/local_weather/loaded", func { 
+
+compat_layer = local_weather;
+weather_dynamics = local_weather;
+weather_tile_management = local_weather;
+weather_tiles = local_weather;
 
-_setlistener("/sim/signals/nasal-dir-initialized", func { 
 
 var result = "yes";
 
diff --git a/Nasal/local_weather/local_weather.nas b/Nasal/local_weather/local_weather.nas
index 52c7a2f..eecb95a 100644
--- a/Nasal/local_weather/local_weather.nas
+++ b/Nasal/local_weather/local_weather.nas
@@ -4414,10 +4414,18 @@ setprop(lw~"tiles/tile-counter",0);
 
 setprop(lwi~"ipoint-number",0);
 
+var updateMenu = func {
+	var isEnabled = getprop("/nasal/local_weather/enabled");
+	gui.menuEnable("local_weather", isEnabled);
+	gui.menuEnable("local_weather_tiles", isEnabled);
+}
+
+_setlistener("/nasal/local_weather/enabled", updateMenu);
 
 # wait for Nasal to be available and do what is in startup()
 
-_setlistener("/sim/signals/nasal-dir-initialized", func {
+_setlistener("/nasal/local_weather/loaded", func {
+	updateMenu();
 	startup();
 });
 
diff --git a/gui/dialogs/local_weather_config.xml b/gui/dialogs/local_weather_config.xml
index 5826cff..f72bb54 100644
--- a/gui/dialogs/local_weather_config.xml
+++ b/gui/dialogs/local_weather_config.xml
@@ -6,10 +6,22 @@
 
  local_weather_config
  400
- 400
+ 440
  false
 
 
+
+   5
+   400
+   15
+   15
+   Enable local weather module
+   /nasal/local_weather/enabled
+   
+dialog-apply
+   
+
+
 
   5
   370
diff --git a/gui/menubar.xml b/gui/menubar.xml
index bbaa69a..fba2618 100644
--- a/gui/menubar.xml
+++ b/gui/menubar.xml
@@ -329,14 +329,8 @@
 
 		
 			Local Weather
-			
-dialog-show
-local_weather
-			
-		
-
-		
-			Local Weather Tiles
+			local_weather
+			false
 			
 dialog-show
 local_weather_tiles
@@ -344,7 +338,8 @@
 		
 
 		
-

Re: [Flightgear-devel] Idea: Priority for loader threads?

[ThorstenB]

On 06.06.2011 18:36, Roland Häder wrote:
> Wouldn't it be possible to set lower priority for those loader
> processes? I think no user can be asked to buy an expensive SCSI
> hardware system (which would lower the CPU usage compared to IDE/SATA
> systems).
>
> I mean somthing like "niceness" for forked loader threads, like we have
> on Uni*/Linux boxes. So the "main" simulation thread would have more CPU
> cycles left than the loader (which can quietly load in background).

You're (and everyone is) welcome to investigate the details of these 
hickups in more detail. That would be a huge improvement for FG to get 
rid/lessen these issues.
However, I'm pretty sure it's not as simple as changing a thread 
priority. These hickups also happen on multi-core CPUs. I can see them 
on my local 6-core machine - and we saw them on our dual CPU/12-core 
monster at LinuxTag - where each thread basically had its own CPU core 
(so priority doesn't matter much). My guess is that there is an issue 
blocking our main loop when new models are loaded. Possibly the mainloop 
is blocked in some mutex while a new model is merged into the scene 
graph. But it'd be up to someone to investigate this in more detail (and 
hopefully also find a solution).

cheers,
Thorsten

--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Terrain engine

[ThorstenB]

On 08.06.2011 08:18, Michael Sgier wrote:
> quote fred: "There is nothing that could prevent to release it under the
> GPL, but in
> the light of
> recent events (read FPS) I am not fond of releasing something that
> couldn't be used.."
Don't cut quotes. Fred actually agreed to release it under the GPL when 
it's usable for FG and integrated by someone. Doesn't really work as an 
argument to change license.

On 08.06.2011 08:19, Stefan Seifert wrote:
> On Wednesday 08 June 2011 07:43:12 Michael Sgier wrote:
>> why not simply change the fgfs licence once and for all? Android is not all
>> GPL anymore...we could do the very same.-
>
> Would you really want to restrict the very freedoms that made FlightGear such
> a successful project, just to have some legal means against some shady people
> who try to fool the uninformed into paying some money for FG? Chances are,
> that a different license would not even help, since you couldn't even find out
> who to sue. I do not have much code in FG, but I for one would absolutely
> oppose such a useless and destructive move. If not for the freedom, I would
> never have bothered with FG. I would just have payed a couple of bucks for X-
> Plane and be flying.
>
> Yes, it leaves a very sour taste that people who have contributed nothing are
> earning money (we don't know how well they do btw.) while the people who did
> the work get nothing. But the truth is that we wouldn't get anything in any
> case and we chose it that way. People are cheated every day and thiefs get
> loads of money. It's sad, but nothing will change that.
>
> If you really want to fight those scamers, there's a very simple way to do
> that: inform people. Marketing. People who know about FlightGear will not pay
> for an outdated copy. Go out and write about FG in aviation forums and blogs.
> Write letters to aviation magazines which include articles about flight sims.
> Write about FG in all the social media you use. Post loads of cool videos on
> Youtube. Be visible!
>
> Everyone can help here and it takes only minutes for every action. This helps
> not only preventing people from getting fooled, but also to get more users and
> hopefully contributers which is a hell of a lot better than having to deal
> with law suits, distracting developers and reducing freedom. I say let's
> change the fight into one they simply cannot win. That way we will not only
> stop losing something, but actively win visibility, users and contributers.
>
> Stefan

+1
Thanks Stefan, one of the best emails on the topic.

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] "Pro Flight Simulator"

[ThorstenB]

On 12.06.2011 11:58, Michael Sgier wrote:
> http://www.androidzoom.com/android_games/cards_and_casino/flight-simulation_xcuh.html
>
> how long should we tolerate such...

We've had that before. This 15KB "app" doesn't even contain a 
FlightSimulator. And it doesn't do anything (so I doubt it contains a 
single line of FG code). See comments on that site: "pure fake 
application!".
There's loads of fake apps being offered. Not nice. But what's that got 
to do with FlightGear? Or with our license? Those are pure scams 
unrelated to anything.

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Properties on sim-reset

[ThorstenB]

Hi,
we're resetting all properties on sim-reset to their initial value 
(saved at sim start-up). There's only a few (hard-coded) exceptions of 
properties which are not reset.
I've just pushed a fix to keep userarchived properties unaffected by a 
sim-reset. Their value is always maintained in between sim sessions - 
however you had to exit/restart the sim first, before their value was 
also retained on sim-reset (don't even try to understand that...it was 
just odd).
I could think of several more properties which would better be retained 
on sim resets. I'm about to add a "noreset" flag to the supported 
property attributes. That would allow anyone to flag such exceptional 
properties which should not be affected by a sim reset (in 
XML/nasal/C++). And we can get rid of the hard-coded list of property 
exceptions.

Any objections? Any better name than "noreset"? Otherwise I'll change as 
proposed...

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [BUG] Re: SimGear branch, next, updated. c782a32076016f2c3c01b4fd437b024dc77806e9

[ThorstenB]

On 12.06.2011 21:20, Melchior FRANZ wrote:
>>  Introduce "PRESERVE" flag to protect properties on sim reset.
>>  Some specific properties need protection and shouldn't be restored to 
>> their
>>  original values on sim-reset.
> This commit is buggy. Contest opened ...
> m.
What's wrong?
T.

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] screen shots with OSG multi-threading

[ThorstenB]

Am Montag, den 13.06.2011, 00:34 +0200 schrieb Csaba Halász:
> On Sat, May 28, 2011 at 11:33 PM, ThorstenB  wrote:
> This commit is buggy too :->
> 
> Okay, I'll be nice and provide a hint: It is not safe to call
> removeTask from the timer event itself.
> 
Have you pulled latest simgear? I had adapted the event manager to allow
tasks to remove themselves.

cheers,
Thorsten



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Added missing terrsync make+header files...

[ThorstenB]

On 13.06.2011 12:16, Frederic Bouvier wrote:
>> This is with  LIBSVN not enabled in SIMGEAR Cmake.
>> If I do enable LIBSVN it seems to need APR_CONFIG, which I do not
>> have.
Right, libsvn depends on APR - both needed. Detection of dependencies 
should work with automake. But I know nothing about CMake - so I'll need 
someone to help here. When libraries are not installed (or the feature 
is explicitly disabled), it should not require the libraries/header 
files (compiler switch "HAVE_SVN_CLIENT_H" should be off).

> I can't find a 64-bit libsvn library compiled for windows. Would I be able
> to use the 32-bit terrasync process instead of trying to run a non existent
> by default command line ?
If you don't have a libsvn library, it'll default and try to use the 
external "svn" command-line utility instead. It won't matter if that 
external utility was 32 or 64bit of course.

I'll also push matching GUI dialogs soon.

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Introduce "PRESERVE" flag

[ThorstenB]

> With MSVC10
> 
> -- Build started: Project: fgScripting, Configuration: Release 
> Win32 --
>   NasalSys.cxx
> NasalSys.cxx(918): error C2039: 'PRESERVE' : is not a member of 
> 'SGPropertyNode'
>   
> C:/FlightGear/install/msvc100/SimGear/include\simgear/props/props.hxx(739) 
> : see declaration of 'SGPropertyNode'
> 
> (And similar report in nasal-props.cxx,  property_list.cxx, globals.cxx, 
> where it is used)
> 
> Plus this one
> 
> globals.cxx(398): error C2065: 'PRESERVE' : undeclared identifier
> globals.cxx(400): error C2660: 'copyProperties' : function does not take 4 
> arguments

Same reason for all issues: simgear doesn't match. "git pull" simgear please.

cheers,
Thorsten



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [BUG] Re: SimGear branch, next, updated. c782a32076016f2c3c01b4fd437b024dc77806e9

[ThorstenB]

> On 12.06.2011 21:20, Melchior FRANZ wrote:
> >>  Introduce "PRESERVE" flag to protect properties on sim reset.
> >>  Some specific properties need protection and shouldn't be restored to 
> >> their
> >>  original values on sim-reset.
> > This commit is buggy. Contest opened ...
> > m.
> What's wrong?
> T.

Melchior, I'm happy about anyone code reviewing, testing and reporting
issues. But I'll need some more specific details on what's supposed to
be broken with that particular commit introducing another property flag.
Just saying "buggy" isn't enough for a valid bug report. Otherwise I
assume you hadn't pulled fg/fgdata - and "contest closed"...

cheers,
Thorsten



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Compile and Hudson builds

[ThorstenB]

> But problem solved. Simgear´s Cmake install directory had got reset to its 
> default instead of when I did a "Delete Cache" . Consequently when I built 
> FG itself it still found the old Simgear headers and libraries.
> 
> I am re-compiling and will report back if there is still a failure.
Ok, thanks. And let us know if the libsvn issue is still there. CMake
worked on Hudson (Linux/Mac) - but we're missing the MSVC build machine
for a few days now. Does the Windows slave just need a reboot - or is
anything broken?
Gene, could you have a look?

> BTW Hudson showed a simgear failure with cmake this morning.
That's also solved. Just an issue with the build process itself - which
died for no good reason. Restarting the job did the trick. So Hudson
looks all "green" again.

cheers,
Thorsten



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Compile and Hudson builds

[ThorstenB]

On 13.06.2011 20:23, Alan Teeder wrote:
> It looks as if I still have one error with the FG compile .-(
>
> fgGUI.lib(gui_funcs.obj) : error LNK2019: unresolved external symbol
> "bool __cdecl copyProperties(class SGPropertyNode const *,class
> SGPropertyNode *)" (?copyProperties@@YA_NPBVSGPropertyNode@@PAV1@@Z)
> referenced in function "void __cdecl mkDialog(char const *)"
> (?mkDialog@@YAXPBD@Z)
> C:\FlightGear\flightgear\src\Main\Release\fgfs.exe : fatal error
> LNK1120: 1 unresolved externals

Looks like fgGUI.lib wasn't recompiled against the latest simgear header 
- or it was indeed complied against an old header. Try to "make clean" 
(however you'd do that with MSVC) in "flightgear". Otherwise check your 
simgear/props/props_io.hxx header file(s). If you see:
  bool copyProperties (const SGPropertyNode *in, SGPropertyNode *out);
then you've got an old header somewhere (old simgear).
If it's
  bool copyProperties (const SGPropertyNode *in, SGPropertyNode *out,
int attr_value=0, int attr_mask=0);
then it's the right/current header (4 arguments).

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

[Flightgear-devel] Heads up: scenery download / built-in terrasync

[ThorstenB]

Hi,

the final GUI bits for a new feature are now in fgdata - the last
feature addition for the 2.4 release from my part... You can
download/update scenery directly from FlightGear now (main menu:
Environment => Scenery). Credit for the idea goes to James - bugs are
mine ;-).

It provides built-in terrasync support - with some advantages:

* Configuration requires a scenery target directory only (your
"terrasync" directory) and a checkbox to enable. For now, you'll also
need to provide the terrasync directory as part of your --fg-scenery
paths (otherwise you won't see downloaded scenery). Maybe we can add the
directory to the search path internally some time, simplifying things
even more. Should help anyway (especially new users) in obtaining world
scenery. Not quite as simple as loading scenery with Google Earth yet -
but closer...
Before someone asks: the scenery server address is displayed in the GUI,
but editing is disabled. Is there any reason (right now), why users
would want to change? (You could still change using preferences.xml /
property browser though).

* You can enable/disable scenery download any time using the menu. When
you notice mid-flight that scenery is missing, just enable the download
checkbox and wait a bit (depending on your connection speed ;-) ).

* There is also a (still experimental) option to refresh scenery tiles
once their update is complete. You could "warp" into a new region,
initially see ocean only (default replacement for missing scenery) and
eventually see the ocean tiles being replaced by actual scenery. That's
still experimental though, the update logic requires improvement. Looks
weird when scenery tiles are removed when the a/c is just parked/rolling
on them (old scenery disappears for a second before the "fresh" one
reappears). Also bad on final approach... And the a/c position and
altitude of clouds may need to be adapted when scenery altitude has
changed - which is a problem when ocean (sea level) is replaced by
actual scenery (mountains...). Usually ok to enable the feature
mid-flight. Otherwise, there is also a manual "refresh" button, so you
could choose yourself at what time to replace ocean/missing scenery.

The feature reuses the terrasync sources and relies on a subversion
client. Either using built-in subversion (when "libsvn" is installed,
which is recommended). Otherwise, fgfs tries calling an external utility
("svn") for downloads. All the same as with original terrasync.
The built-in svn support is enabled for automake right now (use
"--with_libsvn=no" to disable). It's off by default for cmake builds (we
could change that, use "ENABLE_LIBSVN" to enable for now). The cmake
build isn't really well tested yet - except that Hudson seems happy for
all targets. And as mentioned, I'd need help with cmake if it wasn't
working properly. And it'd also be good to get Hudson to build the
Windows/Mac binaries with built-in svn support (seems to do that for
Linux/automake already).

As usual, report any (new) issues. If you don't like the feature, keep
the checkbox disabled and the whole thing shouldn't bother you. You can
keep using manual downloads or the separate terrasync utility as before
(which lives on), of course.

cheers,
Thorsten

PS: Yes, a complete update (sg+fg+fgdata) is required for things to
work.



--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] [BUG] Re: SimGear branch, next, updated. c782a32076016f2c3c01b4fd437b024dc77806e9

[ThorstenB]

On 14.06.2011 13:54, Melchior FRANZ wrote:
> --- a/simgear/props/props.cxx
> +++ b/simgear/props/props.cxx
> @@ -642,7 +642,7 @@ SGPropertyNode::trace_read () const
>* Last used attribute
>* Update as needed when enum Attribute is changed
>*/
> -const int SGPropertyNode::LAST_USED_ATTRIBUTE = USERARCHIVE;
> +const int SGPropertyNode::LAST_USED_ATTRIBUTE = PRESERVE;
Indeed! That's a tricky one to spot.

> Yeah, but what about the bug hunting contest?! Who wins the coffee
 > machine?

git history reveals the same bug has been made at least once before 
(when USERARCHIVE was introduced in 2005). Took almost 3 years before it 
was noticed/fixed. It was you, Melchior, who fixed it then. Since that's 
a recurring bug, you had insider knowledge, and we can naturally assume 
you already claimed and got a coffee machine for the same issue at the 
time, you are exempt from winning again. If you're interested in a "tea 
maker" though (aka tea bag, English premium brand), let me know.

Well, thanks for remembering the issue and reporting. I don't dare to 
ask which Nasal code relies on custom property attributes. I hope that 
still works with one custom bit less now - but I don't want to know... ;-)

cheers,
Thorsten

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Re: [Flightgear-devel] Heads up: scenery download / built-in

[ThorstenB]

On 15.06.2011 22:57, Martin Spott wrote:
> By having a closer look at Thorsten's patches you'd realize that his
> primary work was to turn the standalone program with hard-coded host-
> and pathnames into a neatly configurable library.  The interface
> between this lib and FlightGear is pretty slim, it doesn't add much
> overhead and you're free not to use it.

Thanks Martin. Another thing to add here: what I actually did was 
dividing existing terrasync sources into two parts: the library which 
holds all the actual SVN code, and another part that parses command-line 
arguments, processes UDP messages and runs as a stand-alone utility. I 
actually tested the new library using the (remains) of terrasync(.exe) 
stand-alone utility - but decided not to push any changes to terrasync 
itself. Not now at least.

And I'm pretty aware of the HLA approaches - we've discussed that for 
long at LinuxTag (surprise, Mathias was there). I'm absolutely in favour 
of splitting things up - Mathias and Martin know this from LT. Yet, I 
did not see any contradiction with integrating terrasync. I would like 
more subsystems being converted into separate libraries and being 
capable of running them outside FlightGear (which, I agree, is great for 
any advanced user - especially those with CAE-like setups), but still 
have the option to also run the same subsystems all inside a single FG 
(which does have advantages for other kinds of users). With a proper and 
flexible interface (HLA could be the solution here) both is possible. 
When we have that standard interface installed, we can use the new 
library with it (while the left-over bits of terrasync(.exe)'s 
command-line/UDP code might die and be replaced by some generic loader).

On 15.06.2011 23:30, Vivian Meazza wrote:
 > And less clever users, which is most of the people out there, won't. I
 > include myself in that category, since I have failed to make it work
 > so far.
 > I sometimes wonder if we really expect the average user to poke
 > around in preferences.xml? But then, we have FGRun that does most of
 > that for us.

There should be no need to edit anything in preferences.xml. You should 
be able to enter the directory in the GUI (yes, I know, no directory 
dialog). Or you could also provide it via a new command-line option 
(--terrasync-dir). And it's preserved across sessions. So you only need 
to provide/edit it once. I had responded to your email yesterday in 
private, hinting that you probably somehow managed an incomplete fgdata 
pull (which you later confirmed). Maybe something is still broken - 
maybe with my code or still on your system. Or maybe I forgot to push 
something.

So, I am really sorry, Vivian, that you were still unable to make the 
system work for you - on day 2 (though it seems people only started 
trying to use it _today_).

But this and other posts today show our general FG mailing list 
tendency: being negative. It's the almost natural response to any 
change. Oh crap! Doesn't work! Don't like it... I've spent _loads_ of 
time into FG in recent months. I have worked the bug tracker almost 
daily. I have fixed countless bugs other people have introduced - _some_ 
even hidden in absolutely crappy code (so much on the "design" issue). I 
have searched and fixed memory leaks and investigated performance 
issues. I've fixed loads of issues affecting systems that I personally 
never use. So, if anything wasn't working with my _own_ addition now - 
only in GIT for two days, remember - I think it should've been more than 
obvious that I'd be absolutely willing to explain/test/resolve things - 
and help anyone who was really interested. And to make it work as 
expected: to provide an easier solution in accessing scenery (read the 
forums, if you want to know how users do get along with existing 
terrasync). But that's not how FG works. It's "normal" that any slight 
malfunction is immediately criticized as hell. No attempts in being 
positive, trying to encourage / motivate other people in improving their 
work - and to keep them working on FG. When something isn't working, 
start complaining and being negative. Just look at this list's recent 
history.

So, you're all hoping for a better FG. A large redesign, so we can make 
use of multi-core systems, can even distribute parts across multiple 
machines. Can separate the GUI. Get Nasal outside the main simulation 
loop. Well, so do I. But I'm becoming more and more convinced, that this 
indeed is _not_ going to happen. No, not because of that "new" library 
and "such tendencies" (while in fact that library is much better 
prepared to be driven by HLA or something similar than most other 
parts). No, we're very likely to not get any of this since we're 
absolutely unable to motivate - or at least keep people motivated on 
working on our project. That's a major issue we have. Everyone who 
spends time is "welcomed" by negative comments - and surprisingly many 
leave. And I'm sorry to say, after re