[Flightgear-devel] [RFC] AIbase.cxx - RADAR
The radar implementation in AIBase.cxx makes the assumption that the radar is fixed on the longitudinal axis of the model. (It also assumes rotations and elevations are in the local horizontal and that the radar is at the origin of the model.) The radar data are used to drive the target markers on the HUD. While the HUD is also fixed to the longitudinal axis, these assumptions are adequate. When the HUD is not so fixed, as in the Landing Signal Officer HUD in the MP Carrier (no this isn't a flight of fancy, it does exist in RL), we need to apply offsets to radar heading and elevation to enable the target markers to be displayed. The other assumptions are adequate at medium to long range. The attached patch implements heading, elevation and height offsets. The values default to 0, so there are no implications for existing implementations of the AI radar. Vivian AIBase.diff Description: Binary data -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
* Tatsuhiro Nishioka -- 6/23/2009 5:01 AM: I'm not so sure what it should look like, but at least it needs nil check for the property. That would only be cosmetics and just hide the fact that the METAR runway choosing code is now broken since Detlefs recent changes. The METAR wind direction/strength is now published too late for startup.nas, so an aircraft isn't positionend on a proper runway if METAR is used. *This* is the problem that needs to be fixed, not the Nasal error message. startup.nas is/was a bit hackish, anyway. A proper solution would be to wait for the METAR wind and only then to set the runway and FDM. This would require to initialize the environment subsystem earlier. Then we could also drop the additional presets-commit and save some startup time. startup.nas could be dropped altogether. m. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaN-reports and possible cause
Hi, I got a similar crash after observing wildly jumping AI Aircraft. I'm pretty sure the AI Traffic system is the culprit, but haven't really an idea why it's misbehaving. Also, considering the fact that the AI Traffic system is considered to be depricated, I'm not sure how mich time I'm willing to invest in fixing this proble, as opposed to disabling it all together and start to move it's remaining functionality into the AI Traffic Manager system. As I wrote- I guess the error is somewhere in the ground code, the AI Ballistic Objects like the wingmen.demo shows the same behaviour- aircrafts are jumping. But it sounds like a good idea to move AI Traffic into Manager system! Regards HHS still in work: http://www.hoerbird.net/galerie.html But already done: http://www.hoerbird.net/reisen.html -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
Am Dienstag, den 23.06.2009, 14:25 +0200 schrieb Melchior FRANZ: * Tatsuhiro Nishioka -- 6/23/2009 5:01 AM: I'm not so sure what it should look like, but at least it needs nil check for the property. That would only be cosmetics and just hide the fact that the METAR runway choosing code is now broken since Detlefs recent changes. I'm innocent on this. You sure meant someone else ;-) The METAR wind direction/strength is now published too late for startup.nas, so an aircraft isn't positionend on a proper runway if METAR is used. *This* is the problem that needs to be fixed, not the Nasal error message. startup.nas is/was a bit hackish, anyway. A proper solution would be to wait for the METAR wind and only then to set the runway and FDM. This would require to initialize the environment subsystem earlier. Then we could also drop the additional presets-commit and save some startup time. startup.nas could be dropped altogether. m. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Hi, On Sunday 14 June 2009 12:50:10 Frederic Bouvier wrote: it appears this commit broke the autostart feature of the 777. With it, the MFD are not lighting up. It's unfortunate because I am currently working on the ground radar. Sorry, I did not notice that this belongs to me ... Looking int that this evening. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
Hi Tim, On Saturday 20 June 2009 19:46:50 Tim Moore wrote: Actually, I am using osg::Vec3d and osg::Vec4d. I tend to view the SGVec types as redundant, but that's a personal preference. I don't mind using SGVec in the property system, but if I do that I would like to add an operator to SGVec* to provide a conversion to its internal OSG type. Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg. ... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... Yeah, but we do that in the OSG update phase, which is exactly when these updates are supposed to happen. Nothing that alters the scene graph can run during the cull and draw phases, but we have to be able to alter the scene graph at some point. Note that I distinguish between the application step, which happens before the update step and the real update step which is the update visitor's traversal. And in the mid term, we may run the application step in parallel to the cull draw step. So we will just have a very short serial update step. So, in this model - where I am heading to in the mid/longer term, this listener usage hurts. The point is well taken, but the property listeners would be on properties that are directly tied to the effect structures and are not in the main property tree. For the foreseeable future they will be set from C++ material animation code, but I don't see a real problem in setting them from nasal code. It's true that accessing the scene graph safely from multiple threads is going to be an interesting challenge... May be that does not hurt currently. But if there is a way around that kind of issue I would prefer to take that. May be we will make more use of a more distributed simulation system. In this case the listeners in the viewer would not be an issue anymore, but if you can see a way that would allow the simulation step to run in parallel with cull/draw, it would be good I think. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] property system extensions redux
2009/6/23 Mathias Fröhlich Well, from my point of view. I would prefer to have these. The reason is to have something self contained here. Sure we already rely on osg at many places. But if I build an aplication on simgear, I hope to have simgear classes there. SGProperties are simgear classes, and if you use the property system you may not want to rely on osg. ... also from my past experience switching to an other scenegraph, I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL. So looking at SimGear as a utility library for simulation applications, this make sense from my point of view ... So, even if you will need some more glue code, I would prefer to avoid osg classes in simgears parts that are not scenegraph related. The property system is such an area IMO ... This is an interesting point. I also use simgear and the property system in a variety of other projects, so whatever we do, we shouldn't make these low level libraries depend on OSG (which isn't available for instance on my little embedded UAV controller.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Hi, On Sunday 14 June 2009 12:50:10 Frederic Bouvier wrote: it appears this commit broke the autostart feature of the 777. With it, the MFD are not lighting up. It's unfortunate because I am currently working on the ground radar. Should work again now. Greetings Mathias -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] startup.nas
Just commited a hack for envrionment_ctrl.cxx. It now waits for the first METAR to arrive before proceeding with the initialization sequence. This prevents the nasal-dir-initialized signal being fired before a METAR has arrived. I more and more like the idea of removing startup.nas and implenting the automatic runway selection depending on METAR wind directly in the METAR-subsystem, probably enabled by a property. I didn't mark the hack as temporary because temporary solutions usually last longest ;-) For now, the message from startup.nas should have disappeared and automatic runway selection based on METAR wind should work again. Torsten -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
- Mathias Fröhlich a écrit : Hi, On Sunday 14 June 2009 12:50:10 Frederic Bouvier wrote: it appears this commit broke the autostart feature of the 777. With it, the MFD are not lighting up. It's unfortunate because I am currently working on the ground radar. Should work again now. Yes, it works Regards, -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens
Rather long title, eh? :D I'm getting an error with the Seneca II. IndependenVar property, ice/wing in Table definition is not defined. That's all. Even with debug logs, the rest of it is just JSBSim aerodynamic tables. They stop in that error. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens
Can you print the last part of the log or anything that the console dumps - that might help. Details! :-) Jon -Original Message- From: Victhor [mailto:victhor.fos...@gmail.com] Sent: Tuesday, June 23, 2009 5:03 PM To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens Rather long title, eh? :D I'm getting an error with the Seneca II. IndependenVar property, ice/wing in Table definition is not defined. That's all. Even with debug logs, the rest of it is just JSBSim aerodynamic tables. They stop in that error. --- --- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 777 broken Was: [Simgear-cvslogs] CVS: SimGear/simgear/scene/model SGPagedLOD.cxx, 1.9, 1.10 modellib.hxx, 1.10, 1.11 modellib.cxx, 1.16, 1.17 SGReaderWriterXML.cxx, 1.19, 1.20
Thanks, Mathias , was worried that I migt have a bunch of modifying to do :) Syd -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens
That's it. The rest of the log are just JSBSim tables. 2009/6/23, Jon S. Berndt jonsber...@comcast.net: Can you print the last part of the log or anything that the console dumps - that might help. Details! :-) Jon -Original Message- From: Victhor [mailto:victhor.fos...@gmail.com] Sent: Tuesday, June 23, 2009 5:03 PM To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens Rather long title, eh? :D I'm getting an error with the Seneca II. IndependenVar property, ice/wing in Table definition is not defined. That's all. Even with debug logs, the rest of it is just JSBSim aerodynamic tables. They stop in that error. --- --- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Seneca II not working after today's simgear update that fixed the screens
On Tue, 23 Jun 2009, Victhor wrote: Rather long title, eh? :D I'm getting an error with the Seneca II. IndependenVar property, ice/wing in Table definition is not defined. That's all. Even with debug logs, the rest of it is just JSBSim aerodynamic tables. They stop in that error. It looks like the Seneca might have property declaration ordering problems in the FDM config since the latest JSBSim update (simgear changes are unrelated in that case). I might have time to take a look after work. Btw Jon: Reset in FlightGear yields multiple /fdm/jsbsim property subtrees. I also think JSBSim in FlightGear is creating initfile.xml:s again, has anyone else seen that? Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
