Re: [Flightgear-devel] World Scenery 1.0.1
On jeudi 30 octobre 2008, Ralf Gerlich wrote: Hello everybody! The World Custom Scenery Project is proud to finally present the long-awaited bugfix release V1.0.1 of the World Scenery. The scenery can currently be downloaded at http://mapserver.flightgear.org/Scenery We suggest that mirror provides fetch the release from there. Be sure to also download the shared models collection from http://scenemodels.flightgear.org/download/SharedModels.tgz and unpack the archive in your FGROOT folder. Outline of this mail: - Contents of the scenery - Acknowledgements - Base data - Airport data proposal Contents of the scenery --- In addition to the bugfix the release contains some very fine bits of custom scenery work, namely - 6 Caribbean islands plus Helgoland (John Holden, Christian Schmitt) - Revised ParisV2 scenario from http://helijah.free.fr/flightgear/scenery/ParisV2/ParisV2.htm (cleanup and import by Jon Stockill) - Taxiway signs at 6 airfields: KSFO, KBWI, KLVK, KRHV, TFFF, TJSJ - Major progress in crowding the Scenery with 3D models - by Alexis Bory, Gijs de Rooy, Alex Park, Christian Schmitt, Hugo Devon , Paolo Savini just to name a few of the many involved contributors; Acknowledgements The scenery was built on a quad-processor machine in San Diego with access provided to us by John Graham of Telascience. Jon Stockill and Martin Spott maintain the static scenery objects database at http://scenemodels.flightgear.org/ and provided the adjustments of the elevations in the objects DB. Curt Olson provided us with valuable hints as a long-time scenery builder and TerraGear development. Special thanks go to John Holden and Christian Schmitt, who by their work on manual digitizing of Landsat imagery in the Caribbeans and at Helgoland have helped us pushing the envelope of custom scenery in the official scenery release. We sincerely hope that by this newfound experience more people will go this way of improving the data in the landcover database. Base data - The scenery was generated with terragear-cs, the Custom Scenery version of TerraGear, available at http://mapserver.flightgear.org/git. Except for the obvious cases listed above the following base data was used: - landcover and line data: VMAP0, as available on http://mapserver.flightgear.org/ - airport data (apt.dat): as included in FlightGear Release 1.0 - elevation data: SRTM v2 3arcsec and 30arcsec data - static objects: current status of the FlightGear Static Scenery Database (http://scenemodels.flightgear.org/) as of 29th of October 2008 As apt.dat is distributed with the base package instead of the scenery itself we were unable to use up-to-date airport data. This scenery release is intended to serve as official scenery for the current FlightGear release and therefore its contents must be synchronized with the contents of the released base package. Airport data proposal - As an additional feature the release therefore contains airport data in an Airports-directory, based on a proposal of the Custom Scenery Project on decoupling airport data from the base package. The Custom-Scenery-Team is convinced that airport data related to the geometry of the scenery has its place in the scenery instead of the base package. Besides the easily updated static objects airports currently are the main scenery feature that is and should be in constant flux due to updates by users. Currently, the release-cycle of the base-package dictates the possible update cycle of airport data in the official scenery. This is a pity and ought to be changed. The proposal targeted a scheme which allows users to only download the airport data required for their desired area, while at the same time allowing easy access to the data with either the airport-ID or a position as key. Currently the apt.dat makes up nearly 5MB compressed, containing lots of data which is actually only needed by genapts, but not by FlightGear itself. With the v850 format of apt.dat - which we will hopefully be able to support in the future - this amount of superfluous data will increase. We therefore think that simply distributing apt.dat.gz together with each scenery tile might not be feasible anymore. Each 10x10-degree-tile contains only information about the airports contained in this tile, consisting of at most three XML-files per airport: ICAO.twr.xml, ICAO.threshold.xml, ICAO.parking.xml The ICAO.twr.xml-File contains the position(s) of the tower(s) associated with the airport in a PropertyList, presumably to be used for tower view positioning. The ICAO.threshold.xml-File contains the threshold positions of runways associated with the airport - two per runway - with heading and displacement information, again in a PropertyList. The ICAO.parking.xml-File contains the AI-network for the
[Flightgear-devel] Carriers and Wakes
Hello, Only for fun, i have tried to simulate some wakes with the Carrier Foch, which is available on CVS. It is supposed to be on a quiet sea. ( and full speed ) This is only an experiment ( with a lot of .osg scripts) which could be easily removed. I hope this won't be a 'CPU eater' . Here the snapshot http://pagesperso-orange.fr/GRTux/Foch_and-wakes.jpg and the original photo http://accel23.mettre-put-idata.over-blog.com/1/01/49/79//photo07.jpg BTW: sorry i could not get the same result with the osg.xml files -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
Hello, I have posted several months ago, a patch to complet the precipitation manager. So I send again a little patch to improve the preicipitation manager... Regards, Nicolas Le jeudi 30 octobre 2008 à 17:27 +0100, gerard robin a écrit : On mardi 21 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, robin424 wrote: Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers And modifying any parameters within preference.xml about precipitation don't change anything Cheers Again my question. Is it only me ? or does the Rendering options property are not longer operational with precipitation ? Is it hardcoded within FG ? cheers Again and again and again and again my question, No answer, ?? to me, two possibilities, nobody here, knows the answer OR my questions are too stupid to get any answer ( my feeling goes to that explanation ) -- Nicolas VIVIEN precipitation.diff.gz Description: GNU Zip compressed data - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
Hello, To complet my previous mail : [...] I have posted several months ago, a patch to complet the precipitation manager. So I send again a little patch to improve the preicipitation manager... [...] The patch is available on : http://www.progweb.com/precipitation.diff.gz This patch permits you to link the precipitation to rendering manager : ::: SGEnviro::get_precipitation_enable_state Regards, Nicolas VIVIEN Le jeudi 30 octobre 2008 à 17:27 +0100, gerard robin a écrit : On mardi 21 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, robin424 wrote: Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers And modifying any parameters within preference.xml about precipitation don't change anything Cheers Again my question. Is it only me ? or does the Rendering options property are not longer operational with precipitation ? Is it hardcoded within FG ? cheers Again and again and again and again my question, No answer, ?? to me, two possibilities, nobody here, knows the answer OR my questions are too stupid to get any answer ( my feeling goes to that explanation ) -- Nicolas VIVIEN - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
On samedi 01 novembre 2008, Nicolas wrote: Hello, To complet my previous mail : [...] I have posted several months ago, a patch to complet the precipitation manager. So I send again a little patch to improve the preicipitation manager... [...] The patch is available on : http://www.progweb.com/precipitation.diff.gz This patch permits you to link the precipitation to rendering manager : ::: SGEnviro::get_precipitation_enable_state Regards, Nicolas VIVIEN Le jeudi 30 octobre 2008 à 17:27 +0100, gerard robin a écrit : On mardi 21 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, gerard robin wrote: On lundi 20 octobre 2008, robin424 wrote: Hello, I can't avoid precipitation with the Rendering option menu , is it just me ? Cheers And modifying any parameters within preference.xml about precipitation don't change anything Cheers Again my question. Is it only me ? or does the Rendering options property are not longer operational with precipitation ? Is it hardcoded within FG ? cheers Again and again and again and again my question, No answer, ?? to me, two possibilities, nobody here, knows the answer OR my questions are too stupid to get any answer ( my feeling goes to that explanation ) Thanks , here, it will be the opportunity to test it. Raining and raining and raining beuh.:( Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-users] World Scenery 1.0.1
Hi Melchior, thanks for your feedback. I am taking this to the developers' list. To everyone else, I am referring to this mail on the users' list: http://sourceforge.net/mailarchive/message.php?msg_name=490C204E.7040405%40aon.at Melchior FRANZ wrote: The question is, however, if we don't want to put all airport data into one file, in which case the fourth dir level would be superfluous. Merging the tower and threshold files would be possible, but I would oppose merging them with the parking files for two reasons. Reason One is organisational: The parking files are based on direct manual work and are created directly by TaxiDraw, while the tower and threshold files are from the apt.dat. Combining them would mix automatically derived and manually generated content, making management of the data much more complex. I see strong arguments in favour of keeping the connection to apt.dat. Although currently the v810 files are not maintained any more by Robin Peel, we will eventually move on to v850 and then be synchronised with the X-Plane Community again. (BTW: There is an open position at the World Custom Scenery Project for implementing v850 in TerraGear ;-) ) I also do not see any chance in general to push an XML format to Robin Peel and the X-Plane-Community. Keep in mind that the files distributed with the scenery contain only a small fraction of the data contained in the apt.dat (which should already lead to an increase in speed). Taxiways, markings and other details are not re-distributed. For this kind of data, the current apt.dat-format is a good compromise between compressing the representation and making it user-editable. Reason Two is technical: The parking files are currently not in PropertyList format. I know that this has been subject of fierce discussion, which I have no interest in repeating. As long as nobody comes up with a patch making the AI code use a PropertyList format, converting the old files and informing me so that I can update TaxiDraw accordingly, we will probably also have a non-PropertyList-format for the AI files in the next FlightGear release. But then Reason One would still exist. Now it all boils down to the tower and threshold files. These are typically pretty small, so that the overhead for parsing two files instead of one file should be negligible. Further there should be very seldomly a case where we need the information from both files at the same time, e.g. when teleporting to another airport, thereby changing the tower view position. Merging them in time for the next release would mean that we'd have to do another scenery release. Such a release - with some further bugfixes regarding the terrain - is planned, but not before end of November due to time constraints on Martin's and my side (preparing to get my Ph.D. thesis submitted). If we were to make a release this year, this would leave not much more than three or two weeks for properly testing this change in the wild. If things go wrong on the scenery side, we might be just in time for the FlightGear release. So if there is a strong argument in favour of the changes you proposed, I'm open to such a last-minute change, but otherwise I'd rather leave the structure as it is. The last time we fixed scenery in the last minute we had a good share of chaos ensue (which happens to have been just about one year ago). I'd also like to add that a sample of the structure as proposed has been in the FlightGear data CVS for quite some time, containing data for the KSFO area, ready to be commented. IIRC this was also explicitly mentioned in the CVS logs. Cheers, Ralf -- Ralf Gerlich | World Custom Scenery Project Computer Scientist| http://www.custom-scenery.org/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] What happened to San Francisco ?
Looking at the new scenery, I am puzzled to see that models shifted horizontally. I understand why they moved vertically, although I took great care to place them at there right position. But something or someone decided to shake the whole town and repositioned building randomly. Here is an example : -OBJECT_STATIC emb-1-fb.xml -122.3997217 37.7947911 6.457184876 100 +OBJECT_STATIC emb-1-fb.xml -122.399722 37.794722 22.2 100 -OBJECT_STATIC emb-2-fb.xml -122.3985954 37.79493693 4.411412125 100 +OBJECT_STATIC emb-2-fb.xml -122.397778 37.795 13.75100 -OBJECT_STATIC emb-3-fb.xml -122.3975217 37.79508277 3.651058775 100 +OBJECT_STATIC emb-3-fb.xml -122.397222 37.795278 8 100 -OBJECT_STATIC emb-4-fb.xml -122.3962899 37.79524943 2.492505501 100 +OBJECT_STATIC emb-4-fb.xml -122.396111 37.795278 15.49100 excerpt of 942066.stg, diff between rev 1.3 and 1.11 First 2 numbers are longitude and latitude, and everyone can see that the difference is quite significant. Is it agressive rounding from the export routine, or the real position is screwed in the database ? Looking at http://scenemodels.flightgear.org/objects.php?model=84 I am afraid the second hypothesis is the right one. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Corrected joystick description file (Saitek Aviator)
Hi,
The file data\Input\Joysticks\Saitek\Aviator.xml did not recognize my
new Saitek Aviator because its identifying name does not match the name
given by my device (it's Saitek AV8R Classic Stick when the XML file
says Saitek AV8R Joystick.
Changing that name makes FG recognize the stick but several axes and
buttons are switched: the axes and button numbers in the file are wrong
with respect to my joystick.
I made a corrected XML file which is here attached and works correctly
with my Aviator joystick. I don't know if the original was wrong or
there are variants of the device with a few modifications.
Regards,
Alvaro
?xml version=1.0 ?
!-- $Id: Aviator.xml,v 1.2 2007-12-13 18:30:55 mfranz Exp $ --
!-- Saitek AV8R/Aviator
Copyright (C) 2007 Anders Gidenstam (anders(at)gidenstam.org)
This file is released under the GPL license.
--
PropertyList
nameSaitek AV8R Classic Stick/name
data
modifier type=boolfalse/modifier
quick-view-active type=int0/quick-view-active
/data
nasal
script
![CDATA[
var self = cmdarg().getParent();
var data = self.getNode(data);
var modifier= data.getNode(modifier);
var quick_view_active = data.getNode(quick-view-active);
var old_view= view.point.save();
var pressed = [0,0,0,0,0,0,0,0,0,0,0,0];
var goal_heading_offset =
props.globals.getNode(/sim/current-view/goal-heading-offset-deg, 1);
var goal_pitch_offset =
props.globals.getNode(/sim/current-view/goal-pitch-offset-deg, 1);
var kbdshift = props.globals.getNode(/devices/status/keyboard/shift, 1);
var kbdctrl = props.globals.getNode(/devices/status/keyboard/ctrl, 1);
var kbdalt = props.globals.getNode(/devices/status/keyboard/alt, 1);
var quick_view = func {
dir = arg[0];
if (dir == 0) {
quick_view_active.setIntValue(0);
view.point.move(old_view, 0.1);
} else {
if (quick_view_active.getValue() == 0) {
quick_view_active.setIntValue(1);
old_view = view.point.save();
if (dir == 1) {
goal_heading_offset.setDoubleValue
(getprop(/sim/view/config/left-direction-deg));
goal_pitch_offset.setDoubleValue
(getprop(/sim/view/config/pitch-offset-deg));
view.fovProp.setDoubleValue
(getprop(/sim/view/config/default-field-of-view-deg));
} if (dir == 2) {
goal_heading_offset.setDoubleValue
(getprop(/sim/view/config/right-direction-deg));
goal_pitch_offset.setDoubleValue
(getprop(/sim/view/config/pitch-offset-deg));
view.fovProp.setDoubleValue
(getprop(/sim/view/config/default-field-of-view-deg));
} if (dir == 3) {
goal_heading_offset.setDoubleValue
(getprop(/sim/view/config/front-direction-deg));
goal_pitch_offset.setDoubleValue
(getprop(/sim/view/config/pitch-offset-deg));
view.fovProp.setDoubleValue
(getprop(/sim/view/config/default-field-of-view-deg));
} if (dir == 4) {
goal_heading_offset.setDoubleValue
(getprop(/sim/view/config/back-direction-deg));
goal_pitch_offset.setDoubleValue
(getprop(/sim/view/config/pitch-offset-deg));
view.fovProp.setDoubleValue
(getprop(/sim/view/config/default-field-of-view-deg));
}
}
}
}
var trace = func(str) {
# Uncomment the line below to trace button presses.
#print(AV8R.xml: ~ str);
}
]]
/script
/nasal
!-- Analog axis 0. Aileron --
axis n=0
descaileron/desc
binding
commandproperty-scale/command
property/controls/flight/aileron/property
dead-band type=double0.01/dead-band
offset type=double0.0/offset
squared type=booltrue/squared
/binding
/axis
!-- Analog axis 1. Elevator --
axis n=1
descelevator/desc
binding
commandproperty-scale/command
property/controls/flight/elevator/property
dead-band type=double0.01/dead-band
offset type=double0.0/offset
factor type=double-1.0/factor
squared type=booltrue/squared
/binding
/axis
!-- Analog axis 3. Rudder --
axis
number
unix3/unix
mac2/mac
windows3/windows
/number
descrudder/desc
binding
commandproperty-scale/command
property/controls/flight/rudder/property
dead-band type=double0.01/dead-band
offset type=double0.0/offset
factor type=double1.0/factor
/binding
/axis
!-- Analog axis 2. Throttle 1 --
axis
number
unix2/unix
mac3/mac
windows2/windows
/number
descthrottle/desc
binding
commandnasal/command
scriptcontrols.throttleAxis()/script
/binding
/axis
!-- Analog axis 4. Throttle 2 --
axis n=4
descmixture, +mod: propeller pitch/desc
binding
commandnasal/command
script
if (!modifier.getValue()) {
controls.mixtureAxis();
} else {
controls.propellerAxis();
}
/script
/binding
/axis
!-- Axis 5. Hat
Re: [Flightgear-devel] Corrected joystick description file (Saitek Aviator)
On Sat, 1 Nov 2008, Bora wrote: Hi, The file data\Input\Joysticks\Saitek\Aviator.xml did not recognize my new Saitek Aviator because its identifying name does not match the name given by my device (it's Saitek AV8R Classic Stick when the XML file says Saitek AV8R Joystick. Changing that name makes FG recognize the stick but several axes and buttons are switched: the axes and button numbers in the file are wrong with respect to my joystick. I made a corrected XML file which is here attached and works correctly with my Aviator joystick. I don't know if the original was wrong or there are variants of the device with a few modifications. Hi, Are you using FlightGear 1.0.0 ? The version of the Aviator configuration in that release had only been tested on Linux - and the axis numbers differ between OSes. It also includes a name line for the alternative name (mine reports the name in the old file :). The version currently in CVS has been tested and worked on Linux, Windows and (IIRC) Mac OS. The file here has a few updates (for airship piloting) over the one in CVS: http://www.gidenstam.org/FlightGear/misc/Saitek_Aviator/Aviator.xml Could you try the current config and see if it correctly handles your stick? Yours might be a different version from the ones we have encountered before.. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
On Sat, 2008-11-01 at 18:22 +0100, Nicolas wrote: Hello, I have posted several months ago, a patch to complet the precipitation manager. So I send again a little patch to improve the preicipitation manager... Regards, Nicolas I've had this patch installed for a long time. Works for me... jentRon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] What happened to San Francisco ?
Hi Frederic, Frederic Bouvier wrote: Looking at the new scenery, I am puzzled to see that models shifted horizontally. I understand why they moved vertically, although I took great care to place them at there right position. But something or someone decided to shake the whole town and repositioned building randomly. Here is an example : -OBJECT_STATIC emb-1-fb.xml -122.3997217 37.7947911 6.457184876 100 +OBJECT_STATIC emb-1-fb.xml -122.399722 37.794722 22.2 100 This certainly should not have occurred. I'm unable to give you a reasonable explanation right now, but I promise to check how this might have happened. Aside from that, we'll certainly be able to fix the positions according to CVS/GIT history. Thanks for reporting, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Rendering option /Precipitation
2008/11/1 gerard robin [EMAIL PROTECTED] Thanks , here, it will be the opportunity to test it. Raining and raining and raining beuh.:( Well, it's actually raining and raining here in SF :/ Alexis, (who is spending its vacations under the west coast rain...) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
