opengc-devel Mailing List for Open-source Glass Cockpit (OpenGC) (Page 5)
Status: Pre-Alpha
Brought to you by:
madmartigan
Menu
▾
▴
opengc-devel — Developer's discussion list
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(22) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(12) |
Oct
(31) |
Nov
(6) |
Dec
(2) |
| 2003 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(9) |
May
(18) |
Jun
|
Jul
|
Aug
(7) |
Sep
(56) |
Oct
(23) |
Nov
(7) |
Dec
(7) |
| 2004 |
Jan
(2) |
Feb
(2) |
Mar
(7) |
Apr
(26) |
May
(3) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(6) |
Nov
(5) |
Dec
|
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: John W. <ca...@mm...> - 2003-09-29 15:12:55
|
Hi Damion, Like you, I have been both disappointed and puzzled by the singular lack of support and interest within the sim community (hardware and software) for projects like OpenGC. Yet there are any number of websites about projects and individuals building flightdecks, selling software, and offering all forms of products and services. Over the course of the past year I been focused on expanding the FG and OpenGC interaction and network design. The result is that my system has evolved into a highly customized simulation with FlightGear and OpenGC. Throw in recent hardware designs ( and software drivers ) that provide for throttle/control input, momentary and static switches, rotary encoders, light and LED displays, etc and one has pretty much all the technical means to build a world class simulator. Just a question of high deep are your pockets for cockpit hardware and visual systems and how much time to devote to construction. I am still troubled by your claim regards the source and copyright. The code was moved from SourceForge so there is a question of continuity and again I don't think CVS logs (which can be altered and edited) are sufficient proof. I can recall making and committing changes to all segments of the OpenGC code from the make files to basic modules such as ogcAppObject, ogcRenderWindow, and ogcDataSources. So again, I would challenge your claim of copyright and lay claim to those portions and modifications within the larger document(s). Again, if you wonder why there is a lack of interest, perhaps this is a good reason. Regards John W. |
|
From: Damion S. <be...@cs...> - 2003-09-29 05:26:26
|
This has been bothering me a bit, so I did a bit of research... From the GNU website (see http://www.gnu.org/licenses/gpl-faq.html ) Q: I would like to release a program I wrote under the GNU GPL, but I would like to use the same code in non-free programs. A: To release a non-free program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times. Q: Is the developer of a GPL-covered program bound by the GPL? Could the developer's actions ever be a violation of the GPL? A: Strictly speaking, the GPL is a license from the developer for others to use, distribute and change the program. The developer itself is not bound by it, so no matter what the developer does, this is not a "violation" of the GPL. However, if the developer does something that would violate the GPL if done by someone else, the developer will surely lose moral standing in the community. Q: Can the developer of a program who distributed it under the GPL later license it to another party for exclusive use? A: No, because the public already has the right to use the program under the GPL, and this right cannot be withdrawn I believe this is in line with my proposition for how to handle any potential commercialization of the portion of OpenGC for which I am the exclusive copyright holder. It also confirms the point that the version of OpenGC as it exists must always be available under the GPL, and that no claim can be made to the contrary. In other words, I have no right to EVER dispute how the current version of OpenGC is used, as long as such use complies with the GPL. Hopefully this clarifies things a bit. The "lose moral standing in the community" bit mentioned above is why I'm discussing this ahead of time. Cheers, -Damion- --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
|
From: Damion S. <be...@cs...> - 2003-09-29 05:06:59
|
Hi, Please be assured that I _am not_ making any claims of exclusivity regarding code within OpenGC. As I said, this is merely a request for comments, NOT a plan of action. > Whoaa.. I seem to have a copy of an email where you expressed " I like > what > you've done with the VVI" so before you go making any claims of > exclusivity > suggest you tread very lightly. And there are several shots of a Nav > Display circa Feb 2001 produced by myself. And there may have been > others > that made incremental changes and contributions. I don't think CVS > logs > hold ground truth. The current nav display, insofar as the map portion is concerned, was written entirely by myself, completely from scratch. It does not use any code from Simgear, nor is it based on the nav display contributed 12 months ago by Jurgen and Michael. This can be easily verified by looking at the code in the CVS repository. The overlay - VorCntr - is, as you point out, code you contributed some time ago. Again, I AM NOT claiming sole authorship of OpenGC; I would like to make this point extremely clear. In the presentation I gave at Avsim 3 days ago, I included a slide with the following credits: John Wojnaroski (777 EICAS & FlightGr.) Michael DeFeyter (737NG) Jurgen Roeland (737NG) Jeff Ray & PCFlightSystems (EGyro) The many authors of the software libraries used by OpenGC Also note that there are many files within OpenGC for which I am not even a contributing author, much less the original author, for instance ogc747EICAS.cpp, all of the 737 code, the FMC, MCP, and John's original navigation code (this is not an exhaustive list). > Have not read all the details and finer points of the GPL but I think > you > need the concurrence of ALL the developers and contributors (past and > present) to make any changes to the license. I agree. I am not _at all_ suggesting that the current license be changed for the code as it exists in the CVS repository. All of the current codebase would remain GPL'd forever. However, as I said, a good portion of OpenGC has _never_ been modified by a third party. The GPL merely states that if a license is changed on the file it must be done with the full agreement of all of the copyright holders (contributors) to that code. In many cases in OpenGC, particularly in the base portion of the code (the ogcGauge and ogcFontManager classes to name two), I am the sole copyright holder of the code. As I mentioned above, there are other cases where different authors are the sole copyright holder of the file in question. This brings up a few issues I would like to raise for the community as to why I am considering close-sourcing this project at all. Contrary to what it might seem like, I am not discussing this for the sole purpose of pissing people off. 1) There have been _no_ CVS submissions by persons other than myself since mid-September of last year; the most recent submissions were by Jurgen and Michael, with their 737 code. They have since left OpenGC and started their own project. This means that for the past 12 months, I have been for all practical purposes the sole developer of OpenGC. As you might imagine, this is a bit frustrating, since the original intent of the project was to encourage submission of gauges from the community. I can only conclude that the community is (with a few notable exceptions, John included), not interested in contributing. 2) Despite the open source nature of FlightGear, no one has stepped forward to maintain the data source object. There has been only one significant change to that in previous 18 months - a rewrite I did of John's original data source using Plib instead of Unix code - so I can only conclude that the actual level of interest in home cockpit construction using FlightGear and OpenGC is similarly low. A good deal of the code that originally worked with FlightGear - the FMC and MCP - has been non functional for nearly a year because of lack of support. I raise these points not as a criticism, merely as an observation. I am not attempting to belittle anyone's contributions to OpenGC, but the fact remains that for the past 12 months very little has been contributed by the sim community at large. If there is not enough interest in this sort of project to create a viable product using open source methods, then it may be time to move the project in a different direction. A few final points that bear repeating: 1) I have been careful to credit other developers both publicly and in the source code. 2) I have NO INTENTION of ever using code contributed or modified by persons other than myself in a commercial product. 3 These are discussions only; I have no interest in running off with OpenGC in the cover of night. If this were my goal, I would not be soliciting feedback. Cheers, -Damion- --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
|
From: John W. <ca...@mm...> - 2003-09-29 00:32:44
|
> If commercialization were to occur, and I emphasize IF, I propose the > following: > > 1) All of the current OpenGC code would remain publicly available and > licensed under the GPL. > > 2) Any code contributed by authors other than myself, and any code not > part of but used by OpenGC that is GPL'd (i.e. Simgear) would not be > included in any commercial product, to satisfy the GPL. Code which is > not authored by me includes the 777 EICAS, 737 PFD and EICAS, and the > original version of the FlightGear data source. According to CVS logs I > am the only developer who has touched the majority of the other files; > I am happy to provide documentation of this to anyone who asks. > Whoaa.. I seem to have a copy of an email where you expressed " I like what you've done with the VVI" so before you go making any claims of exclusivity suggest you tread very lightly. And there are several shots of a Nav Display circa Feb 2001 produced by myself. And there may have been others that made incremental changes and contributions. I don't think CVS logs hold ground truth. Have not read all the details and finer points of the GPL but I think you need the concurrence of ALL the developers and contributors (past and present) to make any changes to the license. Regards John W. |
|
From: Damion S. <be...@cs...> - 2003-09-28 20:35:41
|
Hi, I wanted to give everyone a report of the feedback I received after "unveiling" OpenGC at the Avsim conference in Reading yesterday (I gave a 40 minute presentation). The overall reaction was extremely positive; in fact, amazingly so. It appears that there is more of an interest in glass cockpit software than I had thought. I spent several hours today talking with both Enrico Schiratti (developer of Project Magenta) and Austin Meyer (developer of X-Plane). Having met both of them in person, I would like to put to rest negative claims that have been made about both; they're extremely cordial guys, and quite supportive of OpenGC. Both Enrico and Austin (Enrico in particular) had interesting thoughts on developing sim add-on software, and some of their opinions have caused me to rethink the place of OpenGC within the simming community somewhat. As the result of conversations with them and a number of conference attendees, I would like to summarize the feedback I received regarding OpenGC: 1) People are impressed with its multi-platform, multi-sim capabilities. 2) The open-source nature of the project is not, in and of itself, a selling point of the project (keeping in mind that this is largely a FS200x, and to some extent X-Plane, oriented crowd). I have personally believed that the main thing that differentiates OpenGC from Project Magenta (and indeed other cockpit efforts) is it's multi sim/platform support. While I do not wish to make product announcements for other projects, it is worth noting that this will likely _not_ be true for the indefinite future. Take that for what you will... This means that OpenGC will soon need to offer a compelling feature set, rather than resting on the status of supporting everything under the sun. To that end, I have started to rethink the nature of OpenGC. I would caution everyone that these are _only_ preliminary thoughts and I'm primarily interested in soliciting feedback. In a nutshell, during the drive home today, I have debated adding a payware/closed source aspect to OpenGC. My reasons are as follows: 1) Closed source development creates a viable business model that would allow development of gauges for which there is a non-trivial development & distribution cost. For instance, gauges based around commercial terrain and map databases (for which there are no freeware alternatives). 2) The homebuilt aircraft/EGyro component of OpenGC developed this summer will need to be accompanied by physical hardware development, which will require purchase of hardware in the multi thousands of dollars range. I am unable to float the cost of this myself with no expectation of return (for obvious reasons), which would essentially block development of what I think is a potentially very valuable addition to general aviation. If commercialization were to occur, and I emphasize IF, I propose the following: 1) All of the current OpenGC code would remain publicly available and licensed under the GPL. 2) Any code contributed by authors other than myself, and any code not part of but used by OpenGC that is GPL'd (i.e. Simgear) would not be included in any commercial product, to satisfy the GPL. Code which is not authored by me includes the 777 EICAS, 737 PFD and EICAS, and the original version of the FlightGear data source. According to CVS logs I am the only developer who has touched the majority of the other files; I am happy to provide documentation of this to anyone who asks. 3a) A full executable version of the commercial OpenGC that functions only with FlightGear (or any future open source simulators) would be available, free of charge, in perpetuity. This is to encourage development of open source simulators. 3b) A "lite" executable version of the commercial OpenGC, supporting a selection of generic gauges, would be available to the commercial simming community free of charge, to promote the hobby among younger simmers who are working on limited budgets. 4) The source code of OpenGC (the commercial version, perhaps with specific gauges removed), would be available to academic institutions and personnel free of charge, for use in teaching or research. I believe that these changes would result in very little impact to the use of OpenGC within the freeware community. Very little gauge development has occurred within the past year by persons other than myself, leading me to believe that people are largely interested in _using_ OpenGC rather than designing within it. My personal goal of providing OpenGC as a teaching tool would continue with essentially zero modifications. This leaves the following as potential targets for full commercialization: 1) Development of more polished gauges, more in line with the Project Magenta work, and any gauges which require data unavailable in free format. 2) The homebuilt aircraft market. 3) Custom gauge development, either on a contractual basis or by licensing a copy of the OpenGC source for commercial development. Again, I caution everyone that this is not an announcement, merely a request for comments. Feedback is of course welcome, and I hope this does not come across as a criticism of those who HAVE contributed a great deal of their time to aspects of OpenGC's development (you know who you are). Thanks in advance for any feedback, and remember, regardless of what happens: 1) OpenGC will remain free for use with free simulators, with the added benefit of the free version being supported by commercial development. 2) The source will remain available to students and educators, for non-commercial use. 3) I'm not out to price-gouge anyone (neither is Enrico, for that matter - really). Cheers, -Damion- <donning flame retardant suit> --------- Damion Shelton The Open Source Glass Cockpit Project (OpenGC) Carnegie Mellon University, Robotics Institute http://www.opengc.org da...@op... |
|
From: John W. <ca...@mm...> - 2003-09-26 21:42:37
|
Hi Manuel, Thanks for the schematics. I wanted to sent you a couple but for some reason I can't move them from the clipboard after converting them to bitmaps. If you have the PCB layout software from ExpressPCB, I can send them to you in that format. Regards JW ----- Original Message ----- From: "Manuel Bessler" <li...@va...> To: <ope...@li...> Sent: Sunday, September 21, 2003 3:45 PM Subject: Re: [Opengc-devel] Linux Hardware > Well... I do some home cockpit building (and its flightgear exclusivly :) > A friend and I were working on a fully enclosed B744 cockpit. But due to > space constraints and a few other reasons, we had to cancel that. Now he > has built a Piper Cub cockpit (that runs flightgear of course) > and I have parts like yoke, rudder pedals and throttle of our old 744 > cockpit here at home. > > I'd rather stay with opensource. > > When I post in a german home cockpit builders forum that I visit > regularly, all my posts have a signature line pointing to flightgear. :-) > > > Regards, > Manuel > > |
|
From: Wendell T. <we...@ad...> - 2003-09-25 16:45:29
|
> > Would this functionality be of interest to anyone else? > > Sure. The only thing I would suggest is that you write a new nav class > rather than adding it to NavTestGauge. As a subset to NavTestGauge, or a new instrument similar to the current NavTestGauge? > I will be making major modifications to that over the next > month and it would probably mess your stuff up. I have some changes that I'm doing to that instrument also: - tower airports in blue - non-tower airports in magenta - waypoints in brown(?) - flightplan route in magenta/white (like in a Garmin 430) - ADS-B targets - target, airport, and waypoint symbology Will this conflict with your changes? I'm not making any architectural changes, just enhancing the display. Are you working on the vor/adf needles? Any chance of those working soon? > The other thing to be aware of is that the nav stuff is > far from complete, and I can't promise that something fundamental won't > change hence breaking your code. Ok. I like what you've done so far, and want do what I can to add to it. > That said, let me know if you'd like write access to the CVS. Wow, what power! Wendell |
|
From: Damion S. <be...@cs...> - 2003-09-25 05:20:18
|
Hi, > So then, I would have the ogcNavTestGauge, upon initialization, > open the sockets? And in Render(), read the socket and > calculate the display? That would work, and I guess I was > trying to be too tricky in duplicating another DataSource. That should do it. > Would this functionality be of interest to anyone else? Would > you want it into cvs? Sure. The only thing I would suggest is that you write a new nav class rather than adding it to NavTestGauge. I will be making major modifications to that over the next month and it would probably mess your stuff up. The other thing to be aware of is that the nav stuff is far from complete, and I can't promise that something fundamental won't change hence breaking your code. That said, let me know if you'd like write access to the CVS. Cheers, -Damion- --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I hope if dogs ever take over the world, and they chose a king, they don't just go by size, because I bet there are some Chihuahuas with some good ideas. |
|
From: Wendell T. <we...@ad...> - 2003-09-24 17:46:13
|
On Wed, Sep 24, 2003 at 01:05:32PM -0400, Damion Shelton wrote: > > There can only be one data source in a render object; Ok, no wonder it wasn't working right! > Now, there is nothing to prevent you from adding specific network > functionality to a particular gauge, So then, I would have the ogcNavTestGauge, upon initialization, open the sockets? And in Render(), read the socket and calculate the display? That would work, and I guess I was trying to be too tricky in duplicating another DataSource. > My suggestion would just be to add network socket functionality to your > version of the nav gauge, that would execute each time a render call > came through. That way, all of the network traffic occurs locally and > is only visible to your code. Wilco. That sounds much easier than what I was trying to do. > Does this answer your question? Yes. Would this functionality be of interest to anyone else? Would you want it into cvs? Wendell |
|
From: Damion S. <be...@cs...> - 2003-09-24 17:06:45
|
Hmmm... I guess I'm not entirely sure what you're trying to do, so let me know if this is any help: There can only be one data source in a render object; this is because it's impossible to override the m_pDataSource member on a per-object basis, because it's a static member variable - see the first bit of main.cpp, the statics are initialized as: ogcDataSource* ogcRenderObject::m_pDataSource = 0; It was designed this way to avoid having to explicitly set the render window, data source, and font manager in each subclass of RenderObject, since there are so many of them. Now, there is nothing to prevent you from adding specific network functionality to a particular gauge, it would just have to be done internally with a different data source name (e.g. m_TCASDataStream). You would also probably _not_ want to derive it from the DataSource base class, since it's assumed that all data sources are capable of providing roughly the same information, and yours provides very specific information. My suggestion would just be to add network socket functionality to your version of the nav gauge, that would execute each time a render call came through. That way, all of the network traffic occurs locally and is only visible to your code. Does this answer your question? Cheers, -Damion- > I am trying to add another data source, specifically to the > NavTestGauge, but it isn't working. --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
|
From: Wendell T. <we...@ad...> - 2003-09-24 00:01:53
|
I am trying to add another data source, specifically to the NavTestGauge, but it isn't working. I was wondering if someone could provide some assistance. I want to have another udp input stream, similar to ogcFGDataSource.cpp. It would receive target data and display them on the Nav Test Gauge (somewhat like TCAS). I tried to follow how the FGDataSource is used (create a new instance in ogcAppObject.cpp; create a Set function in ogcRenderObject.h and ogcRenderWindow.cpp). These seem to work fine, as the new data source class is called, and the socket is opened. I think the OnIdle gets called, and reads the socket and parses the data. However, in the ogcNavTestComponent.cpp, the class seems to have been lost. It seems as if there are multiple instances of my new ogcTGDataSource class, and the instance doing the initializing and reading isn't the instance that the NavTestComponent has visibility to. I could have just jammed the udp reading into the FGDataSource section, but thought that possibly this was a better way. Suggestions? Wendell |
|
From: Manuel B. <li...@va...> - 2003-09-23 23:14:13
|
On Mon, Sep 22, 2003 at 11:18:35PM -0700, John Wojnaroski wrote: > Well, I've been trying to get the word out, but have had very few takers. > Posted a series of snapshots at the end of > May, seemed to get a lot of hits on the site, but very few questions or "How > do I get one of these?" So maybe it wasn't all that cool after all or those > who saw it (assuming it's mostly the FG audience) just weren't interested. > Once I get a little further along with the flightdeck I'll post a few more > pics The screenshots were great. But I cannot remember if you posted a link the the sources/your modifications. Are you working on getting your changes back into the main OpenGC development branch ? Maybe that would generate more "takers" :-) Regards, Manuel |
|
From: Gene B. <ge...@de...> - 2003-09-23 20:04:07
|
> > Here's something to think about - why not write a kernel mode driver for > > the Phidgets? Chester has made noises in the past about releasing the > > actual Phidget code (that runs on the uP on the board) under the GPL. I'm > > sure he'd be happy to give you any info you needed. I'd attempt it > > myself, but drivers are way out of my league. :) > > > > I sent off an email last week regards that board, but have not heard back. I > was planning to write one for Linux but afraid I don't do windows. I'll give > it a few more days and send off another email... > Windows is very well covered, it's Linux that needs the driver set. :) Chester is pretty busy - you might want to try calling him. I think there is a 800 number on his website. g. |
|
From: John W. <ca...@mm...> - 2003-09-23 19:55:14
|
> > > > I do like that 0/256/0 prototyping kit. Will it handle static switches and > > momentary switches? > > > > Thanks for the input. > > > > Here's something to think about - why not write a kernel mode driver for > the Phidgets? Chester has made noises in the past about releasing the > actual Phidget code (that runs on the uP on the board) under the GPL. I'm > sure he'd be happy to give you any info you needed. I'd attempt it > myself, but drivers are way out of my league. :) > I sent off an email last week regards that board, but have not heard back. I was planning to write one for Linux but afraid I don't do windows. I'll give it a few more days and send off another email... Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-23 19:35:42
|
> > I do like that 0/256/0 prototyping kit. Will it handle static switches and > momentary switches? > > Thanks for the input. > Here's something to think about - why not write a kernel mode driver for the Phidgets? Chester has made noises in the past about releasing the actual Phidget code (that runs on the uP on the board) under the GPL. I'm sure he'd be happy to give you any info you needed. I'd attempt it myself, but drivers are way out of my league. :) g. |
|
From: Damion S. <be...@cs...> - 2003-09-23 13:18:52
|
Well, just to chime in with my 2c... > pilot types I've worked with. But (here's the catch) since Damion went > off > on a different direction with the OpenGC project it's become > incompatible > and I just don't have the time, talent or resources to set up a > website and > CVS server or try to sync up with X-Plane or FSxxx. It runs under > Linux and > networks with FG, and is just as easy to set up as FSUIPC and has a > lot more To clarify, OpenGC did not go off in a different direction. The reason I made the decision to axe the older FlightGear interface is that it did not (and could not) build under Windows. This was the same reason that I switched to CMake over autoconf for the build system. The only reason (in my mind) that it's acceptable to not support all possible platforms is if it's not _technically_ possible, as with FSUIPC. I was concerned that the FlightGear stuff was evolving into a separate project within OpenGC, since the interface itself would not work on Windows and FMC would not work with other simulators (or under Windows). I certainly plan to offer cross-platform bidirectional communications along with a FMC in the future. The only thing I insist on is that whatever gets designed work in as generic a manner as possible. This is not the only way to do things - the FlightDeckSoftware guys have differentiated their project from OpenGC by choosing to only support FS200x and Windows, while offering a more complete feature set than OpenGC. However, the original premise of OpenGC was to try and be as cross-platform as possible, and I'd like to stick with that. Cheers, -Damion- --------- Damion Shelton Carnegie Mellon University, Robotics Institute A408-o Newell Simon Hall 412.268.3866 (office) 412.818.8829 (cell) 412.268.6436 (fax) http://www.cs.cmu.edu/~beowulf --------- I hope that after I die, people will say of me: "That guy sure owed me a lot of money." |
|
From: John W. <ca...@mm...> - 2003-09-23 06:20:02
|
> > It runs under Linux and > > networks with FG, and is just as easy to set up as FSUIPC and has a lot more > > potential and will remain free under the GPL license.. > > > While you might have some really cool stuff running, if no one has heard > that it's been done then how will they know they've got a choice? :) > Well, I've been trying to get the word out, but have had very few takers. Posted a series of snapshots at the end of May, seemed to get a lot of hits on the site, but very few questions or "How do I get one of these?" So maybe it wasn't all that cool after all or those who saw it (assuming it's mostly the FG audience) just weren't interested. Once I get a little further along with the flightdeck I'll post a few more pics > The problem with FG right now is that they're concentrating on the "sexy" > features and letting the back end slide a bit. Curt is helping cure this > a bit with the recent aircraft tree reorg. > The network aspects could use a little work. Actually, the interface protocoils to FG are quite numerous but it requires a little more work than FSUIPC but with the plib library it's not all that difficult and well worth the effort. Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-23 01:55:21
|
> > The lack of "amateur" use of FG is most likely due to the high barrier of > > entry (you _must_ know what you're doing) and the lack of cockpit oriented > > third party infrastructure. > > > I like your use of the word "amateur" I was struggling to find the right > expression. It's sorta a chicken and egg thing, provide the support and > you'll have an audience that will justify the effort to produce the support > Bingo. :) > I talked over a year ago with the Magenta folks and all it left in my mouth > was a bad taste, what an arrogant bunch of SOBs and their stuff is not all > THAT great. I've got stuff running derived from OpenGC which is a full 747 > flightdeck with a functional FMC and better,as attested to by a few airline > pilot types I've worked with. But (here's the catch) since Damion went off > on a different direction with the OpenGC project it's become incompatible > and I just don't have the time, talent or resources to set up a website and > CVS server or try to sync up with X-Plane or FSxxx. It runs under Linux and > networks with FG, and is just as easy to set up as FSUIPC and has a lot more > potential and will remain free under the GPL license.. > While you might have some really cool stuff running, if no one has heard that it's been done then how will they know they've got a choice? :) > So true. the FG crowd is rather an ecclectic bunch (based mostly on the > email one sees) and just no way of knowing who else is out there or were > their interests lie. ATM the task(s) de jour seems to be building airplane > models and cultural features. And it is becoming a little top-heavy. IMHO it > needs a got technical thrashing by a couple of heavy-duty gearheads to > improve performance and supportability. > The problem with FG right now is that they're concentrating on the "sexy" features and letting the back end slide a bit. Curt is helping cure this a bit with the recent aircraft tree reorg. g. |
|
From: Wendell T. <we...@ad...> - 2003-09-22 16:20:34
|
The latest version of OpenGC (cvs on Monday, Sept 22),
contains
ExternalLibraries/freetype-2.1.0.tar.gz
which says that it is version
/usr/local/bin/freetype-config --version
8.0.2
However, FTGL doesn't like that one:
cd FTGL/unix
./configure
checking for FreeType - version >= 9.0.3...
configure: error: FreeType2 is required to compile this library
The latest stable release, freetype-2.1.4.tar.gz, which reports
a version of
/usr/local/bin/freetype-config --version
9.3.3
does seem to work fine.
Wendell
|
|
From: <rra...@ro...> - 2003-09-22 16:03:50
|
I recently wrote an application that FSUIPC based applications can talk to
that provides an interface to a custom flight simulator. We use it here to
talk to Project Magenta. It has an IP-based interface (sort of like
WideFS) for getting and putting data to the memory segment that MSFS
normally uses. I've been thinking of posting it somewhere, but am not sure
where the best place would be. It works fine with the free version of
FSUIPC (pre V3.0).
Robert Ankeney
ope...@li...ur
ceforge.net To: ope...@li...
Sent by: cc:
ope...@li...urce Subject: Opengc-devel digest, Vol 1 #64 - 3 msgs
forge.net
09/21/2003 08:15 PM
Please respond to opengc-devel
>From: Gene Buckle <ge...@de...>
>One thing that would prove to be a big boost to FlightGear's popularity
>would be FSUIPC support. All you'd have to do is set up a shared memory
>segment that Pete could get at with his software, and you'd instantly
>obtain 100% compatibility with all those cool add-ons that the MSFS folks
>enjoy. Even the Project Magenta stuff would work right out of the box for
>the most part.
>
>I wish I could do it myself but I don't have the time - I've got my hands
>full already. :)
|
|
From: Manuel B. <li...@va...> - 2003-09-21 23:25:04
|
On Sun, Sep 21, 2003 at 01:36:40PM -0700, Gene Buckle wrote: > > > Well keep in mind that these guys are hackers at heart and if you can show > > > them a need for other platform drivers they'll be happy to comply. > > > > > I talked with some of them, but doubt if a market of one is going to make > > anyone do somersaults... And the use of FG and open source stuff for > > building cockpits is either not reported or not happening... I suspect the > > latter Well... I do some home cockpit building (and its flightgear exclusivly :) A friend and I were working on a fully enclosed B744 cockpit. But due to space constraints and a few other reasons, we had to cancel that. Now he has built a Piper Cub cockpit (that runs flightgear of course) and I have parts like yoke, rudder pedals and throttle of our old 744 cockpit here at home. > The lack of "amateur" use of FG is most likely due to the high barrier of > entry (you _must_ know what you're doing) and the lack of cockpit oriented > third party infrastructure. > > For instance, there is a LOT of cockpit support software available for > MSFS that's made by Project Magenta. It's pretty high dollar software > too. However, it sells itself because of how easy it is to configure and > hook up to MSFS via network, etc. There are other packages out there that > offer similar features for free as well. OpenGC provides a small subset > as you know. I totally agree with you on the way overpriced Project Magenta. They even want you to purchase two licenses if you want their software for both pilot and copilot (unless you use something like VGA splitting.) > For FlightGear to really take off as a core tool for the home cockpit > builder, it has to be more widely supported by the user community. I agree. However since most development goes on on unix/linux, and most people working on it are of the "unix kind" (which is good :), setting fgfs up on windows, esp. if you want to use CVS, is not that easy for what the average MSFS pilots are used to. > One thing that would prove to be a big boost to FlightGear's popularity > would be FSUIPC support. All you'd have to do is set up a shared memory > segment that Pete could get at with his software, and you'd instantly > obtain 100% compatibility with all those cool add-ons that the MSFS folks > enjoy. Even the Project Magenta stuff would work right out of the box for > the most part. I don't think FSUIPC is necessary. there's enought ways of getting data in and out of fgfs. I don't see why Project Magenta (being expensive $-wise) should "profit" from fgfs (being free). Then there is the "FSUIPC now costs money thing"... I'd rather stay with opensource. When I post in a german home cockpit builders forum that I visit regularly, all my posts have a signature line pointing to flightgear. :-) Regards, Manuel |
|
From: John W. <ca...@mm...> - 2003-09-21 22:37:33
|
> > The lack of "amateur" use of FG is most likely due to the high barrier of > entry (you _must_ know what you're doing) and the lack of cockpit oriented > third party infrastructure. > I like your use of the word "amateur" I was struggling to find the right expression. It's sorta a chicken and egg thing, provide the support and you'll have an audience that will justify the effort to produce the support > For instance, there is a LOT of cockpit support software available for > MSFS that's made by Project Magenta. It's pretty high dollar software > too. However, it sells itself because of how easy it is to configure and > hook up to MSFS via network, etc. There are other packages out there that > offer similar features for free as well. OpenGC provides a small subset > as you know. > I talked over a year ago with the Magenta folks and all it left in my mouth was a bad taste, what an arrogant bunch of SOBs and their stuff is not all THAT great. I've got stuff running derived from OpenGC which is a full 747 flightdeck with a functional FMC and better,as attested to by a few airline pilot types I've worked with. But (here's the catch) since Damion went off on a different direction with the OpenGC project it's become incompatible and I just don't have the time, talent or resources to set up a website and CVS server or try to sync up with X-Plane or FSxxx. It runs under Linux and networks with FG, and is just as easy to set up as FSUIPC and has a lot more potential and will remain free under the GPL license.. > For FlightGear to really take off as a core tool for the home cockpit > builder, it has to be more widely supported by the user community. > So true. the FG crowd is rather an ecclectic bunch (based mostly on the email one sees) and just no way of knowing who else is out there or were their interests lie. ATM the task(s) de jour seems to be building airplane models and cultural features. And it is becoming a little top-heavy. IMHO it needs a got technical thrashing by a couple of heavy-duty gearheads to improve performance and supportability. I think one of the big barriers is Linux itself. While the installation and support has improved dramatically over the past few years it still takes a little work to get it installed and running when things don't go as expected. Again MS has a lock on windows and can dictate how things work, so installation can be guaranteed while Linux has to be a little more "democratic" (small d, no reference to politics) and that can lead to a few mis-steps on occasion. Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-21 20:25:42
|
> > Well keep in mind that these guys are hackers at heart and if you can show > > them a need for other platform drivers they'll be happy to comply. > > > I talked with some of them, but doubt if a market of one is going to make > anyone do somersaults... And the use of FG and open source stuff for > building cockpits is either not reported or not happening... I suspect the > latter The lack of "amateur" use of FG is most likely due to the high barrier of entry (you _must_ know what you're doing) and the lack of cockpit oriented third party infrastructure. For instance, there is a LOT of cockpit support software available for MSFS that's made by Project Magenta. It's pretty high dollar software too. However, it sells itself because of how easy it is to configure and hook up to MSFS via network, etc. There are other packages out there that offer similar features for free as well. OpenGC provides a small subset as you know. For FlightGear to really take off as a core tool for the home cockpit builder, it has to be more widely supported by the user community. One thing that would prove to be a big boost to FlightGear's popularity would be FSUIPC support. All you'd have to do is set up a shared memory segment that Pete could get at with his software, and you'd instantly obtain 100% compatibility with all those cool add-ons that the MSFS folks enjoy. Even the Project Magenta stuff would work right out of the box for the most part. I wish I could do it myself but I don't have the time - I've got my hands full already. :) g. |
|
From: John W. <ca...@mm...> - 2003-09-21 00:10:44
|
> > Well keep in mind that these guys are hackers at heart and if you can show > them a need for other platform drivers they'll be happy to comply. > I talked with some of them, but doubt if a market of one is going to make anyone do somersaults... And the use of FG and open source stuff for building cockpits is either not reported or not happening... I suspect the latter Regards John W. |
|
From: Gene B. <ge...@de...> - 2003-09-20 18:23:49
|
> cross-platform compliant, and it's not always easy or fun... > Nothing worth doing ever is. I keep telling myself this every time I cut my hand or bust a knuckle working on the F-15. :0 > application layer. And peek and poke just don't cut it. > You keep referring to "peeking and pokeing". What are you referring to? No simulator that I've ever seen would use such a method. The closest I've seen is Falcon 4 using shared memory segments to expose a small data set to drive a master caution panel and some basic instruments. > But from what I've seen, the market is for hardware and interfaces to work > with and in the windows environment so one either goes with the flow, sets > their own course, or does without. > Well keep in mind that these guys are hackers at heart and if you can show them a need for other platform drivers they'll be happy to comply. > Enjoyed the stories and pics on your website. These projects have a way of > consuming us, don't they? ;-) Thanks. Yeah, it gets out of hand now and again. :) g. |
1 message has been excluded from this view by a project administrator.
