Re: [Flightgear-devel] Linux (Ubuntu) libsvn not found by cmake
Am 28.11.2012 22:04, schrieb Alan Teeder: Yes, I understand that the user can override Cmake defaults. This would however require another fix to the Brisa automated script. My point is that /usr/lib/l386-linux-gnu/ IS the default that the Ubuntu package manager is now using for the svn library (for 32 bit configurations at least), and therefore it would be sensible to add it to the Cmake svn library search path. I would not be surprised if Debian is now the same. Apparently this is a bug affecting some of Ubuntu's cmake packages. It is not considering the multiarch directories, which were introduced for Ubuntu. This is not just causing problems with FG - but with all packages which depend on libraries, which were already converted to the new multiarch directory structure. The Ubuntu cmake bug report says, it was fixed. For details, see: http://code.google.com/p/flightgear-bugs/issues/detail?id=946 cheers, Thorsten -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
Am 28.11.2012 20:12, schrieb Stefan Seifert: A good first step would be to contact the maintainer of the FlightGear package in the games repository and ask why build is disabled for all non-openSUSE distributions. Well, that would be me ;-), and since you have already asked: The cross-platform build is disabled for FG because building for other distros isn't just a matter of flipping a switch. First, you need to ensure that all the dependent libraries are available. And when you check the OBS repositories, you'll notice very few packages provide support for other distros. So, you'll need to start bottom-up, take care of lots of packages, OSG, dependent graphics and sound libraries - and lots stuff that they depend upon. The OBS cross-platform support was introduced years ago, but few package maintainers have adopted it. Next, you'll need to make sure that the build spec file works for other distros. Each distro comes with their subtle differences. Even in between versions: it's sometimes funny enough to build a spec file which works with several versions of the same distro (sometimes you need to install the libsvn package, sometimes it's libsvn-1). After all, you will still need to deal with every single distro. The advantage with Linux is: it is free and everyone can adapt it. The disadvantage is: Linux distros actually use their freedom. Linux is not like Windows, where you build a binary and it just runs everywhere (well, yes, mostly). It's a flexible platform which every distro somehow adapts to their own needs and likes - sometimes maybe even intentionally to distinguish themselves from others. Also, each distro maintains its own app store (well, they don't call it like that, but it's really what it is - except that it's all free) and many, if not most users will even refuse to install stuff from other sources (considering separate installers too difficult - or fearing it could mess up their system or trigger update problems). So, universal binaries aren't even welcome everywhere. I only adopted the OpenSUSE packages, which helps with finding things causing problems with packaging, like incomplete install rules, missing icons, invalid ASCII encodings in documents/READMEs, or with different compiler versions (the OBS build currently uses 4 different GCC versions). All the stuff, which isn't noticed when building stuff locally - but which prevents building a proper package or having it accepted into a distro. I can fix these things directly in FG, which should make things easier for other packagers. What I have also tried for the FG 2.8 release, was getting in contact with other package maintainers. Reminding them of the new release, giving them some hints on what needs to be changed. Many have updated their packages pretty quickly - which may already be an improvement (see below). When possible, I'm also taking patches upstream, so they don't need to mess with adapting local patches for every release (yes, the infamous shared library thing is an example). This helps with speeding up the updates. Concerning FG 2.8 (released August 17th), what I am aware of: * OpenSUSE (released August 17th) https://build.opensuse.org/package/show?project=gamespackage=FlightGear * Playdeb for Ubuntu (released August 18th) http://www.playdeb.net/software/flightgear * FreeBSD (released September 7th) http://www.freshports.org/games/flightgear * Fedora (released September 11th) http://koji.fedoraproject.org/koji/packageinfo?packageID=1200 * Arch Linux (released October 8th) https://www.archlinux.org/packages/community/x86_64/flightgear/ * Gentoo (October 15th) http://packages.gentoo.org/package/games-simulation/flightgear * Debian (2.6.0 (not 2.8.0!) accepted into stable on October 30th) http://packages.debian.org/de/sid/flightgear Yes, it would still be nice to have a universal build. And I guess, ThorstenR (and probably others) think we're therefore doing a lousy job and should just spend more time on FG - like work full time to provide you the perfect service that you clearly all deserve (and for free, of course) :). But at times you notice live is really short. You really need to think about what you want to do, and on which things you really want to spend your precious spare time on. And do I personally want to be responsible for building a package that runs on *any* Linux distro in the universe - and to somehow take care of all their ugly tweaks? To be frank: no. The advantage of the current approach is: it distributes the work. It involves people which actually know and care about their individual distros - and, at least I do not need to do it all on my own. Yes, it may mean there's an extra latency before a new version becomes available for some distros. But is it really _so_ bad, like Debian users apparently seeing an 8 month delay? Or that Linux users may need to update their OS every 2 years (well, you have to update anyway, since
Re: [Flightgear-devel] SenecaII: cannot start right engine
Am 25.11.2012 12:57, schrieb Andreas Gaeb: with the git version from last Thursday, I cannot start the right engine of the SenecaII. Works fine here with current Git. The main problem seems to be that /systems/fuel/fuel-pump[1]/enabled is set to false and immediately gets switched back to false if I set it to true in the property browser. Either the fuel pump control switch is off (circuit breaker #8, fuel pump R), or the right engine primer wasn't pressed prior to starting (both result in /systems/fuel/fuel-pump[1]/enabled being forced to false). cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SenecaII: cannot start right engine
Am 25.11.2012 16:07, schrieb Andreas Gaeb: It was indeed the primer of the right engine; if I press it, the engine starts. However, the left engine starts out of the box after launching Flightgear by pressing } three times and holding s; the right engine does not. Same for running the Hot start tutorial and holding s. Do you see this behaviour, too? Yes, same here, the left engine starts more easily. This means there already is excess fuel in the left engine's carburator at startup - it happens in RL, too. Let's assume it's not a bug, but another realistic detail Torsten has intentionally modelled ;-). Btw, after running the Cold start tutorial, the master switch is off. Maybe the Start Engine tutorial should advise you to switch it back on again, otherwise the starter won't work when following the tutorial strictly. Yes. Patches welcome. ;-) cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI manager fails to compile with MSVC
Am 24.11.2012 14:16, schrieb Alan Teeder: Thanks – FG compiles and runs again. Thanks for the feedback. As you may have noticed, the Jenkins Windows builds were apparently stuck/blocked for 3 days - it hasn't even tried to compile - hence there were no messages (and that's why it says last successful build 3 days ago). The MSVC issue was only in trunk for a few hours though - so everything should have been fine before. cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Which navradio code is considered standard?
On 22.11.2012 10:08, Adrian Musceac wrote: I've gone ahead and used the new radio code for navaids, but I have a question: which navradio code is considered standard? newnavradio or navradio? navradio is the current/old standard, newnavradio is the new module. Most aircraft use navradio, few newnavradio. I'm not sure if there is a plan to switch/replace the old radio at some point, and whether the new module was compatible with the old etc. But for now, both are there. TorstenD is the expert here. cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)
Am 17.11.2012 22:43, schrieb Stuart Buchanan: On Fri, Nov 16, 2012 at 2:27 PM, Torsten Dreyer wrote: 1. A lack of stress testing. We have a four weeks testing period with release binaries publically available, so I am not sure how to improve that. Do we need more testers? Do we need more time? We've already got a fairly extensive lead-in time for the release. More testers on more platforms would seem to be the answer. Perhaps we should advertize for testers of those platforms that aren't adequately covered by developers running git? The main area to improve is to distribute release candidates for all platforms earlier - preferably starting immediately after the freeze. That would already give us more time for testing - without extending the actual freeze period. As I remember, we were pretty late with the initial distribution of FG 2.8.0-RCs - especially for Mac (partly due to technical issues and partly due to people not being available - for which no one is to be blamed for, of course). We should be in much better shape for the upcoming release - since the build automation on Jenkins should be working for all platforms now - and nothing about the infrastructure or build system has changed since the last release. How about having a test run a week or two in advance, just to make sure we can indeed produce release installers for Win+Mac - and then release the first RC on December 17th/18th or 19th ;-) ? Curt, Fred, James? ;-) cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 10:13, schrieb Alan Teeder:
Changing --fg-aircraft=C:\FlightGear\MyAircraft
to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect.
Pull latest fgdata and see if it has any effect.
Is it possible that things were only working before, when the path given
for --fg-aircraft used / instead of the usual Windows \ path
separator? There was something goofed up in Nasal/io.nas, which suggests
this should have been the case.
If it's still not working, replace your fgdata/Nasal/io.nas with the
attached version, run fgfs, reproduce the issue and send the log output
to me (default log settings are enough).
cheers,
Thorsten
# Reads and returns a complete file as a string
var readfile = func(file) {
if ((var st = stat(file)) == nil)
die(Cannot stat file: ~ file);
var sz = st[7];
var buf = bits.buf(sz);
read(open(file), buf, sz);
return buf;
}
# Loads Nasal file into namespace and executes it. The namespace
# (module name) is taken from the optional second argument, or
# derived from the Nasal file's name.
#
# Usage: io.load_nasal(filename [, modulename]);
#
# Example:
#
# io.load_nasal(getprop(/sim/fg-root) ~ /Local/test.nas);
# io.load_nasal(/tmp/foo.nas, test);
#
var load_nasal = func(file, module = nil) {
if (module == nil)
module = split(., split(/, file)[-1])[0];
printlog(info, loading , file, into namespace , module);
if (!contains(globals, module))
globals[module] = {};
elsif (typeof(globals[module]) != hash)
die(io.load_nasal(): namespace ' ~ module ~ ' already in use, but
not a hash);
var code = call(func compile(readfile(file), file), nil, var err = []);
if (size(err)) {
(func nil)(); # FIXME hack around
Nasal bug
if (substr(err[0], 0, 12) == Parse error:) { # hack around Nasal
feature
var e = split( at line , err[0]);
if (size(e) == 2)
err[0] = string.join(, [e[0], \n at , file, , line ,
e[1], \n ]);
}
for (var i = 1; (var c = caller(i)) != nil; i += 1)
err ~= subvec(c, 2, 2);
debug.printerror(err);
return 0;
}
call(bind(code, globals), nil, nil, globals[module], err);
debug.printerror(err);
return !size(err);
}
# Load XML file in FlightGear's native PropertyList format.
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_properties(filename [, props.Node or property-path]);
#
# Examples:
#
# var target = props.globals.getNode(/sim/model);
# io.read_properties(/tmp/foo.xml, target);
#
# var data = io.read_properties(/tmp/foo.xml, /sim/model);
# var data = io.read_properties(/tmp/foo.xml);
#
var read_properties = func(path, target = nil) {
var args = props.Node.new({ filename: path });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Load XML file in FlightGear's native PropertyList format.
# file will be located in the airport-scenery directories according to
# ICAO and filename, i,e in Airports/I/C/A/ICAO.filename.xml
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_airport_properties(icao, filename [, props.Node or
property-path]);
#
# Examples:
#
# var data = io.read_properties(KSFO, rwyuse);
#
var read_airport_properties = func(icao, fname, target = nil) {
var args = props.Node.new({ filename: fname, icao:icao });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Write XML file in FlightGear's native PropertyList format.
# Returns the filename on success or nil on error. If the source
# is a props.Node that refers to a node in the main tree, then
# the data are directly written from the tree, yielding a more
# accurate result. Otherwise the data need to be copied first,
# which may slightly change node types (FLOAT becomes DOUBLE etc.)
#
# Usage: io.write_properties(filename,
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 22:28, schrieb Alan Teeder: It all works out of the (git) box now. I have not tried the io.nas that you attached to your post, but can do if you wish. No need to, if it's working now. I believe we've fixed another old and ugly bug here, requiring Windows users to use Unix-style paths for some command-line parameters to make Nasal access work (namely for --fg-aircraft and --fg-scenery). The realpath patch only extended the existing issue - since realpath converts Unix-style paths back to proper Windows-style paths - so now the issue also caught those using Unix-style paths as a work-around so far. Thanks, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 15.11.2012 12:55, schrieb Alan Teeder: Found it ! Here is the culprit: commit dbea0c936103b2530e551be7c51bc6bd7b5218cb Author: ThorstenB Date: Sun Nov 11 19:26:51 2012 +0100 Geoff McLane: realpath for Windows using _fullpath. Alan *From:* Alan Teeder mailto:ajtee...@v-twin.org.uk *Sent:* Thursday, November 15, 2012 11:32 AM *To:* Flightgear-devel@lists.sourceforge.net mailto:Flightgear-devel@lists.sourceforge.net *Subject:* [Flightgear-devel] Bug 479 has come back Bug 479 (loadxml: reading 'file.xml' denied (unauthorized access) from --aircraft directory) has come back during the last week. (Windows MSVC 2010). Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] download_and_compile.sh
On 12.11.2012 14:25, Pat wrote: I've been learning a lot about Linux development by reading the download_and_compile.sh. I have a few ideas for enhancements to the script. Is anyone keeping a list of requested enhancements to the script? Is this list the right place for discussion of the script and changes to it? The script is maintained by Francesco Brisa. Not sure if he's reading this list. Otherwise try contacting him directly (see contact details in script header). cheers, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 05:32, schrieb Jon S. Berndt: I have a new problem, now, though. I do see the scenery (when I get under about 6000 feet - until then I see only white fog) since I gave the path to the directory outside $FG_ROOT where I placed the terrain, but now I no longer get proper HUD symbology - the numbers aren't there anymore. Any suggestions on how I can do this? I'm not sure how I can set two scenery paths on the cygwin command line for starting FlightGear. When the HUD no longer works, make sure you haven't deleted anything in FGDATA - like the fonts. You don't need to define the path to the base scenery (within fgdata). If you downloaded additional scenery, in one or multiple separate directories, you can separate the paths with : (works also on Windows). fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 13:14, schrieb Frederic Bouvier: multiple separate directories, you can separate the paths with : (works also on Windows). fgfs --fg-root=FGDATA_PATH --fg-scenery=CUSTOM_PATH1:CUSTOM_PATH2:... On windows, the path separator if ; You are right, for scenery it indeed is. But I'm sure I have seen a funny hack in our code somewhere, which detected if the : character was preceded by a single or multiple letters - in order to distinguish Windows drive specs (i.e. C:\foo..) from actual path separators (C:\foo:A:\bar). But maybe this hack is in another area - or it was dumped... cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flight recorder / replay system
Am 11.11.2012 10:52, schrieb Thomas Geymayer: Everything works great here. Save own flights, playback own and your flights (Nice approach btw.;) ). Only with jsbsim the my controls button is missing, but that wasn't working before neither... Good. ;-) Right, the my controls button is currently intentionally disabled for JSBSim and for YASim helicopters. Only works with YASim aircraft so far. YASim reads in all relevant properties before each iteration, so any external change to a property (aircraft angle, velocity) takes immediate effect. This is why it is easy to just take over control of a replay session: when the replay system has restored the state of all relevant properties, we can just reenable the FDM calculation - and YASim just takes it from there and continues. Unfortunately that's different with YASim helicopters: the rotor speed (pretty much the most important property of a helicopter) isn't read from the property tree. So, if you took over control in mid-air, YASim ignores the rotor speed set by the replay system - and the helicopter dropped like a stone. I tried to fix this a while ago, but it turned out to be more complex than expected. It's the same issue with JSBSim, if I remember correctly. It doesn't read (at least not all) properties prior to an iteration, so external changes to aircraft properties don't have any effect. It's possible to start JSBSim with a given velocity/angle/.. though, like we do when initially starting FlightGear or trigger a simulator reset. However, we currently can't just reinitialize or tear down and recreate a single subsystem - at least that is currently not working with the FDM subsystem. The whole (re)initialization phase has a lot of dependencies and fixed sequences. So that currently also isn't an option. The hope is that will change. We have already cleaned up a lot of subsystem / initialization things over the past year - and more things are planned. Eventually, I hope we can just recreate an FDM at any time (out of thin air... ;-) ) with arbitrary initial settings. cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 17:39, schrieb Jon S. Berndt:
Also, if I specify only the custom scenery path - as in the command line
below - I get the errors that follow. Don't know if those are revealing or
unexpected ...
bin/Win64/fgfs.exe --fg-root=./data --fg-scenery=./scenery
--aircraft=CitationX --native-fdm=socket,in,30,,5550,udp --fdm=external
--airport=KCHS
Cannot find Nasal script './data/Nasal/local_weather ...
Aha... You must not use relative paths on Windows. Only absolute paths
are supported.
If anyone was interested/able to fix the support for relative paths on
Windows, please implement SGPath::realpath in simgear/misc/sg_path.cxx:
std::string SGPath::realpath() const
{
#if defined(_WIN32) || (defined(__APPLE__) MAC_OS_X_VERSION_MAX_ALLOWED =
1050)
// Not implemented for Windows yet. Return original path instead.
#else
...
This code is supposed to convert a relative path (given in command-line
parameters) into a proper absolute path - since we have several places
in FG, which just cannot deal with relative paths.
cheers,
Thorsten
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 18:23, schrieb Jon S. Berndt: Thanks for the reply. The path handling in FlightGear seems a bit delicate. Not sure if in Cygwin under Windows I need to be more unix-like, or more windows-like in specifying paths. I'll play with that some, but relative paths do work - at least selectively, for some things. Yes, they work in some areas. But they don't work for Nasal and some other areas. To avoid the issues you really need to use absolute paths - whatever kind works for Cygwin... For Cygwin, instead of c:\FlightGear, try /c/FlightGear/... or c:/FlightGear/... cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery not being loaded
Am 11.11.2012 19:05, schrieb Geoff McLane:
That's strange no one has done this for WIN32 ;=()
I guess most Windows people are using launchers. It's mainly Linux
people who love command-lines ;-).
#if defined(_WIN32)
// with absPath NULL, will allocate, and ignore length
char *buf = _fullpath( NULL, path.c_str(), _MAX_PATH );
if (!buf) {
SG_LOG(... as per unix ...);
return path; // failed, return path as is
}
std::string p(buf);
free(buf); // was allocated using malloc(), so
return p;
Thanks. I have committed it, but can't test it myself. Can some check
with latest SimGear if relative paths are working for Windows now - with
standard MSVC build (check for Nasal ... not found errors).
Actually, thinking about it: cygwin is POSIX, so it can use the POSIX
implementation.
I'm not sure if the compiler switches in sgpath are really correct - it
assumes normal Windows paths for cygwin (WIN32 is also defined for
cygwin). I guess Cygwin isn't really well maintained for FG right now.
Patches welcome... ;-)
cheers,
Thorsten
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] flight recorder / replay system
I have updated the flight recorder / replay system with something I had already planned after last year's update. Two new features: 1. Sessions can be saved to/loaded from disk. Simply fly along, then select Save flight recorder tape from the file menu and press Save. You can load the tape again at any later time. You can keep the tape recording for your own amusement - or send it to someone else. 2. You can add text messages to a flight recording. This turns the recording into a flight tutorial. It's somewhere in between the existing tutorial system and a Youtube video: unlike the existing tutorials, the recorded flight can be used to demonstrate complete flight manoeuvres, such as how to fly a complex approach into an interesting airport. And unlike a fixed video tutorial, users can change views, inspect instruments, or take over control at any point. As a teaser and test, I have created a tutorial showing how to fly the nice Isafjördur fjord takeoff and approach. A beautiful airport in Iceland. The tutorial should be used with the Beechcraft b1900d: Instructions: - Make sure you have (terrasync) scenery for Iceland (airport BIIS). - Download tutorial and store on your disk: http://www.filedropper.com/b1900d-biis-isafjordur-tutorial - Start FlightGear with the b1900d. - Menu File = Load Flight Recorder Tape - Select the downloaded file b1900d-BIIS-Isafjordur-Tutorial.fgtape - Press Load - Watch. You should also see instructions during the flight. - Try the approach yourself (i.e. go back with the replay slider, press my controls...) (The cool Icelanders fly this approach on daily schedule. For the interested, here's a real-life recording: http://www.youtube.com/watch?v=Fv_c6vA8DXE ). Never mind the scenery glitch at the airport (in the FG scenery, not on the RL airport ;-) ). I'll document the details of how to create a tutorial (add text messages) later. For now, I'd like to know if the basic system is working everywhere, and if recorded tapes work across systems. When something is (not) working, let me know. cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Windows SG DLL build - NO GO!
On 08 Nov 2012 Geoff McLane wrote: But maybe we would be better off removing the SIMGEAR_SHARED option if WIN32 ;=)) No objections. Indeed it wasn't intended for Windows. I'll remove the option for WIN32. And of course, I really wonder WHY we added a 'shared' version of SG at all... but that is another topic... I assume someone had a 'good' only-for-UNIX reason ;=)) Exactly. It improved support for Linux distributions a lot, which do have fixed rules to use shared libs. Since shared lib support is now in SG, all distros can/could drop their local makefile patches, which they had to use before. It has removed a major obstacle preventing distros from quickly updating to the latest FG release: they no longer need to wait for a volunteer to update their local makefile patches for every single FG release. Please let's not discuss the reasons here why Linux packagers are so strict with using shared libs (they have very good reasons), it's futile and beyond our power anyway... cheers, Thorsten -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
On Wed, 7 Nov 2012, Durk Talsma wrote: No worries. :-). This is actually fairly subjective, and I'm afraid that I didn't explain my concern too well in my initial post. The real issue is salience, which you can describe as the subjective property of a percept to stand out from it's environment (see http://en.wikipedia.org/wiki/Salience_(neuroscience) ). So, a cool feature that easily dominates in a screenshot contest may not be able to capture our attention very effectively in a different context, such as the one at FSWeekend, where visitors are usually bombarded with high quality graphics. So, what I was actually looking for was new ways of *using* FlightGear, within the limitations of an internet-free environment. Our lan based multiplayer server was very effiective in the past, and in the last few years we also had some new aircraft and/or a specific theme, or even an internet connection, all of which served as great eye-catchers. This year was a bit of a step back in those respects, so I found myself more often than not reverting back to the tested and tried. Only slightly exaggerating, there are two types of people at FSWeekend: those who have never even heard about FG before, and those who have faintly heard about it, but never actually used or seen it ;-). So, presenting FG really needs to start with the very basic stuff: what is FG, where do I get it, how much does it cost ;-), how is it different/better etc. People also ask questions like Can I reuse the FSx addons which I already bought, will my hardware devices work, etc. So, presenting FG is not so much a matter of concentrating on the latest development gimmicks - like we would do in a newsletter or release announcement for people who already know FG. It's more about explaining and showing how it looks/feels in general. But of course, *all* the nice features inside FG and all the nice aircraft absolutely help with demonstrating FG to an interested visitor and help making a good overall impression, so that people will actually remember FG when back home - and start downloading. I agree with Durk, maybe we have been a bit less effective this year in making people stop and look. And until people actually pay attention, it doesn't even matter what's on the screens at all (FG, Rembrandt or just random pixels :) ). As you can see on the photos, there are loads of tables at FSWeekend. Each has a computer with 1-3 displays. In that respect, our booth may not have looked different enough this year. Last year, the 10 display (or 12 displays for LinuxTag :) ) worked pretty well as an eye catcher - causing almost everyone passing to go WTF!?? Brain-to-feet: full stop!! Brain-to-eyes: Check it out! What is this??. It also worked well as an ice-breaker: people would immediately start asking questions How do you connect these? How many machines are running these? How much power does it draw... ;-) So, I really hate to say it, but there really is something about marketing. Or, to go with Durk: there really is something about psychology: to get people's attention, it takes more than a good product alone... ;-) On Wed, 7 Nov 2012, geneb wrote: Durk, if you can find someone that's willing to cut the parts for you, I'd be happy to donate a drawing set for my single-seat collimated display system. You show up next year with THAT and I can just about guarantee most folks will forget how to spell FSX. :) Yay! That would *definitely* trigger a major visitor stampede! ;-) cheers, Thorsten -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FSWeekend 2012...
... is already over now, unfortunately. For those who couldn't attend but are interested in what it was like (make sure to join next year!), here are some photos showing the event and FlightGear booth: http://www.flickr.com/photos/70866411@N05/sets/72157631926925511/detail/ More details are probably to follow (maybe Durk will explain how he managed to reserve the hall's huge main projection screen exclusively for FlightGear - and how a silly broomstick is connected... :-) ). Thanks to every attending this year! Yet again, it's been a lot of fun :). cheers, Thorsten -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FSWeekend 2012...
Am 04.11.2012 20:39, schrieb Jon S. Berndt: Did you run into Austin Meyer (X-Plane)? No, he was there last year to promote his latest release, but I'm not aware that he attended this year. (There were rumours someone had seen a Curtis Olson at the event, but that is yet another story...;-) ). cheers, Thorsten -- LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear commit breaks Atlas (ot??)
FYI the Atlas configure.ac will use -lSimGearCore if ENABLE_SIMGEAR_SHARED is set to yes, which is misleading. I will change this to something more more useful (Suggestion?). I added ENABLE_SIMGEAR_SHARED to Atlas some time last year, since the libraries SimGearCore and SimGearScene (the latter isn't required for Atlas) were only built when the ENABLE_SIMGEAR_SHARED switch was set for SimGear - so the options for SimGear and Atlas matched exactly. Since 2.9.0 SimGear always builds two libraries only (instead of the earlier 9 or 10 different libs), no matter whether static or shared libs were selected for SimGear. So indeed, the option should be renamed now. Also, the default should be changed - since SimGearCore is now always provided by latest (and future) SimGear. Suggestion: rename the switch to SIMGEAR_LEGACY and invert the logic, so it can be set when building with old SimGear versions. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch: FOV automatic compensation for wider screens
On 7 Oct 2012, at 15:19, Stuart Buchanan wrote: The use-case is to enable or disable particular views if you don't want to have to spend ages cycling through them. I also quite like this option. Some a/c also provide many additional custom views. It's handy to just enable the personal favourites. Options dialogs at present, but the View Options name is too generic. How about Enable/Disable Views? Doesn't sound like a proper main menu entry to me. Just as awkward to translate to other languages. Alternatively, we could just merge the Display Options and View Options dialogs into one (probably named View Options). Neither of them are very large. That sounds good to me! A more radical idea would be to change the noun from Views to Cameras, which IMO are a bit more descriptive. We'd then have a Cockpit Camera rather than a Cockpit View etc. Also ok. But it could still be merged into a single dialog then. Disadvantage of renaming view to camera though is that plenty of places would need to be adapted or things get inconsistent. There are also lots of aircraft which install custom views (jump seat view, radio panel view, ...). So, things get messy. And I think camera even sounds odd for some of our current views: would the copilot view be renamed to copilot camera? Should aircraft provide custom radio panel cameras? Hmm ;-). Personal taste: I'd keep the views named as views and just merge the dialogs. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound and HSI problems with Lightning
On 8 Oct 2012, at 14:35, Alan Teeder wrote: The HSI is now stable, but does not agree with the other compasses. Is there a gyro alignment procedure that I need to learn? Yes. It's one of the pilot's duties as part of the pre-start checklist ;-). Also something which needs to be done every 10-15 minutes when in flight, since the indication continuously drifts away. See here: http://www.pilotfriend.com/training/flight_training/fxd_wing/di.htm When the sim starts (or is reset), the initial indication should be aligned with the compass though. However, when the gyro isn't powered, the indication will be wrong as soon as the aircraft turns (offset). The HSI has a knob to adjust the indicator (see C172 cockpit), but it seems to missing in the Lightning. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine sound and HSI problems with Lightning
On 7 Oct 2012, at 09:06, Alan Teeder wrote: If I taxi the Lightning the HSI starts operating normally, and does not fail when I apply the brakes. Something is not getting initialised I guess. Watch the properties /systems/electrical/outputs/DG and /instrumentation/heading-indicator-dg/spin Initially, they are both 0 (no voltage output, hence the gyro isn't spinning). When full thrust is applied, voltage output goes to 115.0016 and the gyro starts spinning (voltage seems a bit high, but the code isn't simulating overvoltage failures ;-) ). When thrust is reduced, voltage output returns to 0, hence the gyro is slowing down again. Of course, a heading indicator isn't working properly when the gyro isn't spinning (no voltage supplied). Check the computation for /systems/electrical/outputs/DG in Aircraft/Lightning/Systems/lightning-electrical.nas. Something doesn't seem right. I have also pushed an update to fg which improves the failure simulation when gyro spin is low (at spin==0 the indicator should be completely stuck now). However, I haven't seen anything in there which could have been different for Windows vs Linux. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Gitorious] Activity: fredb pushed 1 commits to nextnext...
On 4 Oct 2012, at 01:28, James Turner wrote: The translation strings come from FGDATA, so it sounds like either your fgdata hasn't updated correctly, or you're somehow selecting a locale for which we don't have translations? The English language resource is always considered for defaults. incomplete resource only appears when the identifier isn't found in the user's selected language resource, nor in the English (master) resource. So, a git pull for fgdata is required here, to update the (English) GUI labels. cheers, Thorsten -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgdata trouble
On 21 Sep 2012, at 13:03, Anders Gidenstam wrote: The master branch of fgdata has become messed up. A number of commits have become duplicated and some undone (they exist in the history but their effect is gone from HEAD). It has happened again, fgdata history is messed up. It looks as if my last commits (6d46fe7, f722671) were applied to fgdata multiple times now (duplicates are 818b92f and e7452f7). With gitk itself, I can't even see how where these originated (looks as if I had pushed them multiple times). Only the gitorious.org history shows that these were indeed not pushed by me: https://www.gitorious.org/fg/fgdata/commit/818b92fa07a49c333f80ac21f483b33fd5e2b7c7 https://www.gitorious.org/fg/fgdata/commit/e7452f70358e67824e499294fd32d6d6f8d3dd93 Can we please make it a requirement that _local_ merge operations must not become visible on our public repository, so _everyone_ has to rebase before pushing anything? The only merge/branch operations that should be visible in our public repo should be those that affect public branches (release branch creation/merges etc). There's really no reason why other people should see that user XYZ has merged his local branch 1-15 times with gitorious, before pushing back. It only results in the git history becoming unreadable. And apparently it results in more issues. If you compare simgear's or flightgear's history with fgdata's history, you'll see how nice and readable a git history can be - since obviously (almost) everyone pushing to sg/fg knows hows how to rebase. Resolving merge operations locally, to reorder and cleanup the history is really simple - and only requires a few seconds. If you have uncommited changes in your local directory, you can temporarily stash them - so that rebase won't complain. For fgdata: git stash git rebase origin/master git stash pop (And for simgear/flightgear: git stash git rebase origin/next git stash pop ) It is also a good idea to check the git history (gitk) before pushing to gitorious: you can read and double check your own changes a final time - and also check the history for local merge or funny duplication issues. If you're having local Git trouble (like duplications), *please* ask before pushing to gitorious. cheers, Thorsten -- Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] FlightGear branch, next, updated. 1dbc2c83e5c0514b1a51eb0c2aee9f6dbe577492
I'm very suspicious of this - I don't think there's been any post 2.8 commit
that could change such a core behaviour. (I don't read every single commit in
detail, but I look at the summaries)
The change is certainly valid, but I'd be much happier knowing why it worked
before and what broke it. I'll take a quick look myself but any help would be
appreciated.
I checked commit comments, but couldn't find anything related. Checked a
bit closer now: my best _guess_ is, it's related to the following
simgear change:
commit f1201eaebc3fbb8964e06b7ef158fd34a12901aa
Author: Mathias Froehlich
Date: Sat Aug 25 08:43:12 2012 +0200
scene: Reorganize stg loading.
Specifically, the diff contains:
SGReaderWriterXML::readNode(const std::string fileName,
{
+std::string fileName = osgDB::findDataFile(name, options);
+
osg::Node *result=0;
try {
SGPath p = SGModelLib::findDataFile(fileName);
The XML reader relies on osgDB to resolve paths now. If
osgDB::findDataFile cannot find the file, it returns , in which case
SGModelLib::findDataFile cannot search any additional directories.
So, maybe osgDB::findDataFile doesn't know about extra directories,
while SGModelLib::findDataFile was fg-aircraft aware. Not sure why the
change was applied in the first place.
Again, I haven't tested - it just looks plausible and somehow related.
Maybe you or Mathias can investigate if that's what triggered it and
whether anything else may still be broken now.
cheers,
Thorsten
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear at TU Delft
However, in the past couple of weeks ( after a graphics card update for our simulator) we started working with FlightGear 2.8. Thanks a lot for your report! It's really nice and motivating to see FlightGear being used for serious (research) projects and not just for fun/gaming. And a full motion sim certainly is a serious thing ;-). Also shows that FSWeekend is a worthwhile event (btw for everyone: this year's FSWeekend takes place on November 3rd/4th). cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] strange screen
On Sun, Sep 2, 2012 at 11:31 AM, Alasdair ali...@btinternet.com wrote: After git pull (sg,fg,fgdata) a couple of days ago, I was presented with a strange screen which I had not seen before. My regular was shown as a sub-screen in the bottom-left corner. Clicking the maximise widget restores full screen, but any click on a menu item returns me to this stupid screen. Is this infuriating behaviour deliberate, or has my graphics driver gone walk-about? https://dl.dropbox.com/u/15936159/fg_quarter-screen.png Unfortunately a long standing issue. This affects ATI graphics cards when running newer drivers. It can be fixed by reverting to an older ATI driver (see link below). To me it looked like a genuine OSG or ATI driver bug (the size of the graphics view port doesn't properly resize to the size of the window), but it's likely triggered by something special we're doing in FG, since other applications don't seem to have this issue. Also, it's timing-/sequence dependant: it only affects certain aircraft (aircraft using wxradar, which changes/delays the OSG init sequence on startup, are less likely to have the issue) - and for some people it dis- and reappears with certain FG builds. It would be really good if someone seeing the issue locally could properly debug this - even if it means digging into OSG - since a larger number of people are affected. I tried remote debugging this a while ago, but gave up after being unable to narrow it down inside FG. Maybe someone else has better luck. For more see here: http://code.google.com/p/flightgear-bugs/issues/detail?id=385 cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Running Nasal at simulation rate
From: Johnathan Van Why jrvanwhy@gm... - 2012-08-29 13:20 I have a need to run Nasal code at the same rate as the simulation. At this point, I am unsure which to pursue. Which method do you find to be better? To be frank, the whole idea is just bad in the first place - so I vote for #3: avoid *any* Nasal in the fast simulation loop. Nasal execution is slow and non-deterministic. Running it in the fast simulation loop is the last thing we want. I know, some people on the forum would like to eventually replace fgfs(.exe) with nasal(.exe), because apparently everything is just better (tm) when implemented in Nasal (core = bad, nasal = good). But I really think this is a completely wrong direction - and harming the project. Concerning your original issue on implementing an autopilot: a much better way to do it is to avoid Nasal for the actual autopilot controller elements (numeric computation). Instead, use XML autopilot rules for the filter, gain, damper, integrator elements: http://wiki.flightgear.org/Autopilot_Configuration_Reference You can then use Nasal for the high level stuff, and enable/disable/switch the individual controller elements (e.g. in order to automatically switch the autopilot mode when capturing the ILS). There are some nice examples with fgdata/Git aircraft. You could look at the 777. This is also how such things are done in the real world: controllers aren't implemented in imperative programming languages these days - especially not in scripting languages. People use model-based design and connect controller elements - using graphical tools like MATLAB/Simulink. Obviously, FG is missing a graphical interface to specify the controller rules - but the idea of specifying through XML is the same and specification is straight forward. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSim bug fix that should be backported to FG 2.8.0
Am 20.07.2012 11:10, schrieb Anders Gidenstam: Given that there is some risk that the behaviour of carefully tuned flight models change I'd suggest we only update 2.9.0 and do not update 2.8.0 as it is late in its release cycle. Valid point. Can someone with more insight into the patch (Jon/Betrand...) judge whether the patch means a larger/noticeable change in a models flight behaviour? Has anyone observed any noticeable effect? The patch is currently in both trunks - but we can still back off with the release branch, if there's a problem/risk. And we certainly don't have time to adapt any aircraft FDMs for 2.8.0... cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG2.8.0 on final
It's July 17th: http://wiki.flightgear.org/index.php/Release_plan Continuing with FG2.8.0's landing procedures, we have turned on final, moving the release candidate to a separate Git branch (release/2.8.0 for sg/fg/fgdata). FG2.9.0 is already lined up on next (and fgdata master), so new developments are cleared for take off. All bug fixes should be pushed to the next/master branches first. If they are essential for 2.8.0, they should be cherry-picked into the release branch. If you don't know how Git cherry-picking works, please ask the cabin crew for help. The closer we get to the touch down point, the more important is a stable approach. So, throttle back, and when correction is necessary, apply minimal rudder and patches only. Arrival at the release gate is expected to be on time on August 17th, so we'll flare the release a few days early to wrap things up and build final setups. Until then, keep seatbelts fastened... ;-) cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.8-RC3 Startup Failure for Unknown Reasons
Am 17.07.2012 05:14, schrieb Keita Yokoyama: DUMP FILE and .WER REPORT compressed into single ZIP file: http://www.mediafire.com/?3lwhbrd5dd9wdu7 It would be helpful if s.o. with a Windows PC could convert this dump into a human (developer :) ) readable stack trace - using Dumpchk.exe or something: http://support.microsoft.com/kb/315263 cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PAPI/runway lights size - Rembrandt
Am 16.07.2012 16:22, schrieb Christian Schmitt: the size of the PAPI lights has been bothering me for quite some time. It looks just too big for me. Going through the simgear git history I found out quickly that it was changed by commit 1dfde64ac2e6ed0a Use bigger point sprites for airport lighting. I reduced the size locally to 14 for the PAPI and 8 for the runway lights. All was good until I started FG with Rembrandt enabled. Then the PAPI lights do not show up during daytime now. This looks like a Rembrandt bug to me. I think the sizes should be reduced for the non-Rembrandt users as this is still our main audience. Fred, do you have a clue what is going on? To me it appears the lights aren't scaled with the screen size, unlike the rest of the scenery. So they appear really huge especially on small screens (while on large screens, they might even appear too small). http://code.google.com/p/flightgear-bugs/issues/detail?id=716 cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCom - cmake
Am 10.07.2012 15:27, schrieb HB-GRAL:
The last weeks Geoff McLane and me forked fgcom temporary at gitorious
(http://www.gitorious.org/fgcom) and made some significant changes.
Origin source is still available at http://sourceforge.net/projects/fgcom/
Schön wieder Fortschritte bei fgcom zu sehen. Und schön CMake + Git zu
sehen ;-). Habt ihr auch mal Holger Wirtz kontaktiert? Wäre vielleicht
ganz gut. Er ist beim LinuxTag in Berlin immer mit dabei - hat aber
ansonsten wohl viel anderes zu tun.
- In CMakeLists you can see that is possible now to set paths to
positions and frequencies files with:
-DSPECIAL_FREQUENCIES_FILE=fgcom-data/special_frequencies.txt
-DDEFAULT_POSITIONS_FILE=fgcom-data/positions.txt
Super wäre es, wenn diese auch als CMake Optionen von außen gesetzt
werden können - damit man das an sein System anpassen kann, ohne an den
Sourcen zu schrauben. Siehe Patch im Anhang.
Ansonsten habe ich für Linux noch die pthread Library hinzufügen
müssen. Eine saubere Lösung wäre wohl das irgendwie zu detektieren -
ggf. mal in die FG CMake Files reinschauen, und irgendwie abkupfern.
Mit dem Patch im Anhang hat es bei mir direkt funktioniert und fgcom
läuft einwandfrei. Das alte fgcom konnte ich nur auf meinem alten
Rechner laufen lassen (lansgsamer single core) - auf meiner modernen
6core Maschine lief das alte fgcom irgendwie nicht.
Gruß,
Thorsten
diff --git a/CMakeLists.txt b/CMakeLists.txt
index d599aae..63fd5dc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -298,8 +298,11 @@ add_definitions( -DSVN_REV=261 )
add_definitions( -DLIBVER=SVN 261 )
# for now follow like in OSX, in fgcom-data in the 'install' directory
-add_definitions( -DSPECIAL_FREQUENCIES_FILE=fgcom-data/special_frequencies.txt )
-add_definitions( -DDEFAULT_POSITIONS_FILE=fgcom-data/positions.txt )
+option( SPECIAL_FREQUENCIES_FILE Path to 'special frequencies' file. /usr/share/fgcom/special_frequencies.txt )
+option( DEFAULT_POSITIONS_FILE Path to 'default positions' file. /usr/share/fgcom/positions.txt )
+add_definitions( -DSPECIAL_FREQUENCIES_FILE=${SPECIAL_FREQUENCIES_FILE} )
+add_definitions( -DDEFAULT_POSITIONS_FILE=${DEFAULT_POSITIONS_FILE} )
+
if(ADD_DEBUG_OUTPUT)
add_definitions( -DDEBUG )
@@ -358,6 +361,7 @@ else(WIN32)
# DYNLIB=libiaxclient.dylib
else(APPLE)
if(UNIX)
+set( win_LIBS pthread )
# CFLAGS:= $(CFLAGS) -Iportaudio/src/os/unix
# DYNCFLAGS=-fPIC
# DYNLIB=libiaxclient.so
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCom - cmake
Ah well. You guessed the obvious... This was mainly meant for HB-GRAL. Anyway, an opportunity to learn some German! ;-) cheers, Thorsten Am 10.07.2012 20:52, schrieb ThorstenB: Am 10.07.2012 15:27, schrieb HB-GRAL: The last weeks Geoff McLane and me forked fgcom temporary at gitorious (http://www.gitorious.org/fgcom) and made some significant changes. Origin source is still available at http://sourceforge.net/projects/fgcom/ Schön wieder Fortschritte bei fgcom zu sehen. Und schön CMake + Git zu sehen ;-). Habt ihr auch mal Holger Wirtz kontaktiert? Wäre vielleicht ganz gut. Er ist beim LinuxTag in Berlin immer mit dabei - hat aber ansonsten wohl viel anderes zu tun. - In CMakeLists you can see that is possible now to set paths to positions and frequencies files with: -DSPECIAL_FREQUENCIES_FILE=fgcom-data/special_frequencies.txt -DDEFAULT_POSITIONS_FILE=fgcom-data/positions.txt Super wäre es, wenn diese auch als CMake Optionen von außen gesetzt werden können - damit man das an sein System anpassen kann, ohne an den Sourcen zu schrauben. Siehe Patch im Anhang. Ansonsten habe ich für Linux noch die pthread Library hinzufügen müssen. Eine saubere Lösung wäre wohl das irgendwie zu detektieren - ggf. mal in die FG CMake Files reinschauen, und irgendwie abkupfern. Mit dem Patch im Anhang hat es bei mir direkt funktioniert und fgcom läuft einwandfrei. Das alte fgcom konnte ich nur auf meinem alten Rechner laufen lassen (lansgsamer single core) - auf meiner modernen 6core Maschine lief das alte fgcom irgendwie nicht. Gruß, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.8.0: feature freeze starts now
Am 17.06.2012 21:14, schrieb Torsten Dreyer: today is June, 17th and this marks our feature freeze for the sources of SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being part of the base package are not part of the feature freeze. Maintainers for those aircraft are kindly requested to carefully check not to update _any_ file outside their individual aircraft's root directory. Brief update: Release 2.8.0 is still on downwind. We need people testing and fixing things though. * Curt has published the first release candidates for Windows, see: http://www.flightgear.org/download * Here's a list of things about how you could help: http://www.flightgear.org/forums/viewtopic.php?t=15136 * Also check the bug tracker, if you can help with any reported bug issue: http://code.google.com/p/flightgear-bugs/issues/list?q=-Type%3DFeatureRequest+-status%3ATesting * We also still need Italian, Spanish, Polish, Portuguese and German (oops!) volunteers translating the language resources: http://www.flightgear.org/forums/viewtopic.php?t=16876 Distance remaining is about 1 week to the release branch and about 6 weeks to touch down. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] upcoming release suggestion
Am 01.07.2012 05:52, schrieb syd adams: Before the next release , maybe it would be a good idea to disable those 'panel' outlines , which show up when you press 'C' to view hotspots. I don't think this was intentional. The outlines aren't even properly aligned on any aircraft I checked - so it just looks like a bug. And it's only visible on some aircraft. My guess is it only affects 2D elements - i.e. all the 2D map displays (radar/groundradar/maps) in glass cockpits. Also seems to be a relatively new issue - I hadn't even noticed before. Anyone knows when/how this started? Otherwise we'd need to check git commits. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.8.0: feature freeze starts now
Am 30.06.2012 15:02, schrieb Bertrand Coconnier: I don't know if it's only me, but all my efforts to match sg/fg/fgdata version were unsuccessful until I manually deleted src/Include/version.h in flightgear. After a complete rebuild and installation FlightGear was finally able to start but the above mentioned file was not restored ?!? version.h is generated whenever cmake runs. If you delete it, you need to call cmake again. It's also possible that a manual call to cmake is required after every version change, since we keep the version in a separate (non-cmake) file - which isn't really a standard solution. Either type your usual cmake command-line cmake , or enter your build directory and trigger a manual refresh/update of all makefiles using the most recent configuration with make rebuild_cache. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.8.0: feature freeze starts now
Am 17.06.2012 21:14, schrieb Torsten Dreyer: today is June, 17th and this marks our feature freeze for the sources of SimGear, FlightGear and FGDATA. Within FGDATA, only aircraft not being part of the base package are not part of the feature freeze. Maintainers for those aircraft are kindly requested to carefully check not to update _any_ file outside their individual aircraft's root directory. In order to prepare building the first 2.8.0 release candidate(s), we have now updated the simgear/flightgear/fgdata version in the git repositories - to version 2.8.0. Note, the release candidate sources are still in the frozen next branches (master for fgdata). On July 17th we'll move 2.8.0 to a separate branch, reopen next for development and bump its version again (to 2.9.0). See: http://wiki.flightgear.org/Release_plan (The version change was pushed to sg/fg/fgdata consistently. If you get a version mismatch, make sure you have pulled all three repos, rebuilt and _installed_ sg + fg. If you still get a version mismatch, try a clean build - and _install_.) cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
On 11.05.2012 10:21, Renk Thorsten wrote: The problem with that consequence is: As you switched all loops off, the Nasal part of Advanced Weather ceased to run completely and all that's left is the same cloud-generating functionality which is responsible for Basic Weather (C++ and shader work). If killing all Nasal did not solve the problems, then they can't be caused by Nasal, and porting to C++ will not fix them. Not quite true. A significant part of Nasal-related frame rate impact is caused by garbage collection. Its delay/jitter only depends on the number of Nasal objects and their references which need to be searched. Increasing the number of Nasal objects (code+data) existing in memory also increases the delay. The amount of Nasal code which is actually being executed only influences the g/c frequency, i.e. whether the effect is visible every few seconds vs several times per second. This is why we are loading large Nasal modules, like advanced weather, on demand only (= only when feature enabled). We're not unloading objects when disabling a feature though - this usually requires restarting fgfs. This should be remembered when comparing such features (i.e. restart fgfs after disabling advanced weather etc). cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG2.6.0 @ FreeBSD
Am 05.05.2012 10:25, schrieb James Turner: On 5 May 2012, at 09:00, Martin Spott wrote: Cool ! I'm checking the FreeBSD port almost every week, but until recently it's still been at 2.4, looks like this will change soon :-) Yep, if any CMake assistance is required, please just ask. Not sure the FreeBSD maintainer is reading here. Anyway, I think he's done. He offered his changes after completing the port, package is available here: http://www.freshports.org/games/flightgear/ @Curt: you can now also bump the FG version for the FreeBSD link on the FlightGear main download page to 2.6.0 ;-). cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Issue 717: Disabling advanced weather crashes the sim
Am 25.04.2012 12:50, schrieb Renk Thorsten: From my perspective, switching between GUIs runtime and trying to mix features is problematic input in the first place. My Agreed. And I don't think it was the intention of the current GUI to toggle between both dialogs, while keeping advanced (or basic) weather enabled. However, I'm not too happy with the current way of switching between the weather systems in general: I don't think normally advanced users understand the concept. This bug report/feature request (i.e. show METAR in basic weather dialog when advanced weather is enabled) shows the issue: users think they are toggling between a basic and an advanced _dialog_ (likely surprised by the basic dialog looking a lot more complex than the advanced dialog though). It's easy to miss that this actually switches between two completely different features: the basic vs advanced _weather system_ - in the same way as they can switch between 2D and 3D clouds. So, maybe we could find a better method of switching between the weather systems - though this isn't the main issue here. Using radio buttons or a drop-down list would be a more standard way to toggle between alternatives. Otherwise, just updating (and maybe moving) the button descriptions might already help (something like enable advanced weather system rather than just advanced weather, and disable ... rather than basic weather). inclination is if this needs to be hardened against problematic input to treat the usage of the '- Basic Weather' button as intention to leave Advanced Weather and just add a call to local_weather.clear_all(); to the code of the button which ends Advanced Weather when ending its GUI. That would leave Basic Weather still in disabled state though, so to go beyond I would need to save the state of Basic Weather at startup of Advanced Weather and write these parameters back when ending it. With the current GUI concept, I'd expect advanced weather to be disabled and basic weather to be enabled when I switch back from advanced to basic weather dialog. So adding your call to disable (and maybe another to properly enable basic weather) makes sense. But where should the METAR string be? My idea was that you can get it in-sim via the radio, or if you want to cheat there's always the property browser to look it up. Displaying it on the Advanced Weather GUI as well is also not really a problem if that's what people think should be done. Any opinions? Users (like me! :) ) probably want to see the METAR string in some dialog - not just in a property. I'd suggest to display METAR also in the advanced weather dialog. Or, maybe we can move METAR to a completely separate dialog (independent of advanced/basic weather). This would also shrink the basic weather dialog considerably (it's huge! ;-) ). And we could still add a tiny button to open the METAR dialog from the weather dialog(s). And we could have a METAR main menu item. Torsten(D) really needs to comment though... Also, after selecting 'Advanced Weather' then Shift-Esc restarting, clouds flash repeatedly and then segfaults .. only when Shift-Esc after selecting Advanced wetather Well, yes - a restart implicitly starts up Basic Weather again without terminating Advanced Weather and results in a fight between systems. Ok, so that's what's causing it. Once advanced weather is running, basic weather should stay disabled - even if the user resets/relocates. The issue might be a result of our generic method resetting all properties to their initial value on sim reset. We need to explicitly protect (exclude) those properties, which should not be affected (enable the properties' preserve flags). Which properties exactly enable basic weather? Again, I guess Torsten(D) should know (I'll give a bump shortly, unless he's reading this anyway ;-) ). Again, probably the best solution is to end Advanced Weather for good on restart (if anyone can tell me what property to tie the listener to?) because it's impossible to guess the cause for the restart - a restart at the same location would allow to keep the whole calculated cloud configuration and just leave it running and not restart Basic Weather, a restart at a different location however needs a lot of re-computation. I'm not sure whether that's the expected behaviour. Someone who opts to advanced weather probably wants to keep using it - even when he's resetting/relocating. Similar to switching between 2D or 3D clouds - you don't want to loose your selection on reset. Anyhow, you should tie a listener to /sim/signals/fdm-initialized This triggers on _every_ FDM reset, which is when the aircraft knows its new position. You could use this to disable advanced weather - though I'd prefer if you used it to reset and adapt the advanced weather system to the new location, while we sort out how to keep basic weather disabled. I just tried that one, but I didn't get the
Re: [Flightgear-devel] Random Buildings
Am 25.04.2012 13:35, schrieb Stuart Buchanan: Also, there is a significant slow-down in scenery loading. I can certainly confirm ;-). It's not just a longer delay for initial start-up (splash screen takes much longer to drop), it's also causing issues with scenery taking too long to be loaded at run-time, so the aircraft sometimes flies into a patch of void. It also seems to delay unloading of scenery tiles (noticeable when trying to shutdown). This reminds me of an issue we had a while ago, where we had a huge number of shared models (cattle and horses) scattered across the scenery. Something in OSG doesn't scale well with huge numbers - which only caused issues when trying to unload a scenery tile. Since loading and unloading is done in the same thread, this also caused the loader to almost stall. Not sure, if this could also be a factor here. At the time, the only solution we (mainly Tim) saw, was drastically reducing the number of shared models (cull the cattle... ;-) ). Another issue: the density range in the rendering dialog is 0-10. However, even with density 1.5 the buildings look pretty packed. For me, only a density of 0.17 is about usable (avoids the void scenery patch issue). This, however, is the lowest possible setting on the slider - and is very tricky to adjust (just try to configure such a low value, you'll see what I mean). Can we somehow change the slider to a lower range, e.g. 0-3? Not sure if higher values made any sense at all. Actually, I have the same issue with the vegetation density slider. Does the range 0-10 really make any sense to anyone? A lower range would make it much easier to configure usable values on the slider. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
On 23.04.2012 13:52, Christian Schmitt wrote: We could, if the xml parser would not simply discard any new runways that are not already in the apt.dat file. If I understood a comment of James in the bug tracker correctly, this, however, always has been and still is the normal behaviour, since these XML files were only intended to provide updated airport info, not introduce completely new ones (so it's not a new bug, as someone suggested). Also see below. The xml files are small, can be distributed easily and are very fine- grained, meaning that FG only has to parse the data it really needs for the current scenery path, instead of parsing a close-to 100 MB file on every startup (only for the apt data). I think we need the complete airport data in many places, i.e. when mapping the given start airport code to a starting position, to display the list of available airports in the selection dialog, to have data for the route manager, data for scheduling AI traffic, and for the Nasal interface to nav/airport data (which James is just updating these days). These probably all rely on a complete airport list being available straight away. So, we probably can't restrict things to the current display area. What may make sense is a better, non-compressed file format though, where we only load basic data (airport names/position/runways/...) at start-up, which would probably only require a few 100K. Later, we could go back into the (database) file and load additional data on demand, such as taxiway information, etc. (Which reminds of this http://developer.x-plane.com/2009/09/scalability-and-apt-dat/ ). If data needs to be loaded anyway (airport codes/positions), then distributing it to tons of individual files may not help with start-up delays either. James really needs to comment on nav data things though, since I never touched this area. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. You mean to put small apt.dat/nav.dat parts into these directories? Large even. This wasn't meant as a revolution to nav data handling. But it'd be one line of change to tell terrasync to sync another directory, and probably another one or two to change the search directory for apt.dat/nav.dat, so the terrasync directory was considered before the base package. This would only help with keeping terrasync scenery/nav data in sync. It wouldn't help with individual scenery packages. But I'm not sure if mixing nav data from different scenery packages is a good idea in the first place. At least I would like to have _one_ set of consistent, preferably very latest nav data available in FG. cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
On 18.04.2012 07:03, 刘先生 wrote: I'm confusing that when I use the FGrun,every time I select language from the Advanced Options(e.g. ,I input fr for French),the language of the FlightGear remains English.It remains the same Even when I use the command line to select the language(I input the command as fgfs --language=fr,the FG rans but the menu is still English). Could you please tell me anything about the reason? See http://code.google.com/p/flightgear-bugs/issues/detail?id=263 It's broken for a long time. Right now, only the language for the command-line help can be switched, not the language for the menu. cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Failed to select the language for Flightgear
On 18.04.2012 10:34, Gijs de Rooy wrote: Right now, only the language for the command-line help can be switched And even that appears broken now... Or is it just me and some fault in my home-built FG? Indeed. It got broken when the evaluation of command-line options was restructured. I'm adding this to the bug report... cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 14.04.2012 13:08, Stuart Buchanan wrote: I like the idea of resizing textures at model loading time a lot. The other option would be to switch the shader off. Presumably that would not load the normal map into the GPU. Shader textures are loaded unconditionally, at least into main memory. Hopefully GPU loading is optional - but I'm not sure. If someone was looking into improving the effect/texture loading code: it would be great if loading shader textures could be made optional, i.e. defer loading them until first access. As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Workaround: c172p on MacBook Pro with Intel HD3000
On 14.04.2012 15:18, Mathias Fröhlich wrote: Shader textures are loaded unconditionally, at least into main memory. Hopefully GPU loading is optional - but I'm not sure. Textures are loaded in main memory when the model that references them is loaded. Handing textures over to OpenGL is done once they are Right. But some of the global shaders always seem to be loaded. For example, start at LOWI. Doesn't matter whether shaders are enabled or disabled - you still get the warnings about the proprietary sea_foam.dds textures being loaded. Not sure whether it's really referenced by the scenery there - the sea should be really far away ;-). If someone was looking into improving the effect/texture loading code: it would be great if loading shader textures could be made optional, i.e. defer loading them until first access. Well, what do you mean with 'first access'? To somehow create the effect object when the model references it, but to defer loading the texture until the effect condition becomes true for the very first time - which is the moment when the texture is actually needed/accessed for the first time. This would keep the feature of being able to enable shaders at run-time, while avoiding to waste memory/CPU performance on loading unnecessary textures. As a hard work-around, we could also introduce a new command-line option to disable shaders support completely (enabling shaders at run-time via the dialog wouldn't work then). This would help those with weak GPUs/old systems - and reduce loading times and memory consumption. That's actually something I consider having. Also for different reasons. All the shader stuff is really nice but there are really use cases out there where it does not matter if the chrome is glossy or not. For them it's really most important that you get stable 60hz in *any* case. Which is still easier to get using the fixed function pipeline. So again still having that available would be good IMO. +1 cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] another segfault
Am 12.04.2012 16:50, schrieb syd adams: I've been updating the CitationX , and suddenly Im getting this error and the program segfaults. calc_bearing is not a finite number : Speed nanpos : nan, nanwaypoint 43.8071, 11.2006 waypoint name rotateSegmentation fault The segfault should be gone with latest Git. Just the result of the AIAircraft calling a hard exit - which isn't a good idea for a number of reasons. Now, you'll probably only get a bunch of error messages in the console (or another segfault somewhere else :) ). But the question for the root cause triggering the error message remains. Seems like some AI aircraft is missing a way point. Disabling AI traffic might avoid the issue. But if it really depends on some aircraft modification (like introducing the NavDisplay), then it could be the result of an ugly memory issue. If you can reproduce this, it's probably best if you provided your modified aircraft files (here or in the bug tracker) and someone starts digging with a debugger... cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] updates to nav.dat.gz
Am 10.04.2012 21:08, schrieb Martin Spott: And there's still one thing to consider: Having one central set of apt./nav.dat files in the Base Package still doesn't address the trend of the FlightGear project and Scenery development proceeding asynchronously. But to be honest, it neither works with central terrasync scenery. We could never push any updates (such as introducing terrasync scenery with the new EDDF runway) without immediately breaking consistency with all previously released FG versions (= their base packages). And we cannot expect all users to run the same FG version - or to even update their FG setups (base packages) on the same day. A bunch of Linux distros still haven't switched to FG 2.6.0... Since we somehow hard-code navigation data into the generated scenery tiles, it really makes sense to couple them closely. Terrasync already syncs a global /Models directory, so terrasync scenery can use newer or updated models. We could do the same for nav data. I'd be happy to extend terrasync to sync another global directory, i.e. /Nav (or /Nav810, /Nav850) and then extend FG to consider these directories first, before defaulting to (old) nav/airport/airway data from the base package - which then would only need to match the (old) base package scenery (i.e. before the users pulls terrasync data for the first time). This would avoid consistency issues, unless the nav data format itself changes - like it will with the 810/850 change. But this seems a less frequent event - hopefully not happening every 3 months or every year. It wouldn't help with any individual, regional scenery projects though: these could still rely on different, conflicting versions of nav data - and we can only load one version into FG. But we probably don't need to (nor could, maybe neither should ;-) ) address this anyway... cheers, Thorsten -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent GIT version fails to compile (fgadmin_funcs)
Am 07.04.2012 21:20, schrieb Björn Kesten: I think I've upgraded GCC to 4.7 recently, but for the life of me, I can't remember what else got upgraded that might have broken FG compilation. The drawback of running a rolling release system (Arch Linux)... The advantage is: you can beta-test FG compatibility with all the new packages rolling onto your system. ;-) #ifdef _WIN32 # includedirect.h # includeio.h #define unlink _unlink #define mkdir _mkdir #else // !_WIN32 #includeunistd.h #endif That worked! Thanks! Also in Git now. Thanks for testing... cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent GIT version fails to compile (fgadmin_funcs)
On 06.04.2012 19:07, Björn Kesten wrote: I hope this is the right place for GIT version related things. Certainly is ;-). utils/fgadmin/src/CMakeFiles/fgadmin.dir/fgadmin_funcs.cxx.o /home/bjoern/fg_git/sources/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx: In function ‘void remove_dir(const char*, void (*)(void*, int), void*, bool)’: /home/bjoern/fg_git/sources/flightgear/utils/fgadmin/src/fgadmin_funcs.cxx:363:39: error: ‘unlink’ was not declared in this scope Jenkins always builds the latest Git sources - and everything is fine there. Also, I cannot see anything that has changed about fgadmin in recent weeks, neither any change of the few includes it is using. So, it's weird if things suddenly changed for you. Seems like some change on your system... Furthermore, rmdir and unlink are standard POSIX functions and should be available in the global scope. Which compiler/version are you using? Have you upgraded recently? cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Git frame rate
On 06.04.2012 21:25, Heiko Schulz wrote: Nethertheless- perfomance has much increased now! :-) Depending on the aircraft I can get now 30-60 fps at noon with materials-dds.xml, trees and clouds with my standard settings. Likely related: a number of smaller performance improvements, but also two major boosts are in Git since a few days. They save CPU cycles - so are independent of GPU or particular graphics features (also independent of Rembrandt). The major boost affects a general part of the FG core, reducing the computations necessary for the environment by a large factor - which helps with all aircraft and settings. And there was another boost specific to YASim, speeding up its FDM computations considerably - so, overall, YASim aircraft gained most. There's a few more improvements pending with project frame rate ;-), but compared to FG 2.6.0, everyone should already see quite an improvement now. Or, of course, you can reinvest the saved computation time in shadows ;-). cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recent GIT version fails to compile (fgadmin_funcs)
Am 07.04.2012 15:33, schrieb Geoff McLane: #ifdef _WIN32 # includedirect.h # includeio.h #define unlink _unlink #define mkdir _mkdir #else // !_WIN32 #includeunistd.h #endif To make windows happy ;=)) and avoid some warnings... Yes, looks good. Indeed, I can't see how fgadmin includes unistd.h so far. Björn, let us know if this fixes your issue. I'd push this to Git, if it works. The really nice way to fix this though, would be drop the direct POSIX calls (unlink/remove) and use our simgear wrapper (simgear::Dir::remove) instead. Would remove another platform dependency from our sources. Then again, fgadmin isn't really a hotspot of current FG development ;-). cheers, Thorsten -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rembrandt - Some Feedback
With Rembrandt, brightness of the scenery seems to depend on the view's pitch angle a lot. So, when you fly along and pitch up/down heavily (take the ufo), you see the ground becoming brighter and darker. It mainly seems to affect the bright (non-shadow) areas. When pitching up, the ground eventually becomes as dark as the shadows (no contrast), while when pitching down, you see the ground being bright and only the shadows are dark: http://imageshack.us/photo/my-images/837/fgfsscreen.png/ cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Am 01.04.2012 18:25, schrieb Mathias Fröhlich: If you work with weak pointers/observer_ptr you need to use the lock method. Ok, you're absolutely right. I wasn't aware of the lock method before, indeed it has to be used here. I'll push a change. Thanks for reviewing this! cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching and other OSG issues
Hi, I've pushed a fix for a larger memory issue, mainly affecting effects/texture images, but also other objects. Once loaded, these stuck in memory until shutting down flightgear - so memory consumption was continually growing when flying larger distances. Probably wasn't much of an issue initially, when we only had few or generic textures. Now, with lots of custom models and eye candy, we obviously should be able to drop stuff again. We've discussed this about a year ago. Tim suggested using observer pointers instead of references in the cache maps. The discussed patch was never pushed to sg/next though, since I was running into stability issues with OSG 2.8.3. Since we don't support OSG 2.8.3 any longer, I've revived this again and changes are in simgear now. Keeps memory consumption a lot lower. I'm still seeing a slight memory growth when moving - but by far, it's not as bad as it was. Simple test is to relocate-on-ground to a series of airport locations and watch process memory. Mathias, maybe you can have a look at the simgear changes. Maybe you see a way to improve this even further - i.e. do we still need all these cache maps? Or could we simply rely on some OSG cache in some places? cheers, Thorsten Am 03.05.2011 21:49, schrieb ThorstenB: On Mon, Apr 18, 2011 at 9:55 AM, Tim Mooretimoor...@gmail.com wrote: On Sun, Apr 17, 2011 at 6:10 PM, ThorstenBbre...@gmail.com 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. 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 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Photo scenery patch: request for help
Not sure if this adds anything new, but digging in old email, I found Tim's review of the photo scenery patch from about a year ago. I'm not sure if the patch was updated since (or even if it's really the same at all), but there were two issues/questions then: 1. It unconditionally uses texture unit 3 in the terrain fragment shader even if no photo-realistic texture has been found. 2. It seems to blend the photo textures with the default material textures using the alpha value of the photo texture, but that isn't documented anywhere.. The purpose wasn't really clear then - i.e. why would you want to blend something photo realistic with a material texture in the first place. To get the patch into Git, Tim asked for the first issue to be fixed, so there was no impact unless photo textures were actually used. And he tried to discuss the second point. There wasn't any follow up/reply from the author though (at least, none that I'm aware of - which of course could just mean they switched to French ;-) ). cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Rembrandt] the plan
Am 25.03.2012 19:49, schrieb Frederic Bouvier: The Rembrandt renderer is enabled with the --enable-rembrandt option. *ALL SHADERS SHOULD BE SET TO OFF* unless someone want to begin to convert other shaders. Basically works here on Linux with proprietary Nvidia drivers. However, when I zoom in or out, large parts of the screen start flicking. Areas flicker between correct colors and bright green/red patches. Screenshot shows the effect: http://imageshack.us/photo/my-images/33/fgfsscreen046.jpg/ cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Change in failures.nas
Am 25.03.2012 00:46, schrieb Eugenio Mondini: I'd like to understand something that seems to affect only me. As you can see in the forum [0] after a recent fgdata update I couldn't use one plane because it checked against a property in failure-manager part of the tree, that was not appering for me. Once I understood more or less what was happening I reverted a part of the commit [1] only in the failures.nas file and it worked again. Oops, there was another change in my commit that wasn't supposed to be pushed. I somehow missed that. Try latest fgdata and see if it's back to normal now. The issue should have affected all aircraft using the failure module. Thanks for reporting. cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound questions
On 24.03.2012 00:29, syd adams wrote: I,ve noticed for awhile that sounds seem to cut off at the reference-distance rather than max-dist. Is there a new way to do the sound files that Ive missed or is this a bug ? It is nice that sounds actually stop now , but I must be doing something wrong .I've been attempting to fix all my sound files but things aren't working as expected. Erik should be able to give authoritative answers on sound, but AFAIK we're using the inverse distance clamped model for attenuation of all sounds. There's a graph showing how gain vs distance works in this mode - see this OpenAL spec (section 3.4.2): http://connect.creativelabs.com/openal/Documentation/OpenAL%201.1%20Specification.pdf Additionally, FG 2.6 introduced a new range check to free sound resources completely above maximum distance. That's a check that FG is doing itself - not done by openAL (so not shown in the openAL spec). So, how it should work altogether for FG is: Volume is clamped to a maximum below reference distance. Volume is attenuated above reference distance. Sounds are completely cut off above maximum distance (since 2.6). If you think it's not behaving as described, it's probably best if you gave an example. cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound questions
Am 24.03.2012 15:39, schrieb syd adams: I thought the volume was reduced to half at reference-distance That's actually what README.xmlsound still says - but I don't think that's right (it's not halved, but clamped at it's maximum at ref-dist). Maybe the description matched a pre-OpenAL implementation of our sound module and needs an update? Erik? cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Performance issue with sim reset vs Nasal
Hi,
I noticed an ugly issue with many of our Nasal modules. Not sure if
that's a result of changed behaviour years ago, or it's just a common
copy paste issue that just wasn't noticed so far.
Problem is, lot's of Nasal modules listen to the property
/sim/signals/fdm-initialized
to trigger some initialization code. It's fine to do so. However,
modules need to be aware that this signal triggers on _every_ simulator
reset. So, the connected code executes every time you hit Shift-ESC, use
the Relocate-in-air or Relocate-on-ground dialogs.
We had plenty of places were init code connected to
/sim/signals/fdm-initialized installed a fresh set of listeners or
started another timer-driven update loop. This results in performance
degrading with every sim reset.
The worst case scenario looks like this:
_setlistener(/sim/signals/fdm-initialized, func {
setlistener(/sim/foo, foo);
setlistener(/sim/bar, bar);
update_loop();
}
var update_loop = func {
...
settimer(update_loop,0);
}
= Initially 'foo' and 'bar' are called once whenever their respective
listener triggers. After the 2nd sim reset, they are called twice per
change, after the 10th reset they are called 10 times for each property
change.
Similar issue with update_loop: initially there's only one timer
running. After the 10th reset, there's already 10 concurrent loops...
I've fixed the issue in several places of our generic Nasal modules (so
this affected every aircraft). I've also fixed the issue for the C172
and B777 specific Nasal code. These aircraft are fine now - no
performance drop even after many sim resets. But I guess many more
aircraft suffer the same problem.
Anyway, if you ever wondered why performance is so bad with FG2.0-2.6
(not sure about earlier versions) after resetting the sim or relocating
the aircraft multiple times, you now know why ;-).
cheers,
Thorsten
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Missing texture files
Hi, after adding some proper error messages in the texture loader, I do see a number of missing texture files being reported. And they don't seem to be in fgdata. Anyone knows what's wrong here? Missing files or broken models/effects referring to incorrect files? Cannot find texture Terrain.winter/sand1.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/sand2.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/sand3.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/sand4.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/sand5.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/sand6.png in Textures or Textures.high folders. Cannot find texture Terrain.winter/golfcourse.png in Textures or Textures.high folders. cheers, Thorsten -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] auto-coordination
Am 09.03.2012 21:46, schrieb syd adams:
Hmmm another thought . Wouldn't setting that value to 0.0 still force
the rudder to center , still overriding other systems ?
No, since Torsten's suggested patch contained a condition
auto_coordination_factor-getDoubleValue() 0.0 ) {
so nothing changes at values = 0 ;-).
cheers,
Thorsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Two small weather issues
On 08.03.2012 19:21, Curtis Olson wrote:
I bet there's a line of code somewhere that looks like:
if ( visibility_meter 1000 ) {
do_sky_dome_stuff();
}
Ha, Curt, I know you cheated! You just looked at the code, right? ;-)
simgear/scene/sky/sky.cxx, SGSky::repaint:
if ( effective_visibility 1000.0 ) {
enable();
dome-repaint();
stars-repaint();
planets-repaint();
oursun-repaint();
moon-repaint();
cheers,
Thorsten
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] About the bug 385
Am 04.03.2012 00:09, schrieb jean pellotier: BTW, whitch OSG version do i have to use? last devel version is ok? Any version that reproduces the issue for you. If it still occurs with OSG trunk, then that's also interesting. If it wasn't, well, then you have a solution ;-). But I already have a suspicion on a timing/sequence issue inside FG itself, so OSG probably won't matter. cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 04.03.2012 19:00, schrieb Stefan Seifert: But whenever talking about git rebase one should mention that THOU SHALT NOT rebase a branch which you've ever pushed. Because if someone ever pulled your What I always do, before pushing an update for the next branch is: git checkout next git pull git rebase origin/next (likewise works with master or other branches). This rebases my local next branch - and places all my local changes on top of the history of the remote next branch (= origin/next). Also, this cannot change any history being already part of the published remote - since anything pushed to the server is already in origin/next, which remains unaltered (it's the base). branch (which happens with a simple git pull from the main repo), his get gets confused by the changed history. If someone managed to mess up the published history, he wouldn't be able to push to our gitorious repository though. Pushing a change of history requires a forced push, which is disabled for our gitorious repos. It's not a mistrust in anyone's git skills, but just to be really safe ;-). cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Project Rembrandt - next steps
Am 03.03.2012 12:43, schrieb Christian Schmitt: Stuart Buchanan wrote: IMO we should bite the bullet and get it into next this week if possible. There's obviously some risk to our 6 month release schedules that we'll just have to accept. I agree here. Let's merge the Rembrandt work into next so that every git user has to work with it, can find glitches and adapt shaders. There are people holding back their shader improvements in anticipation of Rembrandt. We have to merge it anyway sooner or later. Now, the likeliness of conflicts is lower and the speed of development will be faster. Just be sure the new concept will work for everyone, even for the majority not owning the latest high-end GPU, e.g there is an option to disable, reduce load/quality etc. Also, the project is quite good in finding issues, once new stuff is in git. But, generally we are not so good in fixing problems then. Notoriously, everyone has just too little spare time ;-), so a lot of issues just starve in the tracker. And with hard-core OSG stuff, there's even fewer people than usual who could help anyway. So, make an honest estimate of how much work is really left, including fixing reported issues, and whether you have the time to complete this in the next months. Or whether you maybe need to bail out in a few weeks for personal reasons, and we might be getting stuck (your wife/girlfriend isn't pregnant or something? :-D ). If we are certain that everything will be well and stable within reasonable amount of time, then it should go into next. Otherwise, we should think about maintaining separate branches (one of the main advantages of git anyway). Indeed, the latter would probably mean it would not be part of the August release. The key question is: would it be ready? cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] About the bug 385
Am 03.03.2012 03:28, schrieb Robert: 2012/3/2 ThorstenB bre...@gmail.com mailto:bre...@gmail.com But we don't know why this only happens with the ATI, only with their driver versions 11.5 and above, and only on Windows. Thorsten, this bug is also present on Linux (in my case), and I think I have read in the google bug-reports that OSX is affected, too. Never heard anyone reporting the issue for Linux. Indeed, there was a related bug for Mac (#356), but that was reported to be fixed with OSG 3.0.1, only leaving an ugly effect (whatever that is). Anyway, anyone reproducing the issue and capable of compiling FG 2.7.0/Git could help by providing the terminal output when running a debug patch, see #385, comment 41 for details: http://code.google.com/p/flightgear-bugs/issues/detail?id=385#c41 cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] About the bug 385
On 02.03.2012 00:29, jean pellotier wrote: http://code.google.com/p/flightgear-bugs/issues/detail?can=2start=0num=100q=colspec=ID%20Type%20Status%20Priority%20Summary%20Aircraft%20Milestonegroupby=sort=id=385#makechanges It appear in my setup that adding a radar section in the intrumentation.xml (or any name called by theinstrumentation field in the -set.xml file) solve the bug, for all the planes tested (b1900d, bo105, iar80, super constellation etc...) radar namewxradar/name number0/number /radar - is there some clue why the radar can have such an impact? - is it possible to add the radar section to the aircrafts in the base package affected by the bug, or do we have to buy nvidia again? See my comments at bug #385: For some people, removing the instrumentation section from aircraft fixes the issue (or renaming it, which is effectively the same). Otherwise, adding even more stuff to the section, such as the radar also seems to help. This could be a timing issue, since people seeing the issue obviously need to speed up or slow down the phase of initial aircraft loading. We already know that FG doesn't receive a Window resize event when the issue happens. But we don't know why this only happens with the ATI, only with their driver versions 11.5 and above, and only on Windows. One hope is that using a newer OSG library might fix the issue. The latest OSG release is still 3.0.1, but there have been a number of fixes to OSG, including the modules handling GraphicsWindows since. So, it'd be interesting if someone seeing the issue tested FG the latest OSG trunk version. If this doesn't help, then it really takes someone using a debugger and investigate what's happening to the resize event. In any case, randomly adding or removing stuff to aircraft files isn't a solution. Of course, it's ok for anyone to change things locally as a work-around, but nothing acceptable for FG in general. cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Odd message during latest CI build...
On 28.02.2012 18:02, Gene Buckle wrote: The error shown is related to CMake I think. Yes, it was. Result of incorrect syntax in simgear's cmakelist.txt. Should be fixed now - let me know otherwise. cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Jenkins thrashing...
On 28.02.2012 18:00, Gene Buckle wrote: Yes. I needed to use the machine.:) I've re-enabled the MSVC host. And I just triggered a rebuild for Windows/next. Hope the load stays low... I think the problem is that a build is redone every time fgrun is changed because there is no release branch, and it rebuilds everything because Jenkins touch files when it copies artifacts. One solution could be to split the task : one for building binaries, one for packaging. One thing I noticed it did is that it built windows-release, built two other packages and then built windows-release_again_. That's when I got really annoyed.:) History shows that all rebuilds were triggered for a reason - either due to fgrun changes or due to an update of the installer package itself. But see below... We really should create a separate fgrun/Release job: right now, the fgrun job depends on SimGear/next, though Windows/Release depends on fgrun. So, first of all, the fgrun binary in the Release installer isn't built with the correct simgear DLLs (it's was already build against the simgear/2.7.0 - which luckily/hopefully was still compatible to simgear/2.6.0 at the time of the release) - or am I missing something? Secondly, every SimGear/next change triggers an fgrun rebuild (as expected), but due to the fgrun dependency, it also triggered a rebuild of the Windows/Release job. Seems like we something we should improve :). Also, as suggested by Fred, splitting the (Windows) Release job itself into smaller jobs (simgear/flightgear/installer), makes a lot of sense... cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final 2.6.0 Release Preparations
Am 11.02.2012 10:40, schrieb thorsten.i.r...@jyu.fi: Best of all, the new features are based on user community requests, and not driven by economic incentives. Some of these features are already in the works for the next FG release [give continuity message about the development] That'd be suspiciously close to dishonest advertizing. I spend a fair share of my forum time explaining to angry/disappointed/overeager users that feature requests are suggestions which often end up being discussed, but more rarely end up being implemented, and rather that an army of eager developers waiting for features to be proposed, features usually get implemented if a developer is interested in implementing them (so the best strategy to get something done is to get a developer interested, not by just complaining...). As far as I am aware, the development is mostly driven by what developers are interested in, not by user community requests (which sort of makes sense in an all-volunteer community), and unless there is a formal commitment of core developers on the horizon to devote part of their time to work through feature requests, I would not advertize such a line - it's going to backfire on the project. +1 Every free, open source project is really driven by active community _participation_, not so much by (passive) user's _requests_. In general, it's not even a matter of economic incentives, though this may be the case with FG. But you can see it with Linux kernel development: loads of companies and individuals involved, all pushing the project forward - each with their own private fun or economic interests. What really matters to an OS project is the community effort and the option for everyone to get involved. Even if this results in the mentioned group hug :) - I think that'd be the really important point to stress, when hinting a comparison with MS Plight (oops, typo ;-) ). cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] linking errors with origin/next?
Am 11.02.2012 10:16, schrieb Scott Hamilton: I updated my git working directory to origin/next and am getting the following link errors, I'm not 100% sure that git is properly updating everything, I have done a make clean and make rebuild_cache on both simgear and flightgear. Is anyone else seeing these errors, or is my working directory really messed up? Looks like a local problem on your machine. You can always check with the build server: http://flightgear.simpits.org:8080/ If you're having a compile or link problem, but the lights for your platform are all green there (i.e. Windows/Linux/Mac, Release or Next), then you're very likely to have local issue. cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Final 2.6.0 Release Preparations
Am 11.02.2012 16:32, schrieb Ron Jensen: I found and fixed a potential NaN and Segfault in the JSBSim propeller code yesterday. It could be considered a blocking bug for 2.6 to me. Thanks, looks like a small and safe enough patch which we should push to the 2.6.0 branch. cheers, Thorsten -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version file check
On 07.02.2012 21:13, HB-GRAL wrote: Is it a good or bad idea for the FGx launcher to check against the version file if it is a valid fgdata folder AT ALL ? I will need some kind of check. Seems a good idea. Same check is hard-coded inside fgfs (of course, fgfs also requires correct content of the version file). So, if the user selected an fgdata folder not containing the file, you could tell the user right away - launching fgfs would fail anyway... cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Version file check
Am 07.02.2012 21:34, schrieb Curtis Olson: The main reason for a version check between the binary and the data is that we often make parallel changes to both (similar reason why we do a simgear minimum version check when compiling flightgear.) If there are version mismatches, things could break or act in weird or unexpected ways. A launcher might not be in the same category unless you use options that change between versions (this is possible, but happens a lot less often than other sorts of changes.) Right. Not sure what Yves' original intention were. I referred to the basic check if the version file is there _at all_ - such a check seems useful for a launcher. Restricting a launcher to a specific version number inside the file indeed wouldn't be a good idea. At least I'd like to keep using the same launcher for a variety of fgfs versions - 2.5.0, 2.6.0, 2.7.0 :). cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screen.nas FONT size
Am 31.01.2012 19:46, schrieb Torsten Dreyer: The liberation fonts are to be used with OSGText (check $FGDATA/Docs/README.osgtext). With OSGText, the font is rendered by OSG and you put text objects into the scenegraph just like any other 3d object. You can attach it to the world, your aircraft or you screen (which might be what you want). Or you could create a custom HUD with the necessary text labels (fixed text, or referring to string properties). You can configure a font for each label - and add a property condition to enable/disable specific labels. FG has so many ways... cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-builds] Build failed in Jenkins: Windows-release #296
Am 17.01.2012 23:48, schrieb Frederic Bouvier: Hi, The windows released is not supposed to be built with MSVC 9 using msbuild. We should use MSVC 10 and Cmake, so please ignore these build until they are converted. Regards, -Fred Right, I just created the fgmeta release branch - which triggered all Release build jobs on jenkins. But I've only updated the linux release build script to use CMake - hopefully the Linux-release job is successful now. Mac- and Windows-release still need to be taken care of - both require a switch to CMake. Frederic, James, you're taking care of these? cheers, Thorsten -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 69, Issue 9
On 15.01.2012 10:46, Erik Hofman wrote: GIT will het frozen January 17th except for bug fixes. This would be a bug-fix in my book. Of course, fixing licensing issues counts as a bug-fix. Git is frozen already (= bug-fixes only), we'll create the branch on January 17th to open the main branch for development again, while the release branch remains available for further bug-fixes (only!) until February 17th (http://wiki.flightgear.org/Release_plan). Please lets not make a huge fuss out of this issue: of course, everything in the Git repository needs to be under the GPL. If a file is not GPL-compliant, it must not be committed to Git, not even temporarily. If something has slipped in anyway, please fix the issue (remove or replace the file) and end the argument. cheers, Thorsten -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear writes autosave.xml
On 15.01.2012 15:59, Martin Spott wrote:
James Turner wrote:
On 14 Jan 2012, at 11:42, James Turner wrote:
While trying to find out about a different issue ('fgfs' not starting
at all) I noticed, that it still writes an autosave.xml into
${FG_ROOT} despite the fact that I've explicitly set
--prop:/sim/startup/save-on-exit=false
Now I'd like to learn wether someone is deliberately trying piss users
off or it this is just a bug ;-)
Just tested this and it seems to work for me (setting exactly that
argument - there's also explicit options: --disable-save-on-exit and
--enable-save-on-exit)
I just found out that I mixed $FG_ROOT and $FG_HOME. The autosave.xml
was written into $FG_HOME, not $FG_ROOT.
I typically set the properties directly via --prop:/... and I'm quite
sure that I picked the correct one because I matched it against
flightgear/src/Main/globals.cxx - and because I've been using
/sim/startup/save-on-exit successfully for ages to prevent FG from
creating a $HOME/.fgfs/ directory.
BUT, with a new build from todays GIT the autosave.xml doesn't get
written any more. Maybe it's been linked to the recent relative path
changes.
Speculating: what may have happened is that you had an invalid path in
your scenery or aircraft directory list, and also had disabled the
save-on-exit property only at the end of the command-line. fgfs first
reads preferences.xml, which enables save-on-exit by default. Then
it starts evaluating the command-line parameters one by one. Finding the
invalid scenery or aircraft path, it was exiting immediately (due to an
error, which has been fixed already), and never got to evaluate the rest
of the command-line, so save-on-exit remained enabled. May not have
happened if --disable-save-on-exit first was first in the command-line...
cheers,
Thorsten
--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ads Models with current OSG
On 11.01.2012 23:15, Olaf Flebbe wrote: Hi, does anybody have the same problem? Several Messages: Unknown Chunk: ***UNKNOWN*** (0xA08A) in fgfs output. Seems to be a diagnostic from the 3DS loader within OSG. I get this (and messy views) with current OSG, fgfs, fgdata choosing for instance aircraft MD11 or airport EHAM . Yes, see here: http://code.google.com/p/flightgear-bugs/issues/detail?id=543 It's an AI aircraft causing it (MD11), so it's visible frequently. Maybe someone could fix the model - or check why OSG doesn't like the model. cheers, Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear branch, next, updated. 59d400d58b082d583959eb8c27c3155eaa301888
Am 08.01.2012 16:11, schrieb Melchior FRANZ: On Sunday 08 January 2012 05:09:07 Flightgear-commitlogs wrote: commit 246feef85fedd548f2c198831d7d6e7e3be53e12 Author: ThorstenB FGNasalModelData isn't thread-safe. [...] It s*cks... ;-) It predates a separate model loader thread. If something sucks, it's an imcomplete loader thread implementation (apart from developers handing out grades without having much clue, that is). You shortened my commit message. The s*cks was not meant as a grade for FGNasalModelData or any of its authors. It was a final statement summarizing a larger issue as a whole. I had spent hours tracing sporadic memory corruption issues. These really s*ck, since they are not reliable to reproduce - and once you catch a corruption issue in the debugger, it's still difficult to find the origin. Of course, I have very little clue compared to you. You are right, as ever. However, despite being extremely little minded, I still knew that FGNasalModelData predates OSG. The part of my commit message, that you accidentally removed, also states that the issue was only introduced a short while ago, when the MP aircraft loading was moved to the separate loader thread. So, yes, things were fine before. And in the 'good old days' they were anyway. Melchior, yet again I deeply apologize if that commit has hurt your sensitive feelings. Sorry, sorry, sorry. It was not meant as a judgement of any of your involvement in FGNasalModelData, neither of your outstanding work on FlightGear, from the days when you still supported the project with useful contributions, instead of only digging through commit messages to find reasons to spill your poison. The legacy of your work is perfect and beyond any doubt. For the rest of the audience - here's the full commit message: http://www.gitorious.org/fg/flightgear/commit/246feef85fedd548f2c198831d7d6e7e3be53e12 commit 246feef85fedd548f2c198831d7d6e7e3be53e12 Author: ThorstenB Date: Sun Jan 8 13:28:49 2012 +0100 #553: MP-model-loading related segfault MP aircraft are loaded by a separate OSG thread (introduced after FG2.4.0). The OSG thread also calls the modelLoaded callback. However, we mustn't allow the OSG thread to call FGNasalModelData::modelLoaded directly: FGNasalModelData isn't thread-safe. There are obvious issues (_callCount++;), tricky issues like calling the Nasal _parser_ or creating hashes and modifying the global Nasal namespace. It doesn't use locks to protect against another thread executing a Nasal context or running garbage collection. It also executes Nasal code itself (the model's load hook), which we also cannot allow in a separate thread... This patch returns all Nasal parts of MP-aircraft loading (parsing, module creation, execution) to the main thread, while keeping the multi-threaded OSG part (loading of MP-aircraft model files itself). The same issue exists with scenery models (see other commit). To summarize with 2 words: It s*cks... ;-) -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release 2.6.0 git/fgdata aircraft maintenance
On 04.01.2012 13:39, Eric van den Berg wrote: I am not sure who the mig-15 maintainer (same as Vostok-1 problem?) is, AFAIK both aircraft are currently unmaintained as the original author has announced his leave. The ADF produces a left/right audio signal to indicate the NDB direction. It looks like this is done by mixing two stereo files, one with a left track only and one with a right track only. Correct solution is probably to change the position of the sound source for the left/right sound samples. Erik can probably give better hints. I can't take care of individual issues. I'll just take care of converting files, since otherwise there will be no sound at all. Anyone interested in fixing issues for specific aircraft is welcome to place a merge request / submit a patch - especially for abandoned aircraft. cheers, Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Release 2.6.0 git/fgdata aircraft maintenance
Hi, in preparation of the Release 2.6.0, two issues affecting Aircraft in fgdata will be fixed by a batch commit. Updates will be pushed to fgdata next week, so shortly before the 2.6.0 release branch is created. If you want to fix these issues for your aircraft yourself, you have to do it _now_ and push the update or merge request for your aircraft (before next Tuesday). * Issue #1 is stereo sound files. 98 aircraft are still affected by this issue - which is actually one more than when we discussed this in early December. Meanwhile, two aircraft were fixed (Sikorsky-76C and sopwithCamel), however, two new aircraft with the issue were added (Gloster-Whittle and Lockheed-Martin-FA-22A-Raptor). And we forgot to count the separated an2 last time... All aircraft affected by the sound issue (as of today) are listed here: http://pastebin.com/PLe3jk9Y and the full list of affected files: http://pastebin.com/uLA1Sj2C * Issue #2 is the deprecated JSBSim properties egt_deg... (instead of egt-deg...). These have triggered automatic warnings for more than a year. The issue only remains for 7 aircraft - which will also be fixed next week: 737NG600 737NG700 737NG800 737NG900 A380 Lockheed-NF104 fokker50 (Use grep -r /egt_ fgdata/Aircraft to see the remaining occurrences). If you want to resolve the issues of your aircraft yourself, see here for more info: http://wiki.flightgear.org/Aircraft_maintenance cheers, Thorsten -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Some More Detailed Scenery
Am 29.12.2011 06:43, schrieb J. Holden: At the same time I do not support the inclusion of some sceneries I've created in the main FlightGear repository, as users with lower-end machines may wish to use the vmap0 scenery over the more detailed ones - plus there is now a marked difference in scenery versions between scenery compatible with 2.4 and scenery not compatible with 2.4. The user should be allowed to choose. All valid points which need to be addressed, especially the compatibility issue. However, the current conclusion, that we therefore need many separate scenery projects, and should even actively proclaim the use of various external sources, doesn't sound right to me. Do these issues really mean that our central scenery project is limited for ever? Just in comparison: what would happen if Fred provided patches for the new shadow support on his private site only, Mathias did the same for HLA and OSG support, Torsten for the NAV radio and environment code etc. Then we create some central website listing all available patches, so people can choose (according to their hardware/performance/interests). And to make it easier for users: we create a large compatibility matrix, describing which patches fit seamlessly together, and which probably don't. That's a possible solution - but neither does that sound right to me... ;-) Results in the same nightmare that Oliver described for scenery. Instead we all contribute to a central Git repo and try to make features configurable - so you can disable 3D clouds, AI traffic, shaders, multiplayer, ... So we should also discuss other solutions for scenery. It'd be possible to abandon the current TerraSync server and switch to a new one. So, FG 0.1 - 2.4 users keep using existing scenery, while new developments (compatible with FG=2.6) are stored on a new central repository. Or we could extend the scenery project to provide two levels of scenery: a lower quality scenery for older FG versions/older machines, and a high quality version for new/powerful machines and recent FG versions (in a somehow separate directory structure). Maybe we have more options. But we need a _common_ solution for these issues here - and I don't think that the scenery compatibility issue was really discussed here yet (but I may be wrong). There'll always be some external scenery projects, same as there are external FG core or Nasal patches. That doesn't matter much as long as these are small compared to the work on the common project. But it gets to be real trouble when almost everyone works on his separate private projects, and therefore progress of the common project slows down significantly. So, rather than forking development into many little subprojects, and finding ways to better support these forks, we should find solutions, so that scenery developers keep joining forces and improve our common scenery world (uh, that sounds cheesy, right?). cheers, Thorsten -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-commitlogs] SimGear branch, next, updated. 54db2e0ab196b659e4297c0d93f088b2212409f5
Am 18.12.2011 20:13, schrieb James Turner: On 18 Dec 2011, at 16:44, Flightgear-commitlogs wrote: (rule #9: never believe a source code comment). Ah, but it used too, until I removed the Mac OS *9* supporting code :) Yes, I guessed it was some copypaste issue or some left-over. Actually reminded me of something (much worse) I recently found in a RL code review: // set flag to 1 SomeObject.SomeFunction.Flag = 0; ... the most useless comment ever - yet plain wrong at the same time. :) cheers, Thorsten -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound support broken by AI traffic
Hi Erik,
Am 12.12.2011 13:31, schrieb Erik Hofman:
I've implemented a mechanism to free OpenAL sources that are farther
away than max-distance (3km for the current AI models). This might solve
your problems, although it is not a one size fits all solution.
I'm still getting many error messages at EHAM - but it's better now.
It's starting ok and I'm hearing AI sounds. Nice :)
However, XML conditions for AI aircraft have no effect. All AI sound
samples are played unconditionally as soon as the aircraft is in range.
play once AI sound samples are also played continuously. I think it's
caused by an issue with your last update. Attached patch restores the
effect of the XML conditions for me - and also play once samples work
as expected. Not sure if that's the correct way to fix it though...
cheers,
Thorsten
diff --git a/simgear/sound/sample_group.cxx b/simgear/sound/sample_group.cxx
index bdc00ee..c24bb5b 100644
--- a/simgear/sound/sample_group.cxx
+++ b/simgear/sound/sample_group.cxx
@@ -414,8 +414,6 @@ void SGSampleGroup::update_pos_and_orientation() {
+ position[1]*position[1] + position[2]*position[2];
if (sample-is_playing() (dist2 max2)) {
sample-stop();
-} else if (!sample-is_playing() (dist2 max2)) {
-sample-play(sample-is_looping());
}
}
}
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound support broken by AI traffic
Am 12.12.2011 21:22, schrieb Erik Hofman: That's the problem of the AIModel code that models hardly any properties suitable for sound playback. Not in this case. I had experimented with the AI balloons. I have pushed this to fgdata now - you can use these for testing the issue I reported. Enable the balloon-demo: the balloons' burners now have a nice whoosh! sound. Burner light and sound are connected to the same property - so you should see the light come on and hear the sound at the same time. But currently the balloon's AI sound triggers all the time - so we just get a continuous roar (kind of worked with my patch - so I think the XML conditions are ok). cheers, Thorsten -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound support broken by AI traffic
On 12.12.2011 22:41, Erik Hofman wrote: Ok the only thing the code you proposed to remove does (or should do) is active the sample again when in-range again (distance smaller than max_distance). I've had another report that I suspect has something to do with the same section. If some one want to comment it out (or apply the patch) in the code please go ahead. I'm not at the proper pc right now and won't be able to do anything before tomorrow mortning (EU time). I think we can wait another day... And you may be right, without the line there seems to be an issue when flying back into the range of an AI aircraft - so looped sounds aren't (immediately) resumed. Still seems the current implementation triggers a bit too much... Btw, is there a way to influence the audio level of AI sounds? Would be nice if sounds could be muffled in inside views (i.e. cockpit/inside view), while they should have normal/higher volume in outside views (and there should be no difference for aircraft without a canopy of course). Sorry, if that's another feature request ;-). cheers, Thorsten -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Aircraft maintenance
Following up on the sound file maintenance discussion, I have created a Wiki page to collect information on aircraft maintenance. This is somehow connected to our FG release change log, however it also contains other issues: things that were detected/reported and should be adapted/fixed for aircraft. The idea is that this can be extended when we notice something that aircraft developers should consider. And it should be something that covers more than one FG release - since things aren't usually adapted so fast. http://wiki.flightgear.org/Aircraft_maintenance Maybe this is too organized, maybe this is an effort in vain. And maybe this is teaching pigs how to fly - but this is FlightGear, we already have a * flying Ogel, http://wiki.flightgear.org/Ogel * flying Santa, http://wiki.flightgear.org/Santa * flying Dutchman, http://goo.gl/Fgn8w * flying paper plane, http://wiki.flightgear.org/Paper_airplane * flying UFO, of course, http://wiki.flightgear.org/Ufo * even a Scottish Navaid System soon, http://goo.gl/m6X0W All sounds impossible, but apparently almost everything is possible with FlightGear. So maybe this helps a bit after all. And maybe we'll even have a flying FlightGear pig one day (anyone?)... cheers, Thorsten -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Stereo sound files and affected aircraft
Hi, latest fgfs rejects loading stereo sound files. I guess it's because stereo sounds don't really work with a 3D sound engine. Stereo files still somehow worked with older fgfs versions, at least they produced something audible, so few authors had noticed the issue so far, and hence we now have a large number of affected aircraft and files. I ran a batch job on fgdata to find stereo files. In total, we have 360 stereo sound files - that's almost 1/5th of our sound files (2039 sound files in total). The issue affects 97 aircraft. How do we want to proceed? Do aircraft maintainers convert their sound files individually? Or should we run a batch job to convert files? May not be a bad idea, since the last reported issue (attitude indicator caging) so far hasn't been fixed for single aircraft I reported (still 26 affected)... I also noticed there a few affected aircraft which are officially unmaintained (authors have left the project for good). We should fix the issue for the FG2.6 release, otherwise about 1/4 of all fgdata aircraft is affected by (partially) missing sound effects. And I guess we don't want to handle 97 individual bug reports in the tracker... Another option might be to change the sound code again, so that stereo files aren't rejected, and only a warning is produced. But that would still result in loads of user bug reports, and it wouldn't fix the actual issue. List of all affected fgdata aircraft below. Even further below, there's the list of individual stereo sound files which need to be converted... cheers, Thorsten 717 737-300 747-400 757-200 767-300 787 A-10 A-6E A320-family A340-600 A380 ASK13 ATR-72-500 Aichi-D3A AirCrane Airco-DH2 Allegro-2000 Arsenal-VG33 Avro-Lancaster BV-141 BV-170 Bell-222X Bell-P-39 Boeing-247 Bombardier-415 C130 CRJ-200 CRJ700-family Cessna-208-Caravan Cessna-421-Golden-Eagle Commonwealth-Ca-12 Convair-XFY-1-Pogo D510 D520 DG-101G DO-X DR400 Dauphin Deuche Diamond-Da42 Douglas-Dc3 Dromader F6F-Hellcat Fairchild-Metroliner Fokker-Eindecker-EIII Fw61 Gee-Bee Hurricane Jaguar Ka-50 Lightning Lionceau Lockheed-P38 Lockheed-Vega Lockheed1049h Long-EZ ME-209-V1 MS-406 MiG-15 MirageIII MirageIV Nakajima-B5N Nieuport-11 Northrop-P61 Northrop-xb35 PC-6 Pioneer-200 Polikarpov-I16 R44 RAF-S-E-5 RV-6A Short-Stirling Sikorsky-76C Spitfire Stearman Super-Etendard TU-95 Tecnam-P92 Tigre V22-Osprey VMX22-Osprey Vostok-1 YS-11 Zlin-50lx apache dc8-63 dc8-73 ec135 eurofighter f-14b fokker100 harrier mosquito rallye-MS893 sopwithCamel superguppySGT victor List of stereo sound files: ./Aircraft/717/Sounds/cabinalert.wav(STEREO) ./Aircraft/717/Sounds/flaps.wav (STEREO) ./Aircraft/717/Sounds/touchdown.wav (STEREO) ./Aircraft/737-300/Sounds/FastenSeatbelt.wav(STEREO) ./Aircraft/737-300/Sounds/Flaps.wav (STEREO) ./Aircraft/737-300/Sounds/touchdown.wav (STEREO) ./Aircraft/747-400/Sounds/FastenSeatbelt.wav(STEREO) ./Aircraft/747-400/Sounds/Flaps.wav (STEREO) ./Aircraft/747-400/Sounds/beeper.wav(STEREO) ./Aircraft/747-400/Sounds/climb.wav (STEREO) ./Aircraft/747-400/Sounds/descend.wav (STEREO) ./Aircraft/747-400/Sounds/engine-start.wav (STEREO) ./Aircraft/747-400/Sounds/touchdown.wav (STEREO) ./Aircraft/757-200/Sounds/cabinalert.wav(STEREO) ./Aircraft/757-200/Sounds/touchdown.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/arrival.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/climbing.wav(STEREO) ./Aircraft/767-300/Sounds/Cabin/descending.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/emergency.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/music.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/music2.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/pretakeoff.wav (STEREO) ./Aircraft/767-300/Sounds/Cabin/seatbelt.wav(STEREO) ./Aircraft/767-300/Sounds/touchdown.wav (STEREO) ./Aircraft/767-300/Sounds/whine2.wav(STEREO) ./Aircraft/787/Sounds/Flaps.wav (STEREO) ./Aircraft/787/Sounds/touchdown.wav (STEREO) ./Aircraft/A-10/Sounds/canopy-close2.wav(STEREO) ./Aircraft/A-10/Sounds/gau-8.wav(STEREO) ./Aircraft/A-10/Sounds/gun2.wav (STEREO) ./Aircraft/A-6E/Sounds/canopy-close2.wav(STEREO) ./Aircraft/A-6E/Sounds/gun2.wav (STEREO) ./Aircraft/A320-family/Sounds/cabinalert.wav(STEREO) ./Aircraft/A320-family/Sounds/flaps.wav (STEREO) ./Aircraft/A320-family/Sounds/touchdown.wav (STEREO) ./Aircraft/A340-600/Sounds/Flaps.wav(STEREO) ./Aircraft/A340-600/Sounds/captain.wav (STEREO) ./Aircraft/A340-600/Sounds/cruising.wav (STEREO) ./Aircraft/A340-600/Sounds/decending.wav(STEREO) ./Aircraft/A340-600/Sounds/emergency.wav(STEREO) ./Aircraft/A340-600/Sounds/music.wav(STEREO) ./Aircraft/A340-600/Sounds/music2.wav (STEREO) ./Aircraft/A340-600/Sounds/seatbelt.wav (STEREO) ./Aircraft/A340-600/Sounds/tenthousand.wav (STEREO) ./Aircraft/A340-600/Sounds/touchdown.wav(STEREO) ./Aircraft/A340-600/Sounds/whine2.wav (STEREO) ./Aircraft/A380/Sounds/Flaps.wav
Re: [Flightgear-devel] Stereo sound files and affected aircraft
Am 09.12.2011 13:43, schrieb Erik Hofman: On Fri, 2011-12-09 at 12:21 +, TDO Brandano wrote: I think the most compatible solution would be to either downmix them to mono, or convert them to two mono samples to be played concurrently but offset from their original position by an amount directly proportional to the distance from the cockpit. Personally I think they should be converted period. The waste 50% file size and make FlightGear look bad when showing off the nifty 3d audio capabilities (no Doppler, no 3d positioning, etc). But I am not going to update aircraft maintained by others and start another flamewar. I certainly also do not want a flame war. But we need to do something. Either have the aircraft sounds changed or change the sound code again. I find the current state with a 1/4 of aircraft at least partially broken is unacceptable for a release. And users will complain that FG2.6 has a regression, since these aircraft worked with FG2.4 (in fact, we already have related issues in the tracker from git/snapshot users). That would make FG2.6 look really bad - certainly worse than missing 3D/Doppler effects alone. But don't get me wrong: I'm certainly in favor of fixing the issue, so that we get the full 3D sound effects. I'd propose that aircraft maintainers have time to fix the stereo files themselves, say until early January. We're going to branch off the 2.6 release (fg/sg/fgdata) on January 17th. We could convert any remaining stereo sound files shortly before that, to make sure that FG2.6 doesn't mean a regression for many aircraft. I'm happy to run a batch job for conversion, that's no big deal. If any author does not want her aircraft fixed, let me know. I guess most authors don't really have a problem with such straight forward changes anyway. Maybe it'd be a good idea if authors, who really do not want their aircraft to be touched ever, not even for such straight forward fixes guaranteeing continued FG release compatibility, placed a specific file in their aircraft directories (such as .PRIVATE). That would make it easy to identify the no go areas, while other aircraft could still receive basic emergency maintenance from the community. Personally, I think it'd be ridiculous, if we knew about basic issues which are easy to fix, don't dare to do anything, and eventually release with lots of broken aircraft. cheers, Thorsten -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stereo sound files and affected aircraft
Am 09.12.2011 22:53, schrieb Roland Häder:
On Fri, 2011-12-09 at 18:29 +0100, ThorstenB wrote:
Here's a full list of sound duplicates:
http://pastebin.com/DvCT6AT9
Can you please release this file? Or is it possible to sent it to me
directly? I would like to cleanup some of my archives.
Find the script attached. The script does both - reports stereo files
and all duplicates. You need to run it in the directory you want to search.
Requires python. Is Linux only. Don't ask for documentation. Don't use
the bug tracker if it doesn't work. :)
cheers,
Thorsten
#!/usr/bin/python
import os
import string
def doShell(Command):
Pipe = os.popen(Command)
Lines = Pipe.readlines()
Lines = map(string.strip, Lines)
Pipe.close()
return Lines
def getSoundChannels(x):
Lines = doShell(soxi -c \+x+\)
if len(Lines)1:
return '1'
return string.strip(Lines[0])
def getMD5(x):
Lines = doShell(md5sum \+x+\)
if len(Lines)1:
return ''
return string.strip(Lines[0]).split()[0]
def getFileList(Pattern):
Lines = doShell(find -iname \+Pattern+\)
return Lines
def checkStereoFiles(FileList):
BadFiles = []
for FileName in FileList:
Channels = getSoundChannels(FileName)
if (Channels!='1'):
BadFiles.append((FileName,Channels))
BadFiles.sort()
BadAircraft = {}
print Stereo files:,len(BadFiles),/,len(FileList)
for (FileName,Channels) in BadFiles:
print FileName
Aircraft = FileName.split(/)[2]
BadAircraft[Aircraft]=BadAircraft.get(Aircraft,0)+1
AircraftList=BadAircraft.keys()
AircraftList.sort()
print Aircraft with stereo files:,len(AircraftList)
print string.join(AircraftList,\n)
def findIdenticalFiles(FileList):
Md5Dict = {}
for FileName in FileList:
Checksum = getMD5(FileName)
IdenticalFiles = Md5Dict.get(Checksum,[])
IdenticalFiles.append(FileName)
Md5Dict[Checksum] = IdenticalFiles
ChecksumList = Md5Dict.keys()
SortList=[]
for Checksum in ChecksumList:
SortList.append((len(Md5Dict[Checksum]),Checksum))
SortList.sort()
SortList.reverse()
for (Count,Checksum) in SortList:
FileNameList = Md5Dict[Checksum]
if (len(FileNameList)1):
print %i identical files, MD5: %s\n%s % (len(FileNameList),Checksum,string.join(FileNameList,\n))
FileList = getFileList(*.wav)
print Found,len(FileList),files.
checkStereoFiles(FileList)
findIdenticalFiles(FileList)
--
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sound support broken by AI traffic
Hi Erik et al, sound support is broken here (GIT of today). When I start with the UFO at an airport with AI traffic, e.g. KSFO, then I hear a roar for a few seconds during start-up - but then there is silence for the rest of the simulation. No sound when the UFO moves. On shutdown, I do get a few error messages like these: AL Error (sound manager): Invalid Operation at release buffer AL Error (sound manager): Invalid Operation at release buffer It's working fine when I start at some remote location which doesn't have AI traffic, i.e. ENSD. I commented out the new code in AIBase::update - and then sound is back to normal. However, the error messages (see above) are still there - so these could be unrelated. Anyone else seeing this issue? Any ideas? Another thing I noticed: The sound manager is the last remaining subsystem that is created and initialized at run-time (thanks to James for structuring all the other systems so far!). The sound manager is still initialized in the main loop, and it's done _after_ the scenery is fully loaded (about when the splash screen is withdrawn). However, at this time the first AI aircraft may already be loaded, initialized, updated... Hence, nothing guarantees that AI aircraft won't (try to) use the sound subsystem even _before_ this is properly initialized. Maybe this is already the reason for the issues I'm seeing. Maybe it'd be a good idea to make the sound manager a proper subsystem now, to make sure it's created and initialized with all the other subsystems - so even _before_ the mainloop is run for the very first time. Futhermore, since AI+MP traffic may now depend on sound, the sound manager should probably be initialized before the AI, traffic and MP subsystems now. I'm sure we can resolve these issues for the 2.6.0 release (well, we have to :) ), but it'd probably still be a good idea to also add a switch, so that the new AI sound effects can be disabled - for example on slower systems. cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound support broken by AI traffic
Am 02.12.2011 20:44, schrieb ThorstenB: sound support is broken here (GIT of today). When I start with the UFO Sorry, only checking the bug tracker now (yes, should have done that first :) ). Someone reported a related issue, different effect though: http://code.google.com/p/flightgear-bugs/issues/detail?id=501 cheers, Thorsten -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
