Re: [Flightgear-devel] Spawning new AI instances
Frederic Bouvier wrote: Is there a way to create new instances of AIAircraft or another kind on the fly, just by adding some nodes in the property tree, or running a command from the telnet interface, that is, without modifying the source code ? Is there something planned in this direction ? Fred, Could you please hold off doing any work on the AI subsystems? I am investigating the possibilities to move parts of that code over to SimGear and it might be possible that functionality gets added in the move. Curt and I have agreed that we need some sort of DCS (Distributed Content System) that synchronizes instances of dynamic models between multiple running versions of FlightGear. That way a multi display setup of FlightGear will work with ATC/AIModels/AI Traffic (and MultiPlayer) code enabled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spawning new AI instances
Durk Talsma wrote: Hmm, that's an interesting thought, because that was actually one of the possible mechanisms that I had in mind for the traffic manager. That is, have the schedules managed by an independent program that would communicate with FlightGear through a network layer. In the end I decided not to go into this direction after doing some tests and finding that the the easiest way to do it was by adding the traffic manager as a subsystem to the main FlightGear program, specifically because the overhead of managing the schedules turned out to be a quite low. Doing this through a network remains an interesting option though... If you're going with the independant program route, then wouldn't it make sense to have the AI handled in that program - this way it could feed as many flightgear systems as you like, and they'll all have a consistent view of available traffic. If handled in this way there'd basically be no difference between an AI aircraft, and another instance of flightgear running over the network. It also presents some interesting opportunities for ATC when you have a consistent view of the world like this. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spawning new AI instances
Erik Hofman wrote: Frederic Bouvier wrote: Is there a way to create new instances of AIAircraft or another kind on the fly, just by adding some nodes in the property tree, or running a command from the telnet interface, that is, without modifying the source code ? Is there something planned in this direction ? Fred, Could you please hold off doing any work on the AI subsystems? I am investigating the possibilities to move parts of that code over to SimGear and it might be possible that functionality gets added in the move. Curt and I have agreed that we need some sort of DCS (Distributed Content System) that synchronizes instances of dynamic models between multiple running versions of FlightGear. That way a multi display setup of FlightGear will work with ATC/AIModels/AI Traffic (and MultiPlayer) code enabled. I see I should have read the entire thread before I replied :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FMC
Hi, Just a few words to let you know that I am working on that atm. I don't go into the details as it is still in early development stage but here is how I see it : - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; - the fmc talk to FG with the telnet protocol, reading and modifying properties when needed ; - the route can be given with the current databases (basic, runways, fix, nav and awy) - no sid/star since there is no database atm. - the FMC talk to the autopilot system - it should be able to do some computations about fuel, thrust and alt for econ flight, take off etc. Tip. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Harald said: - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compass turning error gone
I've just tried the 0.7.5 release and there is no wet compass turning error. When did that go away ? It's kinda important ... PS. I'm not receiving e-mail at my usual address for a while. Use this address or the list (since I can watch the archive). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compass turning error gone
Alex Perry wrote: I've just tried the 0.7.5 release and there is no wet compass turning error. When did that go away ? It's kinda important ... You and I had some private correspondence on this point a few months ago, and you were planning to look at the code when you had some free time. As far as I can tell, it has something to do with values reported by the FDMs, because you see the error with some aircraft and not others. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [ANN] Blender 2.34 released
This release contains one feature that I consider very important for fgfs: an excellent new UV unwrapper! Now there's no excuse for not texturing the Bo105 any more. :-) http://www.blender3d.org/cms/UV_Unwrapping.363.0.html Download and further information: http://www.blender3d.org/ m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [ANN] Blender 2.34 released
Melchior FRANZ schrieb: This release contains one feature that I consider very important for fgfs: an excellent new UV unwrapper! Now there's no excuse for not texturing the Bo105 any more. :-) also the EC130 coming soon ;-) http://www.ron-lange.de/ec130_stage1.jpg Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
On Thu, Aug 05, 2004 at 06:14:03PM -, Jim Wilson wrote: Harald said: - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; I like the idea of a FMC system. :-) It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. I know that it would have some advantages if the FMC were part of flightgear, however I tend towards an seperate program like Harald is planning. It could be easily networked so you could use an older computer with a small monitor to put the FMC/CDU on. The FMC program wouldn't even have to provide a text/graphics output necessarily. Would it work to have one node in the property tree that would contain the text on the CDU display ? The 3D cockpit could listen for changes to this node and when one happens, update the CDU display in the 3D cockpit... It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. How about the setup in a B747-400 with 3 CDUs (and AFAIR also 3 FMCs). For those building cockpits at home, having more than one CDU, each displaying different pages would be nice :-) Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [ANN] Blender 2.34 released
Ron Lange wrote: Melchior FRANZ schrieb: This release contains one feature that I consider very important for fgfs: an excellent new UV unwrapper! Now there's no excuse for not texturing the Bo105 any more. :-) also the EC130 coming soon ;-) http://www.ron-lange.de/ec130_stage1.jpg Promising. I suppose you already know this page : http://www.eurocopter.com/ec130/fmaindims.html -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Jim Wilson wrote: Harald said: - it's an external application because there is no need to put it in FG code and there would be some complication with the display and keyboard part ; It would actually be very nice to have a FlightGear subsystem for this. Even nicer if it was possible to configure features via an xml config file (since not all FMCs are exactly the same). You can still manipulate data through the property system. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. Having recently thought about means to add FMC functionality to FlightGear myself I would agree with Jim here, there are really many different kinds of FMCs - some with pretty basic functionality and others providing pretty advanced stuff. So, having a basic subsystem as a backend and using XML files as well as possibly also some kind of basic skinning mechanism would certainly be a good approach for the whole FMC thing, since it would not be specific to a certain model or implementation but would rather provide a general dynamic framework for FMC creation/customization - pretty much like the current appraoch to define aircraft or panels. Regarding the GUI, this may be really mainly about adding support for skins and defining clickable regions and possibly different states of buttons - but I would not be that much in favour of using basic PUI elements for these purposes, this might be okay in the beginning but later there should be really support to load a skin and assign certain regions to certain functions/actions or simply events that can be dealt with by using Nasal. Most of the internal logics could certainly be very well handled using Nasal that then accesses the flight parameters via the Property Tree directly. The maths involved for the FMC calculations should also be possible to be realized using Nasal, I'd think - and then there'd still be the option of adding the more complicated stuff as a separate command. That way the CDU could be implemented using some basic skinning mechanism and defining those regions that are clickable and where Nasal should act and then there would need to be a general control for screen output, possibly defining some basics like fonts, rows/colums and available colors - as well as possibly some minor controls like LEDs to display a status information or anything like that. An approach like the one suggested by Jim would certainly have the potential to add many variations of FMCs simply because it would be mainly a thing of specifying the appeareance and logics using a XML file with some Nasal code. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FMC
Manuel Bessler wrote: I know that it would have some advantages if the FMC were part of flightgear, however I tend towards an seperate program like Harald is planning. It could be easily networked so you could use an older computer with a small monitor to put the FMC/CDU on. The FMC program wouldn't even have to provide a text/graphics output necessarily. regarding the ability to easily network it, pretty much all necessary data for that purpose should already be available via the exported property tree, I'd think - of course using a separate machine for that purpose is an interesting idea for some users and one which would not be taken care of if one simply used FlightGear internal implementations exclusively... Of course, if there's running X11 on that other machine, FlightGear could still provide the graphics for such an externally displayed CDU via network without the need to explicitly be running on that machine :-) Would it work to have one node in the property tree that would contain the text on the CDU display ? This should not be problem I think, except maybe that CDUs usually have several lines/columns with individual text and the actual layout differs from CDU to CDU, so you'd rather provide a general node with sub-nodes defining what's getting displayed and where. Also, I'd personally consider it not a good approach to add these things statically to a node, rather they should be possible to be dynamically modified by users who really want to design their own FMC, be it logically or really visually. It should be very easy to use the NewGUI feature (xml gui) to present a display with buttons as well as pc keyboard input. How about the setup in a B747-400 with 3 CDUs (and AFAIR also 3 FMCs). For those building cockpits at home, having more than one CDU, each displaying different pages would be nice :-) IF there is a basic framework for FMCs/CDUs it shouldn't matter how many of these are being displayed, in general it would make use of the same resources, the only thing that would really change is the data/mode being used, so it would be merely a matter of creating several instances of an FMC data object [arrays] to be able to differentiate between all these different systems. That way, each CDU could display specific data. But I'd agree that an approach to add FMC/CDU support externally does have its justification when it really comes to those professional users who are building their own cockpits or simply those users that are using those expensive external standalone CDU units. On the other hand I think one has to ponder about the pros cons, and certainly it would be more of an advantage for the AVERAGE user to have a GENERAL xml-configurable mechanism to add support for FMCs/CDUs to FlightGear than having merely a way to code your own stuff by accessing the property tree via network. As long as its underlying interface is general enough and also accessible within the property node, external software for purposes like the ones you mentioned above, could still easily make use of the functionality provided by FlightGear, while the majority of users could use XML-configured systems. -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
