RE: [Flightgear-devel] Adding external nasal bindings fgcommands toFlightGear by using Plugins ?
-Original Message- From: Boris Koenig Sent: 14 July 2004 11:18 pm To: FlightGear developers discussions Subject: [Flightgear-devel] Adding external nasal bindings fgcommands toFlightGear by using Plugins ? Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: snip Running make should only rebuild the parts of the source that have changed, and any parts of the source that are dependent on parts that have changed. You will always have to do the final link (20-30 seconds), but it shouldn't hit too much else. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. I am leaning towards the later (for FligthGear at least). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures and the Transparency Mask
Innis Cunningham wrote: The size of the model does not seem to effect frame rates in FG.I get nearly the same rate if I use the cessna or the an225.I have tried with the fuselage double sided and single sided the frame rates seem to be the same. There are others though for which this is becoming a problem... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Hi again ! I am just about trying to add some test-hooks to FlightGear, but wouldn't like to have to rebuild the whole FlightGear build tree each time (~ 350 MB ), just for 2-3 added small test-functions, hence I came up with the following idea: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. I am leaning towards the later (for FligthGear at least). I wouldn't like to see FlightGear becoming the swiss knife of everybody's need. I would prefer spending time to modularize even more FG and put more in SimGear. This way, everybody could use the library in their own program for the purpose they wish. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures and the Transparency Mask
Erik Hofman writes Innis Cunningham wrote: The size of the model does not seem to effect frame rates in FG.I get nearly the same rate if I use the cessna or the an225.I have tried with the fuselage double sided and single sided the frame rates seem to be the same. There are others though for which this is becoming a problem... The thing is is it the total number of vertices/surfaces in the model that determines the frame rate or is it also dependant on if the model is double sided or single sided. I guess what I am asking is if two models have the same amount of vertices /surfaces do they place the same load on the system. Erik Cheers Innis _ Need plastic Surgery? Apply for a Virgin Credit Card. Click here: http://ad.doubleclick.net/clk;9466596;9687279;s?http://au.virginmoney.com/virgin/publish.nsf/Content/VM+HomePage?OpenDocumentsource=P08 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures and the Transparency Mask
Innis Cunningham wrote: The thing is is it the total number of vertices/surfaces in the model that determines the frame rate or is it also dependant on if the model is double sided or single sided. Both. Double sided objects count for the fillrate. Using singe sided polygons can speed up rendering for a maximum of 150%. Some cards are limited to the number of vertices that can be rendered per second. I guess what I am asking is if two models have the same amount of vertices /surfaces do they place the same load on the system. That also depends. A small object will be rendered faster than a big object (because of pixel fill rate), but only if they are at an equal distance from the viewer. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands toFlightGear by using Plugins ?
Richard Bytheway wrote: Running make should only rebuild the parts of the source that have changed, and any parts of the source that are dependent on parts that have changed. You will always have to do the final link (20-30 seconds), but it shouldn't hit too much else. Ya, thanks for that - I know, but it's still 350 megs stuff that I need to keep on the drive, just for some minor changes ;-) Sorry, if I wasn't clear about that. Erik Hofman wrote: Boris Koenig wrote: How about adding a sub-directory lib to FlightGear/data/Nasal which could then keep plugins that implement external Nasal functions ? What do you think ? I don't particulalry like the idea. I'de much rather concentrate on imporving a FlightSimulator than on extening a scripting language. I agree -that was actually the very reason why I suggested something like that: *I* would take care of the plugin thing, so that *I* could easily add new Nasal stuff - and so I wouldn't have to bother you guys too much with my requirements anymore ;-) That way the number of bindings to Nasal are as low as possible which nakes it easier to use. I agree again, but there are some things that I would need to be added to Nasal in order to really be able to use Nasal INSTEAD of doing things _primarily_ in C++. And meanwhile, I've really come to the conclusion that I like the scripting approach - IF it allows for some more flexibility (see my previous postings) I realize there might be a difference between people who want a scripting language to do everything they need and people who don't want a scripting language except for some very specific tasks. Well, don't get me wrong - _I_ don't want Nasal to do everything, it's just that YOU suggested using Nasal instead of C++. I don't want to make Nasal a fully bloated programming language, but from what I can tell so far, there are about 6-10 additional commands that I might need in order to really be able to absolutely drop the C++ approach and concentrate on Nasal. So, my motivation is NOT to make Nasal bloatware, just to add things like support for : - dynamic population of statically defined panels/dialogs - simple file I/O (could be easily handleld by FlightGear itself - More advanced hooking techniques in order to allow for some simple dragging and dropping of instruments/dialogs within the authoring component of my FliteTutor concept. Regarding the latter, imagine a simple dynamic panel dialog editor that would be written using Nasal - this could even be integrated into FlightGear itself, users would be able to create panels dialogs by doing some dragging and droppinig of pre-defined FlightGear objects and this stuff would then be saved in a standard XML file using PropertyList syntax. I am leaning towards the later (for FligthGear at least). Yes, I can see - and this really wasn't meant to suggest Nasal should become a Visual Basic pendant within FlightGear - rather just for simpler adding of new functions/fgcommands. -- Boris P.S.: I've added a screenshot section to the webpage (http://flitetutor.sourceforge.net) to show what I've done so far (STATICALLY, using XML files) and what I'd like to be able to do on the fly with Nasal. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support. By saying this you imply to be looking at FlightGear in a much too commercial way. If the source is open there is little need for a plugin system. Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Airports and basic.dat.gz
Hi, I've compiled the CVS version of FlightGear but now I've a problem with the airports. The program, every 10 seconds, writes on the console the following message: cannot find KSQL in basic.dat.gz I've downloaded the CVS version of basic.dat.gz. I've also the latest scenery created and I've found that, instead, exists a file named KSQL.bgt.gz that, I think stores the airport data. Why this happens? How I can solve this (I've to remove the file KSQL...)? Tanks, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airports and basic.dat.gz
Luca Masera wrote: Hi, I've compiled the CVS version of FlightGear but now I've a problem with the airports. The program, every 10 seconds, writes on the console the following message: cannot find KSQL in basic.dat.gz I've downloaded the CVS version of basic.dat.gz. I've also the latest scenery created and I've found that, instead, exists a file named KSQL.bgt.gz that, I think stores the airport data. Why this happens? How I can solve this (I've to remove the file KSQL...)? I can confirm that behaviour exactly - did also recompile OpenAL/SimGear/FlightGear from CVS yesterday. Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: By the way, the addition of a plugin architecture has pushed all major flight simulators tremendously forward, I don't even mention stuff like Microsoft's FS, but I suggest to have a look at X-Plane: Since the author added support for basic plugins, there are numerous projects to interface with X-Plane, some of them concentrating on multiplayer stuff - others on specific things like integrated preflight-support. By saying this you imply to be looking at FlightGear in a much too commercial way. Sorry, you are definitely wrong, besides: there are not only commerical AddOns to X-Plane. I really don't have any commercial intentions. If the source is open there is little need for a plugin system. Well, I've heard that argument several times now - and of course you are right in saying that one COULD directly modify the FlightGear source code in order to incorporate some desired functionality. But do you really want to have to change the whole FlightGear code for some specific functionality ? To get back to the swiss army knife-example: I do think that example becomes legitimate when it comes to very specific requirements or ideas, the only alternative that remains then would be to create a branch of the original FlightGear source in order to add some specific functionality-something I would personally never consider... This is another point: How about people who have suggestions (possibly even a bit extraordinary) but who like these features to be OPTIONALLY being available in all FlightGear versions ? Speaking of myself now: while I pondered about the pros cons for a FlightGear enhancement such as the FliteTutor concept, I would have really love to be able to do this via some kind of plugin structure. This also for the very same reason that we can currently watch here: people feel differently about certain features, enhancements or suggestions. And I do understand this quite well. Let's consider the FliteTutor example again: IF I really start the first coding attempts,I will very likely have to add some commands to Nasal - and I really wouldn't hesitate to do this directly into FlightGear's source, BUT what we have then is ONE modified version with, that some people might still object against to integrate into the real branch. Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. I don't think that would be a major problem, there's other opensource (GPL'ed) software that makes use of modular enhancements (aka plugins)- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a module needs to provide the licence under which it is available in order to be loaded (This is a kernel 2.65 addition I think). Now you could argue that you will be opening up the source of the plugin, but I'm not so sure about others. Okay, that's a point - a point that hasn't yet been made. Personally, I really wouldn't have any problems about releasing any sources - except maybe, because of their lack of elegance ;-) But I think one could really find a solution for that problem, e.g. either by really making a plugin provide the licence under which it is available - and deny those plugins access, which do not specify an acceptable opensource licence OR by selectively maintaining an internal list (within FlightGear) of plugins that FlightGear would load (because they are opensourced). -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airports and basic.dat.gz
Boris Koenig wrote: Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight That must be a driver bug. The only thing --enable-specular-highlight does is enabling a hardware option (if available) that enables specular reflections on textured objects. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airports and basic.dat.gz
Erik Hofman wrote: Boris Koenig wrote: Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight That must be a driver bug. I've also thought about something like that, that's why I ran at least 5-6 other openGL software: there were not any problems with the software, but when I then restarted FlightGear, it seemed as if the openGL buffer would not have been emptied, because FlightGear displayed a screen of tuxracer - which I had run seconds ago,in order to test the openGL stuff. So, I am also about to think that there are some driver problems under certain circumstances, hence I will run the the FlightGear cvs version on another computer: but that's gonna require RECOMPILE :-/ The only thing --enable-specular-highlight does is enabling a hardware option (if available) that enables specular reflections on textured objects. well, I could disable it again and see if the same problems occur, and if they do I could see whether these are visible within a screenshot... Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. I don't think that would be a major problem, there's other opensource (GPL'ed) software that makes use of modular enhancements (aka plugins)- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a module needs to provide the licence under which it is available in order to be loaded (This is a kernel 2.65 addition I think). I'm still not convinced that a plugin system would be such a great idea for FlightGear. The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree. Adding new code is quite easy, but by introducing a plugin loader we would be put right back into the C world, using structures to pass variables around. Besides, most everything can be done in FlightGear without touching any code. Only special cases or additions need to be coded in C++. And I'm still not sure whether your flitetutor isn't outgrowing FlightGear's purpose. Adding a basic, menu accessible Flight Tutorial is probably in line with the project, but moving instruments around and even panel design within FlightGear is out of scope of the program I'm afraid. I would love to hear other opinions about that though. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project. I don't think that would be a major problem, there's other opensource (GPL'ed) software that makes use of modular enhancements (aka plugins)- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a module needs to provide the licence under which it is available in order to be loaded (This is a kernel 2.65 addition I think). I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree. Well, regarding the clever subsystem architecture - is there any more detailed information available ? Also, I have browsed the property tree and read all the docs about the property tree that I could get my hands on, but didn't find any details regarding how to disable subsystems like the FlightDataModelling, (in order to provide some instrument familiarization there would not be any need for such stuff be running in the background) Adding new code is quite easy, but by introducing a plugin loader we would be put right back into the C world, using structures to pass variables around. I think you are probably right in saying that FlightGear is already extremely advanced, but adding features by the means of plugins could also be done using some kind of higher level mechanism. But okay, this isn't that important right now. As I mentioned above: I am merely making suggestions. Besides, most everything can be done in FlightGear without touching any code. Only special cases or additions need to be coded in C++. That's exactly why I would _actually_ love to use the Nasal approach, though things like XML-handling might still be necessary to be added. And I'm still not sure whether your flitetutor isn't outgrowing FlightGear's purpose. it isn't meant to do so - it's should be merely an enhancement Adding a basic, menu accessible Flight Tutorial is probably in line with the project, Currently, this would be ONE of the supported modes that FliteTutor should be able to work in. By the way: there doesn't seem to be PUI-PopUp menu supported within the XML resources: how likely is it, that things like these could be added ? but moving instruments around and even panel design within FlightGear is out of scope of the program I'm afraid. Yes,regarding that argument you are probably not entirely wrong, if you remember my original plans for the whole thing (which are also still available on the webpage, I think) you'll notice that I had originally planned to develop the authoring component using QT - OUTSIDE of FlightGear itself. Simply BECAUSE OF things like interactive dragging dropping of components. While the player would be integrated within FlightGear - possibly as a set of Nasal scripts. But again, things like dragging dropping of panels would already be one of the more advanced features and is not really considered realistic to be implemented in the near future. I would love to hear other opinions about that though. You are actually about to give pretty good reasons for a plugin architecture by implying that the FliteTutor concept is a bit too special - and as I mentioned above, I do somewhat agree with you, at least regarding these more advanced features - and I haven't even yet mentioned those other utopic suggestions that I received ;-) The options that I would be left with in such a case would really be mainly: - either grab, understand and modify the FlightGear sources in order to start a branch which supports the necessary additions (unlikely to happen !) - at least add dynamic Nasal extension support by the means of plugins in order to be able to call some more advanced Nasal commands So, my intention would definitely be to make this whole thing GENERALLY available - I certainly wouldn't start to create my own FlightGear version just for some learning stuff to be integrated. I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels). - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Airports and basic.dat.gz
Boris Koenig wrote: Besides there occured some OpenGL problems (weird graphics) which I could only solve by disabling some rendering options such as --disable-specular-highlight Some time ago I've noticed something related to it in the precompiled version that I've downloaded (sometimes the textures appear throught a red transparent surface) but now it appears ok in the CVS version. Chris Metzler wrote: This is a known issue; if you check back in the archives of this mailing list, it's been discussed. I'm not sure what component of the software wants KSQL to be present; maybe there's some AI traffic involving KSQL. Someone else here (Erik?) probably knows about that. But the problem is that the latest set of airport data from Robin Peel has some issues, and one of them is that San Carlos Airport (KSQL) wasn't included in the new airport dataset at all. So I expect that this will go away when the fixed airport data, and thus fixed scenery tile, becomes available. Ok; what about using the old data stored in airports, or it's incompatible? And it's possible to add the missing lines in the file getting them from the old one? Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Boris Koenig wrote: I wouldn't have a problem, creating the authoring part of the application as an external application - but THEN I would need to be able to load FlightGear resources (aircraft/images/panels). Ok. Lets start a *minimal* list of items that really are needed for this and skip the implementation part for now. This is what I think what would be needed (feel free to add your ideas). * A configurable, interactive menu system. * The ability to load a set of sheets, one after each other. * Be able to add the following to these sheets: - Dynamic text at a static location (*) - Static images (*) - Animated instruments that react to actions of the user(*) * Pop-up screens to guide a user. * Disable unwanted subsystems: - Out of the window view (* - including scenery loading?) - FDM (* - using the NULL FDM) - Multiplayer (*) - AI Traffic/Models/ATC (*) - Sound (*) - Environment Anything else (remember, this is the *absolute minimum*)? Erik (*) This can be done now already. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Erik Hofman wrote: * The ability to load a set of sheets, one after each other. * Be able to add the following to these sheets: - Dynamic text at a static location (*) - Static images (*) - Animated instruments that react to actions of the user(*) Most of this sounds like the existing GUI layer. I was thinking a while back about writing a Pui widget that allows you to put a 2D instrument (with hotspots) onto a GUI dialog. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote:
Erik Hofman wrote:
Boris Koenig wrote:
Frederic is right that a plugin system is actually in contrast with
the GPL (FlightGear's license), that requires everything to be
opened when using some piece of GPL software within your project.
I don't think that would be a major problem, there's other opensource
(GPL'ed) software that makes use of modular enhancements (aka
plugins)- the most prominent example being the Linux Kernel itself,
whose plugin architecture meanwhile supports licence-validation - i.e. a
module needs to provide the licence under which it is available in
order to be loaded (This is a kernel 2.65 addition I think).
I'm still not convinced that a plugin system would be such a great
idea for FlightGear.
Well, I am just making suggestion :-)
The project has outgrown C and even C++ by using some clever subsytem
architecture and by using the property tree.
Well, regarding the clever subsystem architecture - is there any
more detailed information available ?
It's actually quite simple, you create a derived class from SGSubsystem
and you have to define a small set of functions:
class FGFX : public SGSubsystem
{
public:
FGFX ();
virtual ~FGFX ();
virtual void init ();
virtual void reinit ();
virtual void bind ();
virtual void unbind ();
virtual void update (double dt);
}
The init() functions should make sure everything is set and ready so the
update() function can be run by the main loop. The reinit() function
handles everything in case of a reset by the user.
The bind() and unbind() functions are to tie and untie properties.
The you can register this class at the sub system manager:
globals-add_subsystem(fx, new FGFX);
Now the sub system manager calls the update() function of this class
every frame. dt is the time (in seconds) elapsed since the last call.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Andy Ross wrote: Erik Hofman wrote: * The ability to load a set of sheets, one after each other. * Be able to add the following to these sheets: - Dynamic text at a static location (*) - Static images (*) - Animated instruments that react to actions of the user(*) Most of this sounds like the existing GUI layer. I was thinking a while back about writing a Pui widget that allows you to put a 2D instrument (with hotspots) onto a GUI dialog. Yes. An alternative would be to load different panels as sheets, one after each other. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Boris Koenig wrote: Erik Hofman wrote: I'm still not convinced that a plugin system would be such a great idea for FlightGear. Well, I am just making suggestion :-) I think most of the criticism centers on the idea that, even if you had a nice plugin system available, it really isn't going to help you very much with doing extension development. It doesn't change the existing Nasal or FGCommand interfaces at all, and adds an extra layer of complication. Basically, you have to write a little extra code to avoid typing make quite as often. That's not a very good tradeoff. The idea of a plugin comes from the commercial software world, where distinct entities (Microsoft and aircraft vendors, for example) need to ship software on different schedules. It's a solution to a problem that, honestly, we don't have yet. We aren't that big. I think as you get used to the existing architecture, you will find that most of the extensions you are thinking of are best implemented as augmentations (or even rewrites) of pre-existing code instead of pluggable, not-quite-orthogonal extra features. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgtie in route_mgr
Here are some fixes so that a property element is tied to the route manager list. Would someone with cvs access check these and commit them to cvs? http://www.halcyon.com/wturner/fgfs/route_mgr.hxx http://www.halcyon.com/wturner/fgfs/route_mgr.cxx Thanks, Wendell ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Adding external nasal bindings fgcommands to FlightGear by using Plugins ?
Erik Hofman wrote: Boris Koenig wrote: Well, regarding the clever subsystem architecture - is there any more detailed information available ? It's actually quite simple, you create a derived class from SGSubsystem and you have to define a small set of functions: Thanks for that (REALLY !) But actually I was really asking WHAT subsystems exist, how they are called (names, not programming !) and what their purpose is. I indicated already a couple of days ago, that I wouldn't mind writing some documentation, and I think these details are still missing, one could even present such information in a graphical way (as I mentioned already) Later, one could add the properties that affect a certain subsystem. I think this would really make for some good introduction into FlightGear developing, I would certainly find it easier to dive into the code if such things were generally available. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FliteTuror (Was: Adding external nasal bindings fgcommands)
Erik: you are causing some trouble over here, actually I didn't want to
change the project's sourceforge name, but I appreciate you taking the
time to make even another suggestion ;-)
Erik Hofman wrote:
Boris Koenig wrote:
I wouldn't have a problem, creating the authoring part of the
application as an external application - but THEN I would need
to be able to load FlightGear resources (aircraft/images/panels).
Ok. Lets start a *minimal* list of items that really are needed for this
and skip the implementation part for now.
Okay, no problem - so you are now only talking of the Player
part, right ?
This is what I think what would be needed (feel free to add your ideas).
okay, then I'll write down those things that I'd like to be able to
do *interactively* using Nasal (i.e. don't want to rely on static files)
* A configurable, interactive menu system.
yes, this could easily be done by making the menu system available
via a set of nodes in a corresponding property tree.
*But this is currently NOT essential* - the menu(bar) itself is less
likely to be changed that often - compared to other GUI elements.
So, I would not even add it to the minimal list right now - but IF
it gets implemented it would make sense to add some kind of
Nasal function to globally register Nasal based addons, that way
I would not have to use a certain Menu named FliteTutor but rather
could register FliteTutor to be loaded within a menu called Addons
or something like that.
* The ability to load a set of sheets, one after each other.
right, I have looked into the sources and think that should be also
possible to be achieved using some specific node in a property
tree (I gave some examples in one of my last eMails).
What I am now using - for testing purposes is:
/addons/FliteTutor/player/pages
and
/addons/FliteTutor/player/currentpage
While the former is an object that contains all necessary properties
for a specific page, like:
pages[0]/position/x
pages[0]/position/y
etc.
And the latter property specifies which of the pages in player/pages
is currently being displayed and hence should be read from the prop tree.
(Since, I don't yet know how to save load this stuff using Nasal, I am
setting it up each time in order to have some stuff available)
* Be able to add the following to these sheets:
- Dynamic text at a static location (*)
...also DYNAMIC positioning - this could be also implemented using
a specific node in the property tree.
text = setprop(/subsystem/../createTextWidget,1);
setprop(text,position/x[0],100);
setprop(text,position/y[0],200);
and if possible, some simple formatting would also come in handy-
like 2-3 different font sizes, BOLD and UNDERLINED text:
setprop(text,font/format/size[0],LARGE);
setprop(text,font/format/bold[0],1);
This would probably already be sufficient regarding font handling.
- Static images (*)
yes, images won't get created on the fly, for any other dynamic
image based contents I would make use of animations.
But it would be useful if I could not only specify their
position in some XML file but rather do this dynamically -
I think I did also provide a pseudo (nasal) code example
in of my last mails.
Something like:
//Create Image
img = setprop(/subsystem/createImg[0],1);
//file
setprop(img,filename[0],sample.gif);
/*OPTIONALLY, it might be useful if I could directly provide a
binary or hex-encoded buffer to that function, in order to
enable storing of images WITHIN a XML file:
image type=JPEG name=drawing
0xFF,0xFF,0xFF,0xFF,0xFF .
/image
And load this then by doing the following in Nasal:
readXML = func {
// function to retrieve contents of a section within a
// particular XML file
}
data = readXML();
setprop(img,buffer[0],data);
Even though that's not particularly elegant,
it would enable EASY exchange of modules, since
these wouldn't have any external dependencies
but could rather store all resources (e.g. images,
sound) within a module, EVEN if these are binary.
*/
//Position
setprop(img,position/x[0],100);
setprop(img,position/y[0],200);
//Dimensions
setprop(img,dimensions/x[0],100);
setprop(img,dimensions/y[0],100);
- Animated instruments that react to actions of the user(*)
yep, as well as being animated by the player - for illustrative
purposes, but this isn't a problem I think, as I got an example to
work already.
But again, I don't want to rely on external XML files :-)
* Pop-up screens to guide a user.
right, I'm currently using a statically defined dialog with
a fixed width, what I considered being useful AND powerful
(also for FlightGear itself!) would be a template based
RE: [Flightgear-devel] Spitfire
I wrote Sent: 09 July 2004 09:53 To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] Spitfire David Megginson wrote Sent: 09 July 2004 00:24 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Spitfire Vivian Meazza wrote: There should also be a version with the legacy code, and that does fly (or rather, does for me), although the performance is a bit down. I don't think that there is an error in the code, but I'll double check with the legacy version Thanks. It's a beautiful model, by the way. Thanks for that - I have an upgraded version with a more accurate cockpit nearly ready to go. There is a real Spitfire based at my home airport -- I actually gave up my parking place for it during our Fly Day a couple of weeks ago. It's normally over on the south field, but I love watching it take off when it's at our end of the airport. If only the plane had an extra seat ... I've tested the CVS version (legacy propeller/engine code) under FGFS 0.9.4 (windows version). Flies OK. 'Evidence' attached. I can't test under CVS source code: frame rate too slow on my computer, which I will upgrade in the very near future. Perhaps that will solve the problem, or, more likely, since I'm doing it myself, I'll lose all the data and take 2 weeks to recover! Back up with an upgraded machine - 2.8 Mhz P4, 512 Ram, Gforce 5200. I've rebuilt Cywin, and FGFS-CVS. I've just copied the latest version of the Spitfire from FGFS-0.9.4, where it was working, after a fashion, to FGFS-CVS. All the files. Now it won't fly, as David pointed out. Back to the drawing board! Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] How FlightGear handles 3ds
Bump. So, is my idea a good one or a bad one? There doesn't seem to be much response... Regards, Ampere On July 10, 2004 05:20 pm, Erik Hofman wrote: Ampere K. Hardraade wrote: New animation type as in specifying the effects in the XML file? If so, that is what I was thinking as well. Yep. That's what I meant. Erik On July 9, 2004 03:57 pm, Erik Hofman wrote: Ampere K. Hardraade wrote: I know. It is like the way things are done in 3D Studio. Unfortunately, most of these features aren't working with 3ds format in FlightGear. I even had a specular level problem at the very beginning. As for illumination, it is better done by a mask rather than selecting material property. For example, the logo light only shines on certain portion of the vertical stabilizer, not the entire thing. From the way things looked, it doesn't seem that AC3D can handle this effect either. Nor can OpenGL do this easily. This kind of effects is probably best done using a new animation type rather than using fancy 3D modeler options. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] The Orange Book
FYI A few months ago, the OpenGL Shading Language -- OpenGL's own high-level shading language for programming Graphics Processing Units (GPUs) -- was ratified by the Architectural Review Board (ARB) responsible for the development and extension of the OpenGL graphics API. The first real-world implementations are just becoming available in the latest graphics drivers of the big graphics hardware vendors. Now the first book that features this new shading language is available, with the intention of becoming the standard book on the subject. Randi J. Rost's OpenGL Shading Language (published by Addison-Wesley) is a good introduction to developing shaders with the new OpenGL Shading Language, and demonstrates a number of useful applications for real-time programmable shaders. Read on for the rest of Ecker's review. http://books.slashdot.org/books/04/07/15/162242.shtml?tid=126tid=137tid=152tid=156tid=185 Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
