[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-03_07:21:24 (mfranz) /var/cvs/FlightGear-0.9/source/src/AIModel/submodel.cxx degrade "found path" SG_ALERT to SG_INFO =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_14:22:33 (mfranz) /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/models/propulsion/FGPropeller.cpp backport from JSBSim/cvs: apply prop sense only once (OK'ed by JSB) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_04:57:53 (mfranz) /var/cvs/FlightGear-0.9/source/src/Scripting/NasalSys.cxx add runway number as "id" to the runway hash within an airport hash (It's already available as runway hash key, but the runway hash shouldn't depend on it and be self-contained.) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-06_12:04:17 (mfranz) /var/cvs/FlightGear-0.9/source/src/Model/acmodel.cxx tell *why* loading a model failed =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-06_12:32:45 (mfranz) /var/cvs/FlightGear-0.9/source/src/Model/modelmgr.cxx - move exception handling from init() and childAdded() to add_model() - tell why loading a model failed =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-07_07:03:57 (timoore) /var/cvs/FlightGear-0.9/source/src/MultiPlayer/multiplaymgr.cxx Check for valid multiplayer packet. Instead of just reporting that the magic number, length, etc. of a multiplayer packet is invalid, abort processing this packet. Also, check if enough space remains to send a property string. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-08_03:49:15 (mfranz) /var/cvs/FlightGear-0.9/source/src/MultiPlayer/multiplaymgr.cxx add some generic properties for free use =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-08_16:13:04 (mfranz) /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.cxx /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.hxx /var/cvs/FlightGear-0.9/source/src/AIModel/AICarrier.cxx /var/cvs/FlightGear-0.9/source/src/AIModel/AICarrier.hxx Tatsuhiro NISHIOKA: Finally I found the cause of DList stack overflow and off-carrier aircraft problem. The cause of the first one is that aip.ssgTransform of AICarrier are unexpectedly registered on every reset in AIBase::init(). The second one is caused by ssgEntry related code in AICarrier::init(). So I made a patch for doing these process only in the first init() calls. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-08_16:37:24 (mfranz) /var/cvs/FlightGear-0.9/source/src/AIModel/submodel.cxx noise-- 2f585eeea02e2c79d7b1d8c4963bae2d - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] 3d instruments
Hi everyone , I ran into another issue , just wondering what everyone else's opinion is on the matter. I,ve been updating the Bravo , and the Primus 1000 instruments and controllers are in the Aircraft/Instruments-3d folder. I assumed that this is the place all 3d instruments should go ... preventing unneccesary duplication , but if the aircraft is a separate download , this could be a problem . Unless of course , those instruments are added to the download package . I guess my question is , should the 3d instruments stay in each Aircraft folder , or the Instruments_3d folder. I have done it both ways , but I think if we get enough accurate 3d instruments in the Instruments_3d folder , assembling a 3d panel should become easier as time goes by ... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-03_01:04:00 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/A-10/Sounds/altitude.wav Alexis BORY: - New audio warning "Altitude-altitude..." - Fixed 2 bugs in the VHF and removed another "settimered" loop. - Added switches to the fuel control panel, in prevision of changes to the fuel system. - Fixed hexausts. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-03_01:18:24 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/clock/M877/M877.nas /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/clock/M877/m877-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/mfd-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/mfd.ac /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/pfd.ac some nasal var and error fixes ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-03_01:28:21 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Models/annunoff.rgb finished off the annunciator panel ... Replaced M877 clock with my Instruments-3d version... Fixed some instrument lighting ... Added the ground idle operation , defaults to NORM ,as it should , can only be shut off via the property browser until I add the switch... Corrected the N2 idle rpm , 45.5% grd idle , 49.5% flight idle , although this seem to vary every startup ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-03_01:28:23 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Citation-Bravo/Panel/throttle-panel.xml finished off the annunciator panel ... Replaced M877 clock with my Instruments-3d version... Fixed some instrument lighting ... Added the ground idle operation , defaults to NORM ,as it should , can only be shut off via the property browser until I add the switch... Corrected the N2 idle rpm , 45.5% grd idle , 49.5% flight idle , although this seem to vary every startup ... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_06:36:51 (mfranz) /var/cvs/FlightGear-0.9/data/Input/Joysticks/Saitek/X52-pro.xml Arvid NORLANDER: Saitek X52 pro driver =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_10:39:15 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/Malolo1/Attic/Malolo1_splash.rgb add a custom splash screen. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_10:40:50 (curt) /var/cvs/FlightGear-0.9/data/Aircraft/Malolo1/Malolo1-splash.rgb Ooops spelling error. :-( =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_15:32:39 (jons) /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/strobe-red.osg /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/strobe-red.xml /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/strobe-white.osg /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/strobe-white.xml Add red and white strobes =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-04_23:13:51 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/AP-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/ric-hotspots.xml Added hotspots for the autopilot and remote instrument controllers =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_00:18:49 (sydadams) /var/cvs/FlightGear-0.9/data/Aircraft/Instruments-3d/primus-1000/AP-hotspots.xml disabled autopilot on ground... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_07:39:19 (dfaber) /var/cvs/FlightGear-0.9/data/Aircraft/fw190/fw190.jpg added a thumbnail =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_07:40:01 (dfaber) /var/cvs/FlightGear-0.9/data/Aircraft/spitfireIX/spifireIX.jpg added a thumbnail =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_16:37:08 (jons) /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-green.ac Add navigation lights =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_16:37:09 (jons) /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-green.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-green.xml /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-red.ac /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-red.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-red.xml /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-white.ac /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-white.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Grob-G115/Models/navlight-white.xml Add navigation lights =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2007-12-05_16:54:09 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Nasal/buccaneer-obs-utils.nas /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Nasal/buccaneer-utils.nas /var/cvs/FlightGear-
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-02_03:33:38 (durk)
/var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx
Torsten Dreyer: Make sure 3D clouds cache never gets set to zero, thereby
preventing a program crash that could occur when switching between OSG and
plib versions.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-02_06:28:30 (fredb)
/var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj
Update MSVC 7.1 projects
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-03_04:46:41 (mfranz)
/var/cvs/SimGear-0.3/source/simgear/scene/model/shadowvolume.cxx
let use of deprecated "noshadow" prefix cause error message
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-03_06:46:44 (mfranz)
/var/cvs/SimGear-0.3/source/simgear/scene/model/shadowvolume.cxx
print full object name in noshadow deprecation error message
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-03_10:38:30 (mfranz)
/var/cvs/SimGear-0.3/source/simgear/scene/model/shadowvolume.cxx
make the "noshadow" prefix SG_ALERT an SG_WARN
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-04_16:38:40 (timoore)
/var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj
Don't modify OSG Registry with file path
To set a path when loading model files, use an osg ReaderWriter::Options object.
Put locks in ModelRegistry::readNode and ModelRegistry::readImage to avoid
conflicts when files are loaded from both the pager and the main thread.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-04_16:38:41 (timoore)
/var/cvs/SimGear-0.3/source/simgear/misc/PathOptions.cxx
/var/cvs/SimGear-0.3/source/simgear/misc/PathOptions.hxx
/var/cvs/SimGear-0.3/source/simgear/scene/model/ModelRegistry.cxx
/var/cvs/SimGear-0.3/source/simgear/scene/model/ModelRegistry.hxx
Don't modify OSG Registry with file path
To set a path when loading model files, use an osg ReaderWriter::Options object.
Put locks in ModelRegistry::readNode and ModelRegistry::readImage to avoid
conflicts when files are loaded from both the pager and the main thread.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-06_11:57:46 (mfranz)
/var/cvs/SimGear-0.3/source/simgear/props/condition.cxx
- comparison: don't crash if second element is missing
- better messages ("panel"?!)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
2007-12-08_05:07:39 (fredb)
/var/cvs/SimGear-0.3/source/simgear/scene/sky/cloudfield.cxx
Fix a typo
2f585eeea02e2c79d7b1d8c4963bae2d
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] B1900d engine sounds
I had noticed the problem with the engine sounds a couple weeks ago, but now I have all the sounds again after a cvs update. I haven't noticed any issues with the avionics. You have to flip a switch to turn them on, maybe you just didn't notice it? On Dec 8, 2007 1:36 PM, Durk Talsma <[EMAIL PROTECTED]> wrote: > Just a quick observation. While testing the B1990d this afternoon, I found > that I didn't hear any engine sounds. I also found the aircraft about half > active upon initialization. That is, the engines were running, but the > avionics were off. Bug or feature? :-) > > Anyway, since this aircraft is listed as a candidate for the base package, > it'd be great is somebody could have a look. > > Cheers, > Durk > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
I think it would be better to replace the pa28-161 with the pa24-250, as the pa28 is similar in type to the c172. Also, Durk has pointed out a problem with the sound in the b1900d that should probably be fixed before a release. On Dec 8, 2007 7:57 PM, gerard robin <[EMAIL PROTECTED]> wrote: > On sam 8 décembre 2007, Ralf Gerlich wrote: > > Hi Gerard! > > > > gerard robin wrote: > > > Thanks , but NO > > > Catalina and Blackbird are on only under construction. > > > There is a lot of stuff to do , cockpit and FDM (mainly Blackbird > which > > > is wrong), > > > My to do list is long like the bible :) > > > Nothing valuable to be released "Production" > > > > Just today I had a (first) closer look at the models of the Catalina, > > trying to figure out what you are doing differently than me so that your > > models look so fine. I would be a lucky guy if my modelling skills were > > so good that I could imagine potential for improvement in these models, > > implying that _these_ models are not yet "Production" status ;-) > > > > Yes, I saw you were talking about the cockpit and the FDM, not the > > models, but I just wanted to get this item of "well done to Gerard!" off > > my TODO-List ;-) > > > > Cheers, > > Ralf > > > > Hello Ralf, > > Thanks for the flowers :) > Anyhow here we can find many others creators who have a high level of > modelling skill (better than i can). > > And, wasn't it said, here, that the eye candy is not enough ? > > Cheers > > > -- > Gérard > http://pagesperso-orange.fr/GRTux/ > << Less i work, better i go >> > > > - > SF.Net email is sponsored by: > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On sam 8 décembre 2007, Ralf Gerlich wrote: > Hi Gerard! > > gerard robin wrote: > > Thanks , but NO > > Catalina and Blackbird are on only under construction. > > There is a lot of stuff to do , cockpit and FDM (mainly Blackbird which > > is wrong), > > My to do list is long like the bible :) > > Nothing valuable to be released "Production" > > Just today I had a (first) closer look at the models of the Catalina, > trying to figure out what you are doing differently than me so that your > models look so fine. I would be a lucky guy if my modelling skills were > so good that I could imagine potential for improvement in these models, > implying that _these_ models are not yet "Production" status ;-) > > Yes, I saw you were talking about the cockpit and the FDM, not the > models, but I just wanted to get this item of "well done to Gerard!" off > my TODO-List ;-) > > Cheers, > Ralf > Hello Ralf, Thanks for the flowers :) Anyhow here we can find many others creators who have a high level of modelling skill (better than i can). And, wasn't it said, here, that the eye candy is not enough ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ << Less i work, better i go >> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
Hi Melchior,
Melchior FRANZ schrieb am 08.12.2007 17:08:
> * Melchior FRANZ -- Saturday 08 December 2007:
>
>> it was time to add some generic properties for "internal communication".
>>
>
> It's probably also time to remind people again of the possibility to
> add Nasal code to model (animation) XML files. This is then only
> run when the model is used as as a static scenery model or an MP
> model, but not for the instance that you are actively flying on your
> machine. Such code can evaluate generic properties and modify them,
> and/or move them where they belong. In the MP case, cmdarg() can be
> used to access the model's node under /ai/models/. Example:
>
>
> print("I was just loaded under ", cmdarg().getPath())
> print("Good Bye says ", cmdarg().getPath())
>
>
>
Ah, very good! With this trick I should be able to transfer the
wing-fold and engine-tilt animation of the v22 over the MP-protocol.
Thank You!
Maik
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Haha, quick work. Thanks a lot! On Dec 9, 2007, at 7:19 AM, Melchior FRANZ wrote: > * Tatsuhiro Nishioka -- Saturday 08 December 2007: >> Durk, could you apply my patch to CVS? > > Too late! Already committed. Thanks. :-) > > m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
* Tatsuhiro Nishioka -- Saturday 08 December 2007: > Durk, could you apply my patch to CVS? Too late! Already committed. Thanks. :-) m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Thanks AJ! Durk, could you apply my patch to CVS? Thanks, Tat On Dec 9, 2007, at 6:48 AM, AJ MacLeod wrote: > On Saturday 08 December 2007 09:04:18 Tatsuhiro Nishioka wrote: >> Finally I found the cause of DList stack overflow and off-carrier >> aircraft problem. >> Now, off-carrier aircraft and DList stack overflow are not "feature" >> anymore. >> If it works on some platforms, then I'll ask Durk to apply it. > > I'd like to report that it worked perfectly for me on Linux, and > that "aircraft ending up under the carrier on reset" bug was very > annoying > indeed (especially given the "risky" nature of carrier ops ;-) > > This would be one fix well worth applying before the release - I > hope it can > be committed so that it gets proper testing. > > Cheers, > > AJ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
On Saturday 08 December 2007 09:04:18 Tatsuhiro Nishioka wrote: > Finally I found the cause of DList stack overflow and off-carrier > aircraft problem. > Now, off-carrier aircraft and DList stack overflow are not "feature" > anymore. > If it works on some platforms, then I'll ask Durk to apply it. I'd like to report that it worked perfectly for me on Linux, and that "aircraft ending up under the carrier on reset" bug was very annoying indeed (especially given the "risky" nature of carrier ops ;-) This would be one fix well worth applying before the release - I hope it can be committed so that it gets proper testing. Cheers, AJ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On Saturday 08 December 2007 18:30:53 Durk Talsma wrote: > I also like the 737, and with a 3D cockpit, I'd almost certainly decided to > keep it, but as it stands, the 2D cockpit stands out in a selction of > almost exclusively 3D cockpits. Of course we're by no means ditching the 737 (or any other model), this is only a "snapshot" of what's available in FG. IMO it would be nice if we could have maintain a bit of variation in base package aircraft between releases to keep things fresh and to introduce people to the rest of the models available. The proposed list does that pretty well, I think. Cheers, AJ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On Saturday 08 December 2007 18:28:35 Jon S. Berndt wrote: > One question, though, for these aircraft which will not be included for the > next release, where should official copies be updated? They're all "included" in the release in that they all go onto the aircraft download page (http://www.flightgear.org/Downloads/aircraft/index.shtml) That has tarballs generated from what's in CVS. Cheers, AJ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chat Menu and fix for chat repetition bug
Stuart Buchanan > Sent: 05 December 2007 08:19 > To: FlightGear Dev > Subject: [Flightgear-devel] Chat Menu and fix for chat repetition bug > > > Hi All, > > The latest and greatest chat menu system is now available. I > have added a couple of new features and fixed a number of bugs: > > - The chat menu automagically creates messages that include > the nearest airport, the current runway in use (based on the > current weather conditions), and information about your > aircraft and location. For example "Half Moon Bay Traffic, > G-FGFS is type Cessna, inbound from the south-west at > 4,000ft, straight in approach runway 30, 4 miles to run". > - The chat repetition bug should now be completely fixed > (though I have only seen it twice, so I can't be 100% certain). > - Going backwards and forwards through the message tree is > now more reliable. > > The patch consists of a number of files (from > http://www.nanjika.co.uk/flightgear/chatmenu.tar.gz): > - multiplayer.nas: a complete replacement for Nasal/multiplayer.nas > - chat-menu.xml: a new dialog to be placed under gui/dialogs > - chat-menu-entries: an XML file defining the various chat > messages, based on CAP-143 (UK standard radio phraseology). > To be placed under ATC/ > > The patch also changes a small number of other files, for > which diffs are included below. > > As Melchior doesn't spend much time using Multiplayer, he has > asked that I post to the list, so someone with more MP > experience can review and commit it to CVS. > > I think this is a big improvement over the current broken > chat implementation and improves the MP experience > significantly. I'd therefore ideally like it to be included > in the release. As the patch is non-trivial, I'd appreciate > it if it could be committed so that plenty of people can have > the chance to try it out before the release. > > Thanks > > -Stuart > > Index: preferences.xml > === > RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v > retrieving revision 1.256 > diff -u -r1.256 preferences.xml > --- preferences.xml 4 Dec 2007 13:12:15 - 1.256 > +++ preferences.xml 5 Dec 2007 07:58:48 - > @@ -472,6 +472,7 @@ > Hello > type="string">11850 > true > + > > > > > Index: menubar.xml > === > RCS file: /var/cvs/FlightGear-0.9/data/gui/menubar.xml,v > retrieving revision 1.68 > diff -u -r1.68 menubar.xml > --- menubar.xml 4 Dec 2007 10:51:45 - 1.68 > +++ menubar.xml 5 Dec 2007 07:57:44 - > @@ -162,6 +162,14 @@ > > > > + > + Chat Menu > + > +dialog-show > +chat-menu > + > + > + > > > > > Index: keyboard.xml > === > RCS file: /var/cvs/FlightGear-0.9/data/keyboard.xml,v > retrieving revision 1.103 > diff -u -r1.103 keyboard.xml > --- keyboard.xml 26 Nov 2007 17:55:28 - 1.103 > +++ keyboard.xml 1 Dec 2007 10:08:51 - > @@ -352,7 +352,17 @@ > > > > - > + > +- > +false > +Compose Chat > + > + dialog-show > + chat-menu > + > + > + > + >. >Right brake > > @@ -773,6 +783,16 @@ > > > > + > +_ > +false > +Compose Chat > + > + nasal > + multiplayer.compose_message() > + > + > + > >a >Increase speed-up. > > I've tested this all with Start, and after some changes and bug fixes it is now in cvs-head. Unfortunately, my cvs client has crashed, and I can't backport it to plib until tomorrow. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
--- Durk Talsma <[EMAIL PROTECTED]> schrieb: > On Saturday 08 December 2007 19:21, gerard robin > wrote: > > > > I forgot, > > does the 737 gone out and DEAD ? (in spite of > the coming 3D cockpit , > > Heiko working hardly on it). > > Certainly not dead. :-) I asked Heiko, off-list how > much time he needed to > finish the 3D cockpit, and answered that he was > quite sure he wouldn't be > able to finish it in time. > > I also like the 737, and with a 3D cockpit, I'd > almost certainly decided to > keep it, but as it stands, the 2D cockpit stands out > in a selction of almost > exclusively 3D cockpits. > > Cheers, > Durk > > Hi, Absolutely Right! Of course the 787 hasn't much hours, but beside the A-10 and A-6 it has one of the best 3d-cockpit. I'll need time to go one, and in the moment I havn't much due to my job and other circumstances. I agree to the list and the list of aircrafts shows really the improvements! Regards HHS Jetzt Mails schnell in einem Vorschaufenster überfliegen. Dies und viel mehr bietet das neue Yahoo! Mail - www.yahoo.de/mail - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] B1900d engine sounds
Just a quick observation. While testing the B1990d this afternoon, I found that I didn't hear any engine sounds. I also found the aircraft about half active upon initialization. That is, the engines were running, but the avionics were off. Bug or feature? :-) Anyway, since this aircraft is listed as a candidate for the base package, it'd be great is somebody could have a look. Cheers, Durk - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On Saturday 08 December 2007 19:21, gerard robin wrote: > > I forgot, > does the 737 gone out and DEAD ? (in spite of the coming 3D cockpit , > Heiko working hardly on it). Certainly not dead. :-) I asked Heiko, off-list how much time he needed to finish the 3D cockpit, and answered that he was quite sure he wouldn't be able to finish it in time. I also like the 737, and with a 3D cockpit, I'd almost certainly decided to keep it, but as it stands, the 2D cockpit stands out in a selction of almost exclusively 3D cockpits. Cheers, Durk - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
> I vote to keep the 737 > > Regards > -- > Gérard Once the 3D cockpit comes out, and some other work is done, perhaps it can be reconsidered. I'm not going to argue with this process, which has been careful and considerate. One question, though, for these aircraft which will not be included for the next release, where should official copies be updated? Jon - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On sam 8 décembre 2007, Durk Talsma wrote: > Hi there, > > Based on all the input sofar, I'd like to propose the following list of > aircraft for inclusion in the next release: > > 787 > A-10 > bf109 > bo105 > c172 > c172p > SenecaII > Beaver > B1900d > Lightning > j3cub > seahawk > p51d > pa28-161 > Bocian > choice of (T38, or Catalina, or Blackbird) > ufo > bleriot-XI-yasim > > In response to the previous discussions, please note the following: > > - After some testing this afternoon, I'd decided I prefer to keep the > bf109. Yes, it's pretty hard to get off the ground, but after testing I did > not have the impression that new users will blame this on bad programming. > > - I prefer the bochian over the schweizer for exactly the same reason why > we want to swap the 737 for the 787: The schweizer only has a 2d cockpit, > and and panning the view makes you feel lost. Also, the bochian has very > easy acces to the aerotow features. (Although the schweizer might, didn't > really check that). > > - I'm still undecided regarding the T38. As I wrote earlier, I feel that > the "small powerful jet" category is a bit overrepresented. Therefore, I'd > like to swap that with an altogether different category. After browsing the > repository, and some random sampling, I found two aircraft that seemed > quite advanced enough for inclusion, each representing a category of it's > own: The Blackbird, and the Catalina. > > I did not a few problems with the latter two aircraft, however: > - Blackbird: Couldn't get the engines started (somehow, the 's' key didn't > seem to respond. > - Catalina: Doesn't always seem to recognize ground contact points (e.g. at > EHAM it fell through the runway, and acted as a float plane). > > > I'm trying to finalize the list today or tomorrow, so I'd strongly prefer > not to make big changes. However, there is possibly still room for > improvement, so please let me know if you have suggestions for change. > > Cheers, > Durk I forgot, does the 737 gone out and DEAD ? (in spite of the coming 3D cockpit , Heiko working hardly on it). Wasn't it said that the 737 was the most popular. i have nothing against the 787 the model is great, but the real one has not so many hours. I vote to keep the 737 Regards -- Gérard http://pagesperso-orange.fr/GRTux/ << Less i work, better i go >> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On Sat, 8 Dec 2007 17:25:26 +0100 Durk Talsma <[EMAIL PROTECTED]> wrote: > Hi there, > > Based on all the input sofar, I'd like to propose the following list of > aircraft for inclusion in the next release: > > 787 > A-10 > bf109 > bo105 > c172 > c172p > SenecaII > Beaver > B1900d > Lightning > j3cub > seahawk > p51d > pa28-161 > Bocian > choice of (T38, or Catalina, or Blackbird) > ufo > bleriot-XI-yasim > > In response to the previous discussions, please note the following: > > - After some testing this afternoon, I'd decided I prefer to keep the bf109. > Yes, it's pretty hard to get off the ground, but after testing I did not have > the impression that new users will blame this on bad programming. > > - I prefer the bochian over the schweizer for exactly the same reason why we > want to swap the 737 for the 787: The schweizer only has a 2d cockpit, and > and panning the view makes you feel lost. Also, the bochian has very easy > acces to the aerotow features. (Although the schweizer might, didn't really > check that). > > - I'm still undecided regarding the T38. As I wrote earlier, I feel that > the "small powerful jet" category is a bit overrepresented. Therefore, I'd > like to swap that with an altogether different category. After browsing the > repository, and some random sampling, I found two aircraft that seemed quite > advanced enough for inclusion, each representing a category of it's own: The > Blackbird, and the Catalina. > > I did not a few problems with the latter two aircraft, however: > - Blackbird: Couldn't get the engines started (somehow, the 's' key didn't > seem to respond. > - Catalina: Doesn't always seem to recognize ground contact points (e.g. at > EHAM it fell through the runway, and acted as a float plane). > > > I'm trying to finalize the list today or tomorrow, so I'd strongly prefer not > to make big changes. However, there is possibly still room for improvement, > so please let me know if you have suggestions for change. > > Cheers, > Durk > Looks good to me , too Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] control trim reset
On Sat, 8 Dec 2007 23:17:13 +0900 Tatsuhiro Nishioka <[EMAIL PROTECTED]> wrote: > Oops, my bad explanation. > > On Dec 8, 2007, at 11:00 PM, Tatsuhiro Nishioka wrote: > > > Hi, > > > > One comment on this. > > > > J7W has Flap-driven Elevator-Trim Controller. it automatically adjusts > > elevator trim > > when flap is applied to avoid pushing up its tail. > > When flap is applied, J7W automatically adjusts its elevator trim to > avoid pushing up its tail. > > Though I'm not sure I want to use 5 key to reset all controls on J7W, > since such sudden control > may crash this cute canard. > > Anyway, it's a really good discussion. > I like this kinda topic since I can learn a bit more about using trims. > > Thanks guys > > Tat > HI Tat . Don't worry , I was thinking of it as a reset function . And now I agree it shouldn't be added :) I just need to find out how the real Bravo autopilot handles trim when the autopilot disengages because of excessive roll or pitch ... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Anders Gidenstam -- Saturday 08 December 2007: > Though my dual control version of the c172p already uses more > than 10 extra float properties.. :) I have no problem with adding more, now that I know that they have no effect if they aren't used. And if you are using some others, anyway, then we can as well have additional generic ones. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On Sat, 8 Dec 2007, gerard robin wrote: > Nasal animation Probably valuable for YASim but with JSBsim their is an other > way easier. But those properties are not sent over MP - which is the whole point of the /sim/multiplay/generic/* properties. While I agree that JSBSim allows many useful transformations of properties to be specified directly in the FDM config, this is one thing it cannot do. Many thanks to Melchior for adding these properties. (Though my dual control version of the c172p already uses more than 10 extra float properties.. :) Cheers, Anders -- --- Anders Gidenstam mail: anders(at)gidenstam.org WWW: http://www.gidenstam.org/FlightGear/JSBSim-LTA/ - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
Hi Gerard! gerard robin wrote: > Thanks , but NO > Catalina and Blackbird are on only under construction. > There is a lot of stuff to do , cockpit and FDM (mainly Blackbird which is > wrong), > My to do list is long like the bible :) > Nothing valuable to be released "Production" Just today I had a (first) closer look at the models of the Catalina, trying to figure out what you are doing differently than me so that your models look so fine. I would be a lucky guy if my modelling skills were so good that I could imagine potential for improvement in these models, implying that _these_ models are not yet "Production" status ;-) Yes, I saw you were talking about the cockpit and the FDM, not the models, but I just wanted to get this item of "well done to Gerard!" off my TODO-List ;-) Cheers, Ralf - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* gerard robin -- Saturday 08 December 2007: > but don't forget that we can within JSBSim avoid most of the Nasal code > everything done in the FDM. Again: this doesn't even *work* for what you fear it could be (ab)used. The bit of Nasal code in bo105.xml is simply ignored if you fly the bo105. It's only run for bo105 that appear as multiplayer objects, or such that you place as scenery decoration. There are only two uses for embedded Nasal: - static objects (e.g. animated hangar doors), where it's useful that the Nasal module is created when the object comes "into sight" (if you have good eyes ;-), and is removed again when you leave the area - MP objects, which need to run code that knows where in the property tree its parameters reside, and which have to move or modify properties there. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
On sam 8 décembre 2007, Durk Talsma wrote: > Hi there, > > Based on all the input sofar, I'd like to propose the following list of > aircraft for inclusion in the next release: > > 787 > A-10 > bf109 > bo105 > c172 > c172p > SenecaII > Beaver > B1900d > Lightning > j3cub > seahawk > p51d > pa28-161 > Bocian > choice of (T38, or Catalina, or Blackbird) > ufo > bleriot-XI-yasim > > In response to the previous discussions, please note the following: > > - After some testing this afternoon, I'd decided I prefer to keep the > bf109. Yes, it's pretty hard to get off the ground, but after testing I did > not have the impression that new users will blame this on bad programming. > > - I prefer the bochian over the schweizer for exactly the same reason why > we want to swap the 737 for the 787: The schweizer only has a 2d cockpit, > and and panning the view makes you feel lost. Also, the bochian has very > easy acces to the aerotow features. (Although the schweizer might, didn't > really check that). > > - I'm still undecided regarding the T38. As I wrote earlier, I feel that > the "small powerful jet" category is a bit overrepresented. Therefore, I'd > like to swap that with an altogether different category. After browsing the > repository, and some random sampling, I found two aircraft that seemed > quite advanced enough for inclusion, each representing a category of it's > own: The Blackbird, and the Catalina. > > I did not a few problems with the latter two aircraft, however: > - Blackbird: Couldn't get the engines started (somehow, the 's' key didn't > seem to respond. > - Catalina: Doesn't always seem to recognize ground contact points (e.g. at > EHAM it fell through the runway, and acted as a float plane). > > > I'm trying to finalize the list today or tomorrow, so I'd strongly prefer > not to make big changes. However, there is possibly still room for > improvement, so please let me know if you have suggestions for change. > > Cheers, > Durk Thanks , but NO Catalina and Blackbird are on only under construction. There is a lot of stuff to do , cockpit and FDM (mainly Blackbird which is wrong), My to do list is long like the bible :) Nothing valuable to be released "Production" Regards -- Gérard http://pagesperso-orange.fr/GRTux/ << Less i work, better i go >> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-final aircraft selection
* Durk Talsma -- Saturday 08 December 2007: > Based on all the input sofar, I'd like to propose the following list of > aircraft for inclusion in the next release: Looks good. Not trying to say anything particular -- just FYI: 20M 787 20M A-10 26M bf109 3.2Mbo105* 84K c172 1.9Mc172p 6.4MSenecaII 8.5Mdhc2 5.9Mb1900d 12M Lightning 1.2Mj3cub 13M seahawk 12M p51d 1.8Mpa28-161 13M bocian 600Kufo* 9.5Mbleriot-XI + one of those 2.5MT38 9.9MPBY-Catalina 17M SR71-BlackBird * ... a bit less, actually, as this includes files that only I have The bleriot is very nice, much nicer than the wright. But its FDM is a bit ... ummm ... well, the engine is quite powerful and the aircraft allows some aerobatics, which the real one probably didn't ;-) m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On sam 8 décembre 2007, Melchior FRANZ wrote:
> * Melchior FRANZ -- Saturday 08 December 2007:
> > it was time to add some generic properties for "internal communication".
>
> It's probably also time to remind people again of the possibility to
> add Nasal code to model (animation) XML files. This is then only
> run when the model is used as as a static scenery model or an MP
> model, but not for the instance that you are actively flying on your
> machine. Such code can evaluate generic properties and modify them,
> and/or move them where they belong. In the MP case, cmdarg() can be
> used to access the model's node under /ai/models/. Example:
>
>
> print("I was just loaded under ", cmdarg().getPath())
> print("Good Bye says ", cmdarg().getPath())
>
>
> See $FG_ROOT/Aircraft/Models/bo105.xml for a real world example.
>
> m.
>
Which is right,
but don't forget that we can within JSBSim avoid most of the Nasal code
everything done in the FDM.
For instance, i do use it to get the right (factor) animation with propellers,
the brake chute animated under conditions, and so on everything done
without Nasal.
Nasal animation Probably valuable for YASim but with JSBsim their is an other
way easier.
Regards
--
Gérard
http://pagesperso-orange.fr/GRTux/
<< Less i work, better i go >>
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Pre-final aircraft selection
Hi there, Based on all the input sofar, I'd like to propose the following list of aircraft for inclusion in the next release: 787 A-10 bf109 bo105 c172 c172p SenecaII Beaver B1900d Lightning j3cub seahawk p51d pa28-161 Bocian choice of (T38, or Catalina, or Blackbird) ufo bleriot-XI-yasim In response to the previous discussions, please note the following: - After some testing this afternoon, I'd decided I prefer to keep the bf109. Yes, it's pretty hard to get off the ground, but after testing I did not have the impression that new users will blame this on bad programming. - I prefer the bochian over the schweizer for exactly the same reason why we want to swap the 737 for the 787: The schweizer only has a 2d cockpit, and and panning the view makes you feel lost. Also, the bochian has very easy acces to the aerotow features. (Although the schweizer might, didn't really check that). - I'm still undecided regarding the T38. As I wrote earlier, I feel that the "small powerful jet" category is a bit overrepresented. Therefore, I'd like to swap that with an altogether different category. After browsing the repository, and some random sampling, I found two aircraft that seemed quite advanced enough for inclusion, each representing a category of it's own: The Blackbird, and the Catalina. I did not a few problems with the latter two aircraft, however: - Blackbird: Couldn't get the engines started (somehow, the 's' key didn't seem to respond. - Catalina: Doesn't always seem to recognize ground contact points (e.g. at EHAM it fell through the runway, and acted as a float plane). I'm trying to finalize the list today or tomorrow, so I'd strongly prefer not to make big changes. However, there is possibly still room for improvement, so please let me know if you have suggestions for change. Cheers, Durk - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Saturday 08 December 2007: > $FG_ROOT/Aircraft/Models/bo105.xml Bah ... $FG_ROOT/Aircraft/bo105/Models/bo105.xml m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* Melchior FRANZ -- Saturday 08 December 2007:
> it was time to add some generic properties for "internal communication".
It's probably also time to remind people again of the possibility to
add Nasal code to model (animation) XML files. This is then only
run when the model is used as as a static scenery model or an MP
model, but not for the instance that you are actively flying on your
machine. Such code can evaluate generic properties and modify them,
and/or move them where they belong. In the MP case, cmdarg() can be
used to access the model's node under /ai/models/. Example:
print("I was just loaded under ", cmdarg().getPath())
print("Good Bye says ", cmdarg().getPath())
See $FG_ROOT/Aircraft/Models/bo105.xml for a real world example.
m.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Catalina problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 gerard robin wrote: > On sam 8 décembre 2007, you wrote: >> Today I tried --aircraft=Catalina-OSG with OSG, I had not used it for a few >> weeks. However I ended up in an aircraft without textures and these errors >> in the console. > SNIP >> osgDB ac3d reader: could not find texture "Pilote-Casque.rgb" >> osgDB ac3d reader: could not find texture "F4U7-Moteur.rgb" >> osgDB ac3d reader: could not find texture "p38-prop1.rgb" >> Model Author: Author Name >> Creation Date: Creation Date >> Version: Version >> Description: Models a PBY-5 and 6 >> Chat [*FGMS*] Welcome to hugin - Gothenburg, Sweden >> >> >> But at lease some of these textures exist: >> ~/src/flightgear/data/Aircraft/PBY-Catalina $ find . -iname btextu99.rgb >> ./Models/Textures/texture-protcivil/btextu99.rgb >> >> >> So what is going on. I'm using latest CVS source and data (CVS HEAD) >> >> >> Regards >> >> Arvid Norlander > > To me working working right => FG_OSG nov-29 built with OSG stable 2.2 I use FG_OSG CVS as of today with OSG stable 2.2. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWsGCWmK6ng/aMNkRCilHAJ9EUrjftH4wHa0K10md8l/fwD9YugCfSH6j RW0INb+pJHGZ8WZG4jXlolw= =AHYS -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] nonzero turbulence set by Preferences.xml?
Melchior FRANZ wrote: > * dave perry -- Friday 07 December 2007: > >> What is proposed is to make the default turbulence = 0.0 at start-up, >> not turning off turbulence modeling. You can still use the weather menu >> to set the desired turbulence or you can [...] >> > > OK, before even more people answer who didn't get what I was writing: > > - low/no default turbulence doesn't make fgfs a toy > - high default turbulence doesn't make it professional > > just as > > - avoiding really difficult to fly aircraft in the default aircraft >collection doesn't make fgfs a toy, and > - including them doesn't make it professional > > I was just making a comparison! :-) > > In the end I don't care much, as I (like everyone else here) will > not use the default package. The question is only, which defaults > are least frustrating for someone who just downloaded 200 MB of > data via dial up, and what makes the most sense. > > That we want maximum realism *and* a way to configure as much as > possible and reasonable, was never disputed. > > m. > > > A final comment in ending this discussion (I hope). I agree, as a user, that we do not want the default setting to be zero. I am an advocate of realism. The FG windows gui, in weather --> weather conditions allows one to set the turb to zero with sliders. Setting them to zero does not in fact set turb to zero, at least with my recent build of FG OSG. That would be a bug (in OSG version) & should be fixed. A user can, as indicated earlier in this thread, set turb to zero on the command line. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* gerard robin -- Saturday 08 December 2007: > I worry that way /sim/multiplay/generic/.. because i thought > that the best way, regarding every surface position was to > include it into the "/surface-positions/foo" property You miss the point, as maybe some others do as well. The generic properties are not meant to be used for standard functions, but for properties that can't be standardized in a meaningful way. The bo105, for example, has an emblem property for the Red Cross symbol. There's no chance that we'll ever have a hard-coded /sim/model/red-cross-emblem property. We'd have to add thousands of such specific, non-standard properties. And for *such* cases we have now a set of generic properties. Standardized properties should still be transmitted under their specific node path. And if some are missing, then we'll add them. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster > Sent: 08 December 2007 14:02 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] multiplayer generic properties > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Vivian Meazza wrote: > > Anders has a really neat bit-mask utility which allows the > > transmission of up to 32 bools in one int property - much > neater for > > light switches and the like. > > > > Vivian > > > > P.S. - by tradition we bottom-post on the devel list > > However for those aircrafts that I considered for lights they > were not on/off but had birghtness setting too, check the > A-10 and A-6E for example. > Even better - for that there's nice slow signal interface using TDM - needs a pair of properties, preferably int. Panel light, nav lights, etc etc. In theory unlimited, but about 8 is practical. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] control trim reset
Oops, my bad explanation. On Dec 8, 2007, at 11:00 PM, Tatsuhiro Nishioka wrote: > Hi, > > One comment on this. > > J7W has Flap-driven Elevator-Trim Controller. it automatically adjusts > elevator trim > when flap is applied to avoid pushing up its tail. When flap is applied, J7W automatically adjusts its elevator trim to avoid pushing up its tail. Though I'm not sure I want to use 5 key to reset all controls on J7W, since such sudden control may crash this cute canard. Anyway, it's a really good discussion. I like this kinda topic since I can learn a bit more about using trims. Thanks guys Tat - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
On sam 8 décembre 2007, Vivian Meazza wrote: > AnMaster > > > Sent: 08 December 2007 11:55 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] multiplayer generic properties > > SNIP > > > > Melchior FRANZ wrote: > > > After Maik has clued me up about multiplayer properties -- > > > > that only > > > > > those are transmitted, which actually exist at init time > > > > (which is why > > > > > they need to be defined in the *-set.xml file), it was time to add > > > some generic properties for "internal communication". That is: > > > properties which aren't dedicated to a particular function, > > > > but can be > > > > > used by an aircraft to send data to its mirror instances over MP. > > > > > > There are for now: > > > /sim/multiplay/generic/string[0-9] > > > /sim/multiplay/generic/float[0-9] > > > /sim/multiplay/generic/int[0-9] > > > > > > Of course, this should be used sparingly. If you need to transmit a > > > path, don't transmit the full path, but only the parts that > > > > are really > > SNIP > > transmit these > > > > > "single-shot" properties in every package (, I hope :-). > > > > > > m. > > Anders has a really neat bit-mask utility which allows the transmission of > up to 32 bools in one int property - much neater for light switches and the > like. > > Vivian > > P.S. - by tradition we bottom-post on the devel list > I worry that way /sim/multiplay/generic/.. because i thought that the best way, regarding every surface position was to include it into the "/surface-positions/foo" property ( i had talk some time ago with anmaster on IRC with it ). I should have talked about that feature HERE before every decision. This would have saved time with modifications. Regards -- Gérard http://pagesperso-orange.fr/GRTux/ << Less i work, better i go >> - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Vivian Meazza wrote: > Anders has a really neat bit-mask utility which allows the transmission of > up to 32 bools in one int property - much neater for light switches and the > like. > > Vivian > > P.S. - by tradition we bottom-post on the devel list However for those aircrafts that I considered for lights they were not on/off but had birghtness setting too, check the A-10 and A-6E for example. /AnMaster -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWqPaWmK6ng/aMNkRCgkgAJ9sf1F5wLdOkZBk6y6oGvnk5tm3ugCcCx/O fEWQlFrmcLy/OMV1dwuMiP8= =tQJE -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] control trim reset
Hi, One comment on this. J7W has Flap-driven Elevator-Trim Controller. it automatically adjusts elevator trim when flap is applied to avoid pushing up its tail. If elevator trim is reset by pressing 5, then the trim won't be in the center position when flap is all the way up. So resetting elevator trim is no good as long as j7w is concerned. See the following for detail: http://macflightgear.sourceforge.net/home/aircraft/j7w/j7w-manual/ Best, Tat On Dec 6, 2007, at 6:50 AM, Curtis Olson wrote: > On Dec 5, 2007 3:33 PM, John Denker <> wrote: > Maybe I'm missing something, but I thought "5" was a > mouse-only solution to a mouse-only problem. > > "5" is a solution to a keybaord control issue, and it can come in > handy for people that use a mouse too ... if done carefully. It > should be useless for someone flying with a joystick since the > joystick will overwrite the position on the next frame anyway. > > Curt. > -- > Curtis Olson: http://baron.flightgear.org/~curt/ > Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d > - > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster > Sent: 08 December 2007 11:55 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] multiplayer generic properties > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Yes, I already made a patch (see "[Flightgear-devel] Patch > for Harrier: making it's thrust vector work over mp") for the > harrier that makes use of this :) > > And I can think of several other aircrafts that could make > use of this. For example position lights/anti-collision > lights of some aircrafts. Would make formation flying in the > dark over mp simpler. > > Regards, > > Arvid Norlander > > Melchior FRANZ wrote: > > After Maik has clued me up about multiplayer properties -- > that only > > those are transmitted, which actually exist at init time > (which is why > > they need to be defined in the *-set.xml file), it was time to add > > some generic properties for "internal communication". That is: > > properties which aren't dedicated to a particular function, > but can be > > used by an aircraft to send data to its mirror instances over MP. > > > > There are for now: > > /sim/multiplay/generic/string[0-9] > > /sim/multiplay/generic/float[0-9] > > /sim/multiplay/generic/int[0-9] > > > > Of course, this should be used sparingly. If you need to transmit a > > path, don't transmit the full path, but only the parts that > are really > > necessary. For example, the bo105 will only transmit "foo", when it > > actually means "Aircraft/bo105/Models/Variants/foo.xml". > > The prefix and the ".xml" postfix will be stripped. There's > still the > > possibility to transmit "../../foo" if for some reason I > want to refer > > to a file elsewhere. (I didn't add double/long/bool, as > they would be > > transmitted as float/int/int, anyway.) > > > > In one of the next protocol revisions, we won't have to > transmit these > > "single-shot" properties in every package (, I hope :-). > > > > m. Anders has a really neat bit-mask utility which allows the transmission of up to 32 bools in one int property - much neater for light switches and the like. Vivian P.S. - by tradition we bottom-post on the devel list - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] segfault on 0.9.11-pre2
Hi there, I've encountered a weird sigfault on Mac OS 10.5 with 0.9.11-pre2. when I launch fgfs without opening window, fgfs crashes with segfault. e.g., fgfs --fg-root=. --help makes segfault. Simply launching fgfs without no options does too. So does specifying a wrong option. But It doesn't crash when launched with the main window (with options --airport=KSFO --aircraft=c172p) Here is the crash log that I have. Thread 0 Crashed: 0 fgfs0x0048bfb6 std::_Rb_tree, std::allocator >, std::pair, std::allocator > const, SGSharedPtr >, std::_Select1st, std::allocator > const, SGSharedPtr > >, std::less, std::allocator > >, std::allocator, std::allocator > const, SGSharedPtr > > >::_M_erase(std::_Rb_tree_node, std::allocator > const, SGSharedPtr > >*) + 92 1 fgfs0x0048b628 SGMaterialLib::~SGMaterialLib() + 24 2 fgfs0x00300c99 FGGlobals::~FGGlobals() + 467 3 fgfs0x2c56 fgExitCleanup() + 64 4 libSystem.B.dylib 0x9432e967 __cxa_finalize + 252 5 libSystem.B.dylib 0x9432e850 exit + 33 6 fgfs0x00307cc7 fgMainInit(int, char**) + 1005 7 fgfs0x2973 main + 175 8 fgfs0x21f2 _start + 216 9 fgfs0x2119 start + 41 (snip) I guess this is caused by releasing uninitialized instance variable(s). the crash report says it happens around SGMaterialLib::~SGMaterialLib() but that method is empty hmmm, no idea what causes this. First I doubt this is caused by the patch that I made for fixing DList stack overflow, but the built without that patch also ends up with the same result. I've already tried some clean builds but it didn't help. Does anyone have the same issue? or any hints? Thanks in advance, Tat - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Catalina problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Today I tried --aircraft=Catalina-OSG with OSG, I had not used it for a few weeks. However I ended up in an aircraft without textures and these errors in the console. osgDB ac3d reader: could not find texture "btextu99.rgb" osgDB ac3d reader: could not find texture "F4U7-PanelFond.rgb" osgDB ac3d reader: could not find texture "Ailes.rgb" osgDB ac3d reader: could not find texture "QueueDG.rgb" osgDB ac3d reader: could not find texture "Capot-moteur.rgb" osgDB ac3d reader: could not find texture "Nez.rgb" osgDB ac3d reader: could not find texture "alt3d-cadran.rgb" osgDB ac3d reader: could not find texture "hi3d-cadran.rgb" osgDB ac3d reader: could not find texture "par3d-cadran.rgb" osgDB ac3d reader: could not find texture "Jaune-noir.rgb" osgDB ac3d reader: could not find texture "rpm.rgb" osgDB ac3d reader: could not find texture "asi2-nord.rgb" osgDB ac3d reader: could not find texture "blanc-rouge.rgb" osgDB ac3d reader: could not find texture "AISpherev2.rgb" osgDB ac3d reader: could not find texture "attitude5.rgb" osgDB ac3d reader: could not find texture "digit.rgb" osgDB ac3d reader: could not find texture "minus.rgb" osgDB ac3d reader: could not find texture "alt3d-cadran.rgb" osgDB ac3d reader: could not find texture "digit-r.rgb" osgDB ac3d reader: could not find texture "Jaune-noir.rgb" osgDB ac3d reader: could not find texture "mp-osi.rgb" osgDB ac3d reader: could not find texture "turn3d-niveau.rgb" osgDB ac3d reader: could not find texture "hi3d-cadran.rgb" osgDB ac3d reader: could not find texture "hi3d-fond.rgb" osgDB ac3d reader: could not find texture "blanc-rouge.rgb" osgDB ac3d reader: could not find texture "vsi-6.rgb" osgDB ac3d reader: could not find texture "F4U7-Moteur-huile-temp.rgb" osgDB ac3d reader: could not find texture "F4U7-Moteur-fuel-press.rgb" osgDB ac3d reader: could not find texture "F4U7-Moteur-oil-press.rgb" osgDB ac3d reader: could not find texture "tank-pby_lo.rgb" osgDB ac3d reader: could not find texture "blanc-rouge.rgb" osgDB ac3d reader: could not find texture "textupilote.rgb" osgDB ac3d reader: could not find texture "face.rgb" osgDB ac3d reader: could not find texture "Pilote-Casque.rgb" osgDB ac3d reader: could not find texture "F4U7-Moteur.rgb" osgDB ac3d reader: could not find texture "p38-prop1.rgb" Model Author: Author Name Creation Date: Creation Date Version: Version Description: Models a PBY-5 and 6 Chat [*FGMS*] Welcome to hugin - Gothenburg, Sweden But at lease some of these textures exist: ~/src/flightgear/data/Aircraft/PBY-Catalina $ find . -iname btextu99.rgb ./Models/Textures/texture-protcivil/btextu99.rgb So what is going on. I'm using latest CVS source and data (CVS HEAD) Regards Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWpwHWmK6ng/aMNkRCoE0AJ0TZjYSjFz5lMcrq0auaRX2sdr3cwCfU3M2 DUsCa3kFWQZtkoEg1NfHoNY= =mOMu -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
* AnMaster -- Saturday 08 December 2007: > Yes, I already made a patch (see "[Flightgear-devel] Patch for > Harrier: making it's thrust vector work over mp") for the harrier > that makes use of this :) Yes, you are quick. This will have to be reviewed and OK'ed by the harrier model maintainer. > And I can think of several other aircrafts that could make use of this. > For example position lights/anti-collision lights of some aircrafts. These are "standard properties", and should therefore not really use the generic ones, though we may yet have to add them. m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Yes, I already made a patch (see "[Flightgear-devel] Patch for Harrier: making it's thrust vector work over mp") for the harrier that makes use of this :) And I can think of several other aircrafts that could make use of this. For example position lights/anti-collision lights of some aircrafts. Would make formation flying in the dark over mp simpler. Regards, Arvid Norlander Melchior FRANZ wrote: > After Maik has clued me up about multiplayer properties -- that > only those are transmitted, which actually exist at init time > (which is why they need to be defined in the *-set.xml file), > it was time to add some generic properties for "internal communication". > That is: properties which aren't dedicated to a particular > function, but can be used by an aircraft to send data to its > mirror instances over MP. > > There are for now: > /sim/multiplay/generic/string[0-9] > /sim/multiplay/generic/float[0-9] > /sim/multiplay/generic/int[0-9] > > Of course, this should be used sparingly. If you need to transmit > a path, don't transmit the full path, but only the parts that are > really necessary. For example, the bo105 will only transmit "foo", > when it actually means "Aircraft/bo105/Models/Variants/foo.xml". > The prefix and the ".xml" postfix will be stripped. There's still > the possibility to transmit "../../foo" if for some reason I want > to refer to a file elsewhere. (I didn't add double/long/bool, as > they would be transmitted as float/int/int, anyway.) > > In one of the next protocol revisions, we won't have to transmit > these "single-shot" properties in every package (, I hope :-). > > m. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWoYUWmK6ng/aMNkRChvvAJ4gtFn5qiH9R+AcaL3Uvq/vcxWgRwCfVUNk +n/CrUzFWf2Puqz6mY9ibgI= =yodC -END PGP SIGNATURE- - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiplayer generic properties
After Maik has clued me up about multiplayer properties -- that only those are transmitted, which actually exist at init time (which is why they need to be defined in the *-set.xml file), it was time to add some generic properties for "internal communication". That is: properties which aren't dedicated to a particular function, but can be used by an aircraft to send data to its mirror instances over MP. There are for now: /sim/multiplay/generic/string[0-9] /sim/multiplay/generic/float[0-9] /sim/multiplay/generic/int[0-9] Of course, this should be used sparingly. If you need to transmit a path, don't transmit the full path, but only the parts that are really necessary. For example, the bo105 will only transmit "foo", when it actually means "Aircraft/bo105/Models/Variants/foo.xml". The prefix and the ".xml" postfix will be stripped. There's still the possibility to transmit "../../foo" if for some reason I want to refer to a file elsewhere. (I didn't add double/long/bool, as they would be transmitted as float/int/int, anyway.) In one of the next protocol revisions, we won't have to transmit these "single-shot" properties in every package (, I hope :-). m. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for Harrier: making it's thrust vector work over mp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
As the /sim/multiplayer/generic/float[0] to /sim/multiplayer/generic/float[9]
were recently added I decided to make use of this to make the nozzles of the
harrier correctly show the current thrust vector over multiplayer.
Attached is a patch to do this.
Also attached is mpsend.nas that should be placed in DATA/Aircraft/harrier/
(where DATA is the data checkout). As any Nasal subdirectory wasn't used before
I decided to follow the current standard for the harrier.
I have tested that the patch works as it should both locally and over mp.
Regards,
Arvid Norlander
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHWoODWmK6ng/aMNkRCo8ZAKCD2r/mby8sHIZVib9dJY5ysv+dSgCeNcma
U+yJf7zFwQ7K4J/PdF0uT2I=
=fR/z
-END PGP SIGNATURE-
? harrier-thrust-vector.patch
? mpsend.nas
Index: harrier-set.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/harrier/harrier-set.xml,v
retrieving revision 1.9
diff -u -p -r1.9 harrier-set.xml
--- harrier-set.xml 16 Jun 2007 00:48:31 - 1.9
+++ harrier-set.xml 8 Dec 2007 11:41:27 -
@@ -274,6 +274,18 @@
Aircraft/harrier/Panel/Hud/hud.nas
+
+ Aircraft/harrier/mpsend.nas
+
-
+
+
+
+
+
+
+0.0
+
+
+
Index: Models/harrier-model.xml
===
RCS file:
/var/cvs/FlightGear-0.9/data/Aircraft/harrier/Models/harrier-model.xml,v
retrieving revision 1.3
diff -u -p -r1.3 harrier-model.xml
--- Models/harrier-model.xml24 Aug 2006 22:29:17 - 1.3
+++ Models/harrier-model.xml8 Dec 2007 11:41:28 -
@@ -460,7 +460,7 @@
rotate
LFNozzle
RFNozzle
- /controls/engines/engine/mixture
+ sim/multiplay/generic/float[0]
-100
98
@@ -478,7 +478,7 @@
rotate
LRNozzle
RRNozzle
- /controls/engines/engine/mixture
+ sim/multiplay/generic/float[0]
-100
98
@@ -608,7 +608,7 @@
rotate
VectorLever
- controls/engines/engine/mixture
+ sim/multiplay/generic/float[0]
45
-25
@@ -631,7 +631,7 @@
-
/sim/weight[7]/selected
+
sim/weight[7]/selected
Refueling Boom Attached
@@ -667,7 +667,7 @@
intakeDoor
-
/controls/engines/engine/mixture
+
sim/multiplay/generic/float[0]
0.7
# This file is used to copy some properties to send over mp.
# Copy the thrust vectory to a property that can be sent over MP.
setlistener("/controls/engines/engine/mixture", func(n) {
setprop("/sim/multiplay/generic/float[0]", n.getValue());
});-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for issue with tu154 over mp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 If you see a tu154 multiplayer from your own aircraft's cockpit view it will lack fuselage, if you change to external view you will see the fuselage. This was caused by tu154 using absolute property paths. Here is a patch to fix this. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHWnXvWmK6ng/aMNkRCsgkAKCY/ONhNquy1P4qminqYyuLo/kWXgCggXY2 5kxZWjRYi6bzAC6p+A65eO8= =TLW0 -END PGP SIGNATURE- Index: Models/main-ai.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/tu154/Models/main-ai.xml,v retrieving revision 1.1 diff -u -p -r1.1 main-ai.xml --- Models/main-ai.xml 1 Jul 2004 14:09:32 - 1.1 +++ Models/main-ai.xml 8 Dec 2007 10:43:14 - @@ -6,7 +6,7 @@ rotate ball - /orientation/roll-deg + orientation/roll-deg -0.042 0 @@ -22,7 +22,7 @@ rotate ball - /orientation/pitch-deg + orientation/pitch-deg -0.042 0 @@ -38,7 +38,7 @@ rotate rollarrow - /orientation/roll-deg + orientation/roll-deg 1 0 Index: Models/rud1.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/tu154/Models/rud1.xml,v retrieving revision 1.1 diff -u -p -r1.1 rud1.xml --- Models/rud1.xml 1 Jul 2004 14:09:32 - 1.1 +++ Models/rud1.xml 8 Dec 2007 10:43:14 - @@ -7,7 +7,7 @@ rotate rud - /controls/engines/engine[0]/throttle + controls/engines/engine[0]/throttle 36 0 Index: Models/rud2.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/tu154/Models/rud2.xml,v retrieving revision 1.1 diff -u -p -r1.1 rud2.xml --- Models/rud2.xml 1 Jul 2004 14:09:32 - 1.1 +++ Models/rud2.xml 8 Dec 2007 10:43:14 - @@ -7,7 +7,7 @@ rotate rud - /controls/engines/engine[1]/throttle + controls/engines/engine[1]/throttle 36 0 Index: Models/rud3.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/tu154/Models/rud3.xml,v retrieving revision 1.1 diff -u -p -r1.1 rud3.xml --- Models/rud3.xml 1 Jul 2004 14:09:32 - 1.1 +++ Models/rud3.xml 8 Dec 2007 10:43:14 - @@ -7,7 +7,7 @@ rotate rud - /controls/engines/engine[2]/throttle + controls/engines/engine[2]/throttle 36 0 Index: Models/tu154B.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/tu154/Models/tu154B.xml,v retrieving revision 1.4 diff -u -p -r1.4 tu154B.xml --- Models/tu154B.xml 10 Jul 2007 17:10:46 - 1.4 +++ Models/tu154B.xml 8 Dec 2007 10:43:15 - @@ -35,7 +35,7 @@ Tupolev 154B-2 model/animation config. - /sim/current-view/view-number + sim/current-view/view-number 0 @@ -1930,7 +1930,7 @@ Tupolev 154B-2 model/animation config. select BeaconFlasher - /controls/lighting/beacon + controls/lighting/beacon @@ -1940,7 +1940,7 @@ Tupolev 154B-2 model/animation config. RightNavLightOff -/controls/lighting/nav-lights +controls/lighting/nav-lights @@ -1950,7 +1950,7 @@ Tupolev 154B-2 model/animation config. LeftNavLightOn RightNavLightOn -/controls/lighting/nav-lights +controls/lighting/nav-lights - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Tatsuhiro Nishioka schrieb: > Hi Georg, > > Of course it should be rejected since you applied it to too new code. > > The patch is for 0.9.11-pre2 release, not for CVS head. > Check out source files using -r RELEASE_0_9_11_pre2 option and apply > it again. > > Best, > > Tat > > Hello Tat, thank you for the info. I will try later, might be this evening, due to real life work. Georg - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Hi Georg,
Of course it should be rejected since you applied it to too new code.
The patch is for 0.9.11-pre2 release, not for CVS head.
Check out source files using -r RELEASE_0_9_11_pre2 option and apply
it again.
Best,
Tat
On Dec 8, 2007, at 6:37 PM, Georg Vollnhals wrote:
> Hi Tat,
>
> I tried your diff but my actual CVS source (did a fresh update before
> applying the diff) gives some rejections.
> It might be that you build the diff against an older source?
>
> Here an example of one rejection:
>
> *
> AIBase.cxx
> *
>
> ***
> *** 179,185
>
> }
>
>> From your diff:
>
> - if (model) {
> aip.init( model );
> aip.setVisible(true);
> invisible = false;
> --- 180,188
>
> Actual CVS:
>
> if (model.get()) {
>aip.init( model.get() );
>aip.setVisible(true);
>invisible = false;
>
> }
>
> ...
>
> Regards
> Georg
>
> -
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Tatsuhiro Nishioka schrieb:
> Hi,
>
> I found kind of a hint of the cause of DList stack overflow.
>
> After reset, the number of ssgTransform increases a lot.
> so maybe this has something to do with the cause of the problem since
> ssgTransform::cull calls _ssgPushMatrix and _ssgPopMatrix. these two
> show "DList stack overflow" error.
>
> Plus, this problem doesn't happen when --disable-ai-models is specified.
> When I commented outnimitz_demo from
> preferences.xml,
> this DL stack overflow doesn't happen even without --disable-ai-models.
>
> So resetting carrier object in AICarrier::init() or methods called
> from init() probably generates
> redundant or unexpected ssgTransform objects.
>
> I'll dive deeper tomorrow.
> If any of you have any idea on what causes this, please let me know.
>
> Best,
>
> Tat
>
> On Dec 8, 2007, at 2:49 AM, Tatsuhiro Nishioka wrote:
>
>
Hi Tat,
I tried your diff but my actual CVS source (did a fresh update before
applying the diff) gives some rejections.
It might be that you build the diff against an older source?
Here an example of one rejection:
*
AIBase.cxx
*
***
*** 179,185
}
>From your diff:
- if (model) {
aip.init( model );
aip.setVisible(true);
invisible = false;
--- 180,188
Actual CVS:
if (model.get()) {
aip.init( model.get() );
aip.setVisible(true);
invisible = false;
}
...
Regards
Georg
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Hi guys, Finally I found the cause of DList stack overflow and off-carrier aircraft problem. The cause of the first one is that aip.ssgTransform of AICarrier are unexpectedly registered on every reset in AIBase::init(). The second one is caused by ssgEntry related code in AICarrier::init(). So I made a patch for doing these process only in the first init() calls. Now, off-carrier aircraft and DList stack overflow are not "feature" anymore. Enclosed is the patch for solving these problems. I want you guys to test this on your platforms. I don't think this affects any other AI objects' reinit() as far as I've tested but this should be tested on many machines. If it works on some platforms, then I'll ask Durk to apply it. By the way, I've encountered that aircraft doesn't follow the movement of Nimitz while testing this patch. In this case, simply remove ~/.fgfs/autosave.xml can fix this problem. You can also fix it by changing Rendering options and exit fgfs by pressing ESC. Best, Tat On Dec 8, 2007, at 8:44 AM, Tatsuhiro Nishioka wrote: Hi, I found kind of a hint of the cause of DList stack overflow. After reset, the number of ssgTransform increases a lot. so maybe this has something to do with the cause of the problem since ssgTransform::cull calls _ssgPushMatrix and _ssgPopMatrix. these two show "DList stack overflow" error. Plus, this problem doesn't happen when --disable-ai-models is specified. When I commented outnimitz_demo from preferences.xml, this DL stack overflow doesn't happen even without --disable-ai- models. So resetting carrier object in AICarrier::init() or methods called from init() probably generates redundant or unexpected ssgTransform objects. I'll dive deeper tomorrow. If any of you have any idea on what causes this, please let me know. Best, Tat FlightGear-DListStackOverflow.diff Description: Binary data - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
