[Flightgear-devel] ATC client
I've seen that there are plans to develop an ATC client for Flightgear. I'm very interested in this profect, and so I'm offering my help. Whoever is involved, please get in touch. Cheers. Pep. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC client
El 29/11/10 20:44, Martin Spott escribió: Pep Ribal wrote: I've seen that there are plans to develop an ATC client for Flightgear. I'm very interested in this profect, and so I'm offering my help. Whoever is involved, please get in touch. http://wiki.flightgear.org/index.php/FlightGear_Newsletter_October_2010#OpenRadar Cheers, Martin. I would gladly mantain, or port to C++. But who can I contact? There's no contact information available in the websites. Regards. Pep. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
..shouldn't this warrant say a NOTAM to make these old versions, realistically current? ;o) Terrain data is not only a question of updates, but a question of makes. There are a lot of airports to download, and every one sticks to the one of their preference. There shouldn't be much problem as they are all based in real life AD's, but some of them have more level of detail, some lack taxiways, etc. ..in RL, there's also un-controlled and even no-radio GA, Ultra light, etc VFR traffic in the appropriate air spaces, and sometimes outside these. (Or is all that gone in this genocidal post-9/11 era???) Yes, in IVAO too, you can fly uncontrolled. ..why? You could consider FG airshows or fly-ins or even insurgency ;o) and e.g. issue NOTAM's to deal with this RL-like problem. ;o) There's a Special Operations Department, an there are events as I said, which if they agree to IVAO rules and regulations, it's perfectly viable. See the RR here: http://www.ivao.aero/rulregs/ ..you fly FG in IVAO using Wintendo??? How do these communicate? It would be nice to fly FG in IVAO (this is the whole point of this conversation), whatever platform. I personally prefer Linux, but as FG is multiplatform, then IVAO would turn multiplatform... ..maybe you write your [EMAIL PROTECTED] plug-in at home as an hobby like we do? ;o) Here to Help, even by flogging you into a new career, running the [EMAIL PROTECTED] server. ;o) Even then I would need IVAO's permission to log in their servers. Anyway, let's see what's IVAO official answer, as I've already passed them the proposal. We'll know what's their best approach, and so we'll see if both approach match. Cheers. Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Hi all, ..ok, so you have no way of assuring people see the same things at IVAO. Right, though differences are scarce in practice. But even in real life, you have no way of assuring others see colors the same way you do (just kiddin ;o) ). ..you fly FG in IVAO using Wintendo??? How do these communicate? It would be nice to fly FG in IVAO (this is the whole point of this conversation), whatever platform. I personally prefer Linux, but as FG is multiplatform, then IVAO would turn multiplatform... ..yeah, but never mind my surprise, the important question on my line above, was: How do these communicate? I think I'm missing something from your question. How do who communicate? FG and IVAO? But those you don't see on the list, but who are online on the MP servers on a near-constant basis, are the kids (of variable age range, no doubt) whose idea of social flying is EMERGENCY LANDING EVERYBODY CLEAR THE RUNWAY@@@ or CAN SOMEONE TELL ME HOW TO FLY?? and/or those that just loop around aimlessly seeking attention or try to pull off something cool flying a 787 like it were in an aerobatic display. Given the former, I agree that this presents no problem working with IVAO. How do we screen for the latter? Again I say that there would have to be two FG-MP networks; one connected with IVAO and one that isn't. Or, close FG-MP to only those who register for IVAO and plan to follow its guidelines, leaving the kids to play solo, or else privately set up their own FG-MP servers. I completely agree with that. That's why I kept insisting that no one should loose their freedom to play in the way more fun for each one. Someone will prefer messig around, looping, crashing, hitting, aerobatics, etc. Some other will have more fun executing a full flight, with its takeoff, departure, enroute, approach, goaround, diverting, holding or landing procedures, using charts, in a way exactly identical to reality. And someone could prefer both things, depending on the day. Then, two (or more actually) separate networks is best. You don't need to change your flying meetings; moreover: you shouldn't do it for the sake of joining another network. And IVAO would accept FG simmers that enjoyed real life procedures without changing its principles. I don't even think joining networks is philosophically possible. Best, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
If you are asking how flight simulators in general communicate with IVAO, there are client applications that do this: IvAp (for MSFS), Squawkbox (for MSFS, Fly!), X-IvAp (for X-Plane), etc. It has to be that way because of these simulators not being open source. ..nor GPL. My understanding is this should happen server side, or you're tangling with allowed and not work-arounds under the GPL, and you will be distributing or conveying client apps under some license. We all want firm walls around our copyrights here. ..ok, I would want IVAO's Executive Commitee explaining this part of their policy, as it stands now in http://www.ivao.aero/rulregs/va-r-r.asp, §2: ... IVAO will not be responsible of copyright violations., it makes no such database limitation to IVAO's statement, which is really a claim in a pre-emptive litigation defense. ..this language rather suggest IVAO wants to not be held responsible for its potential use of pirated code. Your Executive Commitee will probably want to clarify this language to demonstrate it's respect for Copyright Law. The IVAO software development department is responsible for the development and maintenance of such applications, which are distributed according to a freeware IVAO license. No pirated code is used and no license infringements commited. These applications include pilot clients, Air Traffic Control clients and other network utilities. Note the URL you are pointing out is the VA rules and regulations; nothing to do with software, just about Virtual Airlines data. The VA's around IVAO submit their information to IVAO VA database. This includes logo of the corresponding airline, which sometimes corresponds to that of the real Airline. IVAO cannot know if that submitter possesses the permission to use that logo. The submitter, usually has a VA website. This website URL is submitted as well to IVAO VA database. IVAO database just links to that VA. The information uploaded is not responsibility of IVAO. This is the meaning of the statement. Beyond the scope of VA it doesn't apply. However, if you think this needs further explanation, or rephrasing, you can contact the database administrator: [EMAIL PROTECTED] Cheers, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
..you fly FG in IVAO using Wintendo??? How do these communicate? It would be nice to fly FG in IVAO (this is the whole point of this conversation), whatever platform. I personally prefer Linux, but as FG is multiplatform, then IVAO would turn multiplatform... ..yeah, but never mind my surprise, the important question on my line above, was: How do these communicate? I think I'm missing something from your question. How do who communicate? FG and IVAO? ..yup, the programs, they must communicate somehow. Your wrote your own code to do this? I don't fly FG in IVAO. No one does. If I did, I wouldn't have started all this :) If you are asking how flight simulators in general communicate with IVAO, there are client applications that do this: IvAp (for MSFS), Squawkbox (for MSFS, Fly!), X-IvAp (for X-Plane), etc. It has to be that way because of these simulators not being open source. ..some aren't, agreed, and some combinations _are_ possible, but let's first have IVAO weed out it's litigation traps, e.g. this gem, the last line of §2 in http://www.ivao.aero/rulregs/va-r-r.asp , doesn't quite fly with me, obviously IVAO and its Executive Commitee _is_ subject to copyright law and the GPL, if they do anything mentioned in either of these. This refers only to Virtual Airline registration. However, I'm not law expert, cannot add anything else to this respect; perhaps the database administrator could explain it. Best, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
I don't think the MP servers have to change their philosophy. I don't think both networks should be merged: it would be better to have the possibility to choose. All this is a personal opinion, but I think your MP should remain intact, with the same philosophy, and just add into IVAO the ability to accept FG connections. You can't lose your identity, you should just gain the possibility to connect your simulator to the network of your choice based on which philosophy best suits you. Regards, Pep. - Original Message - From: Rob Shearman, Jr. To: FlightGear developers discussions Sent: Tuesday, November 11, 2008 9:19 PM Subject: Re: [Flightgear-devel] FlightGear in IVAO network I know I am usually just a lurker on this list, and when I do poke my head in, it doesn't always make sense :) However there is one concern I have about IVAO/FG-MP interoperability which I have not seen addressed, and it goes back to a debate about MP we've had in our forum several times over now. The goal of IVAO is to provide a virtual air-traffic environment with a high degree of realism. But I don't agree that FG-MP shares that goal. It seems that a large number (often, the majority) of FG-MP users are on the network to mess around and socialize rather than participate in a multi-aircraft scenario with any degree of realism. Are we then going to revert to our idea of having separate MP networks for serious versus social sim-flying? Or are we to restrict access to our MP network only to those who desire realistic interaction? This may be a can of worms, but it's one that I would at least feel comfortable knowing had already been digested before we bog ourselves down with the technical details... Cheers, -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as [EMAIL PROTECTED] From: Matthew Tippett [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Sent: Tuesday, November 11, 2008 7:34:12 AM Subject: Re: [Flightgear-devel] FlightGear in IVAO network Note the subtle suggestion of the discussion here. To avoid exposing/causing concern with the GPL, keeping it completely internal and not distributing it from IVAO seems like a good idea. However, this appears to need FG to expand/revise it's MP interface to allow secure connection of external MP-FS networks. This in effect opens the FG to have other networks (that talk FG-MP) to connect. Note that in this model, IVAO would bridge it's network into FG-MP, and not the other way around. This distinction is critical for the following reason... Assuming a secure connection (public key), we have the following trusts. 1) FG will allow IVAO MP information when a IVAO network connector joins the FG-MP network. 2) By connecting, the IVAO network agrees to receive FG MP information. 3) The public key of the IVAO network is trusted by FG-MP. 4) The FG-MP network has the trust 'power' to deny IVAO if there are any problems by removing the trust of the public key. Note that the primary factor in this FG-MP is master, IVAO is slave is driven by the closed protocols on the IVAO network. It makes a lot more sense for IVAO to create a connector that talks FG-MP, than the FG jump through a larger (and to some a lot less palletable) set of hoops to have FG-MP create a connector to connect as a slave to the IVAO network. (The Master/Slave term sounds wrong and would most likely cause IVAO issues. Truster/trustee sounds more peerish, but doesn't sound architecturally right either. I suggest the two groups settle on terminology ASAP to ensure a common frame of mind.) Regards... Matthew On 11/11/08, Arnt Karlsen [EMAIL PROTECTED] wrote: On Tue, 11 Nov 2008 09:31:34 +0300, Pep wrote in message [EMAIL PROTECTED]: The way IVAO has worked so far, as Curt says, is completely plugin based, in regard of flight simulators, due to the fact that the simulators that log in are not open source (let's change that!). In the case of FG, where FG itself is open source, and the MP server is too, there are two approaches, as Matthew pointed out: One would be FlightGear acting as a IVAO client and connecting directly to IVAO FSD servers. Honestly it was my first though. However, that would be a bit difficult both for FG and IVAO. The other approach, bridging both networks seems to me now better. However, I leave it to you guys to decide which of the two you prefer, though I assume you go for the second one. In case of the second one, we at IVAO could set up a MP server (or more), connected itself to the IVAO FSD servers. ..and if you modify your MP server, and, _keep_ it _in-house_, you are not distributing etc it and therefore you not violating any GPL or any copyrights. I believe this is a valid work-around. And here, as Martin says, starts the religious war. ..nope, it is no longer necessary. ;o) As I
Re: [Flightgear-devel] FlightGear in IVAO network
Hi all. Another big issue I was thinking about is how we would deal with our differences in terrain data? Maybey we should keep the technicall problems for a later stage, but having planes taxi meters above (or below) you just doesn't look good... As far as I know FG uses the same geographic mode than IVAO network. Good thing is they both are based in real world, so theoretically there shouldn't be much problem. Regarding terrain differences, that's something usual sometimes in IVAO itself, where users have sometimes different versions of an airport, for instance. It's common to hear a controller asking what airport version have you got, sir?, and this is perfectly understood by the controller or other users. Joining IVAO is a great oppurtinity for FlightGear. But I agree with most senior developers that we should think out everything very well before we do something. It's easier to call something off than to revert it. There actually are a few simulators living together in IVAO (MSFS, X-Plane and Fly!), and there seems not to incompatible. The IVAO team could implement a FlightGear compatible interface into their network. The work would be done on their servers, but then nothing would need to change on the FlightGear side. The IVAO team would not need to expose their proprietary communication protocols, but instead would create an implementaion of our open protocols at their side to accept FlightGear connections. They could create their own proprietary interface to our protocol as long as they don't grab any of our code to do so (or maybe the I thought that if we at IVAO don't distribute the GPL software then we can use it, modify it and keep it private in our network? Wasn't it stated before by Arnt? Anyway, a few changes should be made in FG MP protocol, as IVAO needs authentication information, but also full Flight Plan, for instance. And regarding the joining of the networks instead of adding FG possibility into IVAO servers, if we proceed merging networks, your network will have to comply with IVAO rules and regulations automatically, and I don't think that's fair for you. I think freedom of choice is necessary for pilots that have fun in different ways. IVAO should be just adapting itself to FG MP protocol specification changes, though IVAO would be making requests about changes so that it fits the needs. ..any news, Pep? You doing it all in-house with no distribution, means no copyright or license policy mess, which again means you can have things decided at brass levels closer to yourself. ;o) Well, even if I think it makes a lot of sense, I can not decide by myself and go for it... IVAO is burocratic in this respect. I have already proposed this solution. Let's see what it comes out, but as I've said before there's a big interest in the software development department to see the FG simulator onboard. ..my impression from what little I've seen here on this list, (I haven't had time to join the fun), is our social MP things are MP airshows and fly-ins, in the http://eaa.org/ and http://airventure.org/ style spirit. ..these events fits nicely into RL air traffic in RL and I see no problems with IVAO's serious relism traffic servers joining our MP servers, and maybe you could write a NOTAM generator plugin or something, so these serious IVAO etc people are properly notified about FG's MP fly-in and airshow activity like in RL? ;o) C'mon, we are not that serious and boring people!! :o))) Perhaps something you might note is that even if IVAO is quite Real-Life, the main aim is FUN. No need to say that hitting other planes, etc. is forbidden in IVAO, but that's because someone in Real Life decided to forbid it!! ;o)) I agree it takes a bit more to become confident flyer in IVAO, but if the events are planned and executed in a more or less RL style they are perfectly legal in IVAO: airshows, formation flights, military flights, races, serch and rescues, humanitarian flights, chopper contests, etc. Every division (country) sets up events, followed by many many pilots, which make IVAO events something really funny. Can you describe the value-add that FG gives that would be used for ROI assessment for IVAO? If you are asking what has FG to offer to the IVAO network, I'd say A LOT. In the first place, IVAO community increases, as more users can join the fun (ok, call it serious fun ;o)). In second place, there are IVAO users that have stated their interest in FG due to the fact that they stick to Microsoft Windows because of IVAO: they wish to have the possibility to fly online in IVAO using exclusively Linux (though X-Plane is also present, but it's not free). Personally, I think this is a strong reason. Actually I'm personally putting my efforts in this because I use FG, and I've been a lot of time flying offline (I quitted MSFS time ago). Please help me go back to online flying ;o) The other way round applies: many IVAO users that might not know FG
Re: [Flightgear-devel] FlightGear in IVAO network
The way authentication is handled so far in IVAO ATC (IvAc) and pilot (IvAp) clients is a connection popup window that lets you fill VID and password, which you can retype every time you login, or check for remember me. Unfortunately I don't know much more of the internals of the software, but if you need more detail, I can hand a list of questions to Softdev directors before proceeding with the discussion. Alternatively I can hand you a copy of the manuals (IvAc and IvAp) so that you have an idea of what we are talking about. Anyway, I need to know where I can send these manuals (3+ Mb) if you are interested. Cheers. 2008/11/10, Martin Spott [EMAIL PROTECTED]: Please forgive me all these early-morning-no-tea typos Martin Spott wrote: [...] authentication) ? How does the user experience the login procedure when he prepares for a flight if INL would be the means or transport ? ^^ of If you/we aim at convincing IVAO stuff to allow for the use of ^ staff Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
2008/11/10, Martin Spott [EMAIL PROTECTED]: You/they should probably start by explaining to FG developers/users which sort of security - what an elastic term ! - is meant to be achieved by not publishing the network protocol. In other words: The simple fact that there's no officially blessed copy of the network protocol spec floating around actually doesn't buy IVAO not even the slightest security at all. If somone really aims at messing with the IVAO air traffic then they're simply going to grab an inofficial copy of such spec or do the reverse engineering themselves. This might be a point which I think deserves to get addressed. I agree that concealing the protocol specs doesn't avoid the possible hacks, but just makes it harder or postpones them. I assume they just want to make it harder, as there are thousands of IVAO active users, and we can assume there will always be a small fraction of users that will want to acces the system via unauthorised means or for bad purposes. Finally, if the sort of IVAO's security needs become apparent, then you/we have a hook that allows to start arguing from there. One item which certainly has still to be resolved is the fact that FlightGear's MP protocol currently doesn't provide robust authentication mechanisms and without knowing about the actual security requirements it would be quite difficult to properly add the required feature. BTW, how would the practical process of authenticating the user be done with the INL. Does INL authenticate against the servers using some sort of authentication token which resides on the disk and which has to placed there by the user after signing up with IVAO ? Yes, that is a crucial need: every IVAO user, regardless of what flight simulator or ATC client is using, has a personal ID number and password. Once logged in the network using them, all communication are based on this VID/password connection: pilot position, weather, flight plan, transponder, etc. (so far, voice is addressed using Temspeak, a separate application, so no need to worry about that by now). So to summarize, te important thing is authentication and data exchange control, to avoid for example an software sending FP's continuously or constant weather requests to overcharge communication lines and servers. Regards, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
The way IVAO has worked so far, as Curt says, is completely plugin based, in regard of flight simulators, due to the fact that the simulators that log in are not open source (let's change that!). In the case of FG, where FG itself is open source, and the MP server is too, there are two approaches, as Matthew pointed out: One would be FlightGear acting as a IVAO client and connecting directly to IVAO FSD servers. Honestly it was my first though. However, that would be a bit difficult both for FG and IVAO. The other approach, bridging both networks seems to me now better. However, I leave it to you guys to decide which of the two you prefer, though I assume you go for the second one. In case of the second one, we at IVAO could set up a MP server (or more), connected itself to the IVAO FSD servers. And here, as Martin says, starts the religious war. As I understand, a server-server protocol should be implemented. The authentication stuff, moreover, perhaps will demand a few changes to MP? Once we start agreeing, there will be more things like these to address, I assume. If you confirm this is the way you wish to proceed, please tell me. I'll report to my IVAO bosses and see what they decide. Cheers! - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FlightGear in IVAO network
Hi all, my name is Pep Ribal. I belong to the Software Development department of the IVAO network. Some of you might remember me, as I was involved in a project regarding IVAO-FlightGear interconnection time ago. That specific project was discontinued, but we at IVAO have not forgotten about the idea of making FlightGear drop in the network in a future. We think this is a good moment to give it a serious try, though changing the approach, i.e., not via a separate application. It would be really positive either for the FG community as well as for the IVAO community. FG would benefit from the real life human controllers, as well as the big amount of virtual pilots available at the same time, sharing a common airspace between pilots running either FG or other simulators. And IVAO would become the first flight sim network that would accept FlightGear simmers, which in our opinion would be a huge plus for the network. I'd like to ask you developers what do you think it would be the best way to proceed, and what help could we expect from you. The situation is as follows: We are not willing to publish our server protocol. That means that a possible module for connecting FG to the servers shouldn't be open source. We have developed a shared library called the INL (IVAO Network Library), freely available at no charge (IVAO freeware), but not open source, that would encapsulate all accesses to our servers. A potential FG module for connecting to the IVAO servers should link and use this library. What I would like is to know what do you think it can be done technically, what license problems could arise, and see if there's any of you willing to help in the possible development of such a software module. Once I had a clear idea of the best way to proceed, I would hand the project to IVAO for approval. We would provide you developers with the INL binaries, and all necessary documentation and other files. Any suggestion is really welcome. Hope something can be done. Thanks to all. Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear in IVAO network
Thanks for your comments and suggestions. In the first place, I need to tell you that personally, I'm a free software guy, and I agree that the best possible solution is always the GPL license. But this is personal. BTW, you can find information about IVAO at www.ivao.aero, for those that asked. The reason why I wanted to start a discussion about this was to achieve a project proposal or roadmap that we can hand to IVAO Softdev directors for approval. I know their preference is to use the INL library, that's why I suggested this. What I really want is the IVAO approval, and with the use of the INL I think that was guaranteed. But I'm not a salesman; my only interest is just get FG and IVAO join, whatever means that please all. So, as the INL library poses a few important problems, and I see your preference (and my personal one as well) is to go for an open solution, I think we should work on this idea. The thing is, whatever solution is finally pointed out, I'd like to hand them a document about this best solution, well reasoned and clearly explained, so that it helps convince not only software development directors, but the board of governors as well. So yes, the solution that some of you have pointed out of opening a different gateway inside IVAO servers for FG users, had crossed my mind as well time ago. But I need a bunch of arguments and explanations to convince the rest of IVAO that this is the best solution possible. I know Softdev directors are really interested in getting FG join the network, so if we can hand a good explanation there shouldn't be any problem (I'm always optimistic). Regarding why IVAO keeps their protocols closed being a free community, what I've been always answered is that's for security reasons. So explaining them that the mentioned open gateway for FG wouldn't be a security issue is crucial. Developing it in a way that takes security into consideration would be important. I need to tell them how security issues will be addressed. I think the best way to proceed, after reading your posts, is to focus on this solution: a different (open) protocol for FlightGear inside IVAO servers. So what I'd ask you is a set of reasons why we should go for this solution and forget the INL: techical reasons (security-related above all), license reasons, etc. Please help me prepare an interesting proposal. I'm aware the worst hurdle to overcome will be this agreement between two communities with different points of view, but if we could address this specific issue successfully, I'm sure the outcome would be very interesting for the community in general. I'll be waiting for your answers. Best regards, Pep. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Communicating with IVAO client
I'm developing a client application for the IVAO network. John Wojnaroski sent me some time ago a few files to be added/changed in Flightgear source code so that FG sends UDP packets to my application. I've done some changes to these files as well. Now I've changed to Fedora 8, and I've made a complete rebuild of Flightgear. With the modifiations made with John, FG results in having an option namely --ivao. With this new build I experience a small problem: as it works perfectly well with the --ivao option, sending the right packets, when it comes to shutdown FG, an error dump appears in my terminal window. However, if I run FG without the --ivao option, no error is produced. I assume I've made some mistake, as I'm not familiar with FG architecture. What I've done exactly is to download the latest stable source code (0.9.11), and added/edited these few files before compiling, wich I'm attaching in this mail. I've attached as well the terminal command-line used and the resulting messages. If someone could take a look and see if it's a problem in the files, it would really help. Thanks a lot. Pep Ribal. FG-IVAO files.tar.gz Description: GNU Zip compressed data [EMAIL PROTECTED] ~]$ fgfs --airport=BIVM --ivao=socket,out,10,192.168.1.3,6000,udp Model Author: Unknown Creation Date: 2002-01-01 Version: $Id: c172p.xml,v 1.18 2007-01-15 12:50:45 ehofman Exp $ Description: Cessna C-172 Initializing Nasal Electrical System power up *** glibc detected *** fgfs: corrupted double-linked list: 0x08db5b70 *** === Backtrace: = /lib/libc.so.6[0xa92d5d] /lib/libc.so.6[0xa947fb] /lib/libc.so.6(cfree+0x90)[0xa980f0] /usr/lib/libGL.so.1[0x724469a] === Memory map: 00101000-00105000 r-xp 08:05 3489157/usr/lib/libXxf86vm.so.1.0.0 00105000-00106000 rwxp 3000 08:05 3489157/usr/lib/libXxf86vm.so.1.0.0 0011-00111000 r-xp 0011 00:00 0 [vdso] 00111000-0012c000 r-xp 08:05 3480043/usr/lib/libplibpuaux.so.1.8.4 0012c000-0012d000 rwxp 0001b000 08:05 3480043/usr/lib/libplibpuaux.so.1.8.4 0012d000-00158000 r-xp 08:05 3479954/usr/lib/libplibpu.so.1.8.4 00158000-0015a000 rwxp 0002b000 08:05 3479954/usr/lib/libplibpu.so.1.8.4 0015a000-00167000 r-xp 08:05 3479923/usr/lib/libplibfnt.so.1.8.4 00167000-00169000 rwxp d000 08:05 3479923/usr/lib/libplibfnt.so.1.8.4 00169000-0016a000 rwxp 00169000 00:00 0 0016a000-0016c000 r-xp 08:05 3479926/usr/lib/libplibjs.so.1.8.4 0016c000-0016d000 rwxp 1000 08:05 3479926/usr/lib/libplibjs.so.1.8.4 0016d000-00174000 r-xp 08:05 3479927/usr/lib/libplibnet.so.1.8.4 00174000-00175000 rwxp 7000 08:05 3479927/usr/lib/libplibnet.so.1.8.4 00175000-0019e000 r-xp 08:05 3480175/usr/lib/libplibssgaux.so.1.8.4 0019e000-001a8000 rwxp 00029000 08:05 3480175/usr/lib/libplibssgaux.so.1.8.4 001a8000-00244000 r-xp 08:05 3480142/usr/lib/libplibssg.so.1.8.4 00244000-00249000 rwxp 0009c000 08:05 3480142/usr/lib/libplibssg.so.1.8.4 00249000-00506000 rwxp 00249000 00:00 0 00506000-00517000 r-xp 08:05 3480048/usr/lib/libplibsg.so.1.8.4 00517000-00518000 rwxp 0001 08:05 3480048/usr/lib/libplibsg.so.1.8.4 00518000-0051c000 r-xp 08:05 3480180/usr/lib/libplibul.so.1.8.4 0051c000-0051d000 rwxp 3000 08:05 3480180/usr/lib/libplibul.so.1.8.4 0051d000-0054d000 r-xp 08:05 3479843/usr/lib/libglut.so.3.8.0 0054d000-00552000 rwxp 0002f000 08:05 3479843/usr/lib/libglut.so.3.8.0 00552000-00557000 r-xp 08:05 3479710/usr/lib/libalut.so.0.1.0 00557000-0055a000 rwxp 4000 08:05 3479710/usr/lib/libalut.so.0.1.0 0055a000-00595000 r-xp 08:05 3474997/usr/lib/libopenal.so.0.0.0 00595000-00596000 rwxp 0003b000 08:05 3474997/usr/lib/libopenal.so.0.0.0 00596000-0059a000 rwxp 00596000 00:00 0 0059a000-0059b000 r-xp 08:05 3481986/usr/lib/libxcb-xlib.so.0.0.0 0059b000-0059c000 rwxp 08:05 3481986/usr/lib/libxcb-xlib.so.0.0.0 0059c000-005b7000 r-xp 08:05 3481996/usr/lib/libxcb.so.1.0.0 005b7000-005b8000 rwxp 0001a000 08:05 3481996/usr/lib/libxcb.so.1.0.0 005b8000-005ba000 rwxp 00:10 197/dev/zero 0082a000-00898000 r-xp 08:05 3480095/usr/lib/libSDL-1.2.so.0.11.1 00898000-0089a000 rwxp 0006e000 08:05 3480095/usr/lib/libSDL-1.2.so.0.11.1 0089a000-008c5000 rwxp 0089a000 00:00 0 008ea000-0093e000 r-xp 08:05 3488432/usr/lib/libXt.so.6.0.0 0093e000-00942000 rwxp 00054000 08:05 3488432/usr/lib/libXt.so.6.0.0 00944000-0095a000 r-xp 08:05 3488580/usr/lib/libXmu.so.6.2.0 0095a000-0095b000 rwxp 00016000 08:05 3488580/usr/lib/libXmu.so.6.2.0 00a08000-00a23000 r-xp 08:05 1049560/lib/ld-2.7.so 00a23000-00a24000 r-xp 0001a000 08:05 1049560/lib/ld-2.7.so 00a24000-00a25000 rwxp 0001b000 08:05 1049560/lib/ld-2.7.so 00a27000
Re: [Flightgear-devel] Communicating with IVAO client
Roy Vegard Ovesen escribió: I'm getting a very similar error when I exit fgfs: *** glibc detected *** build_sdl/src/Main/fgfs: corrupted double-linked list: 0x00d4bcb0 *** === Backtrace: = /lib/libc.so.6[0x2ae1dcd46067] /lib/libc.so.6[0x2ae1dcd47921] /lib/libc.so.6(cfree+0x8c)[0x2ae1dcd4b6fc] /usr/local/lib64/libosg.so.25(_ZN3osg8StateSetD0Ev+0x2d9)[0x2ae1d9efb0f9] build_sdl/src/Main/fgfs[0x4e71d3] build_sdl/src/Main/fgfs[0x4e7261] ... ... And this is with the CVS version. I assume I've made some mistake, as I'm not familiar with FG architecture. What I've done exactly is to download the latest stable source code (0.9.11), and added/edited these few files before compiling, wich I'm attaching in this mail. I've attached as well the terminal command-line used and the resulting messages. You seem to be contradicting yourself here as I believe the latest stable, or release, is 0.9.10. Perhaps you mean the 0.9.11-pre1 version. In any case I get a similar error and I of course do not have your IVAO code, so it might not be your fault after all. Yes, sorry, I just poured the word stable without much thinking. I really ment the 0.9.11-pre1. Thanks for your reply. Now I know I don't have to worry too much about my files. Best, Pep. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG coordinates
Hi, I need to know: what coordinate system is Flightgear using actually? Is it by any chance the worldwide air navigation standard of WGS84 coordinates? Thx. Pep Ribal. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] IVAO module in Flightgear
Hi, it's been a while since I posted in this list asking for some help with the development of a client application to connect Flightgear to IVAO servers. Since then some important steps have been taken. One of them has been the trust and support to the project shown by the board of governors of the IVAO network. Thus, I've been given a position in the IVAO software development staff, so that they will give all support to the project (including their SVN server). Additionally I've been given a copy of their shared library that encapsulates everything related to connection to their servers, along with includes and documentation. Though the ivao library is not open source, it will be distributed as freeware. However the client application I'm developing will be GPL. Since my first post I got the support of Flightgear developer John Wojnaroski, who has helped me a lot, specially in communications stuff. He has developed an additional module in Flightgear that enables communication with my IVAO client, via the command-line option --ivao=parms (I think it's not in the CVS). So far, the client has been successful in logging in IVAO test server, and sending airplane position updated. However, the hardest part is to be developed. As soon as the IVAO client sends back other packets to Flightgear, all this stuff will have to be processed inside the simulator: weather conditions, other pilots' positions, etc. The way I've thought it, I'd rather go myself for all the aspects of the IVAO client development, and leave the Flightgear tuning to a volunteer team of Flightgear developers, so that I can focus on the client. I think you guys will do a better job than me here, as I am not familiar with the Flightgear architecture. John has agreed to take the communications part between Flightgear and my client, but it would be really appreciated if some of you wanted to go for the development of the IVAO packets processing. If someone is interested in joining the project just let me know. Thanks a lot, Pep. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Connecting to FG
Hi all, I'm trying to make a simple application that just retrieves the FG status via the property tree. What I've done: I've started FG with the option --props=5400; I've startet a successful telnet session in the same host, and everything works fine. But I can't manage to make an app that does this connection. I create a socket. Then, the 'connect' call works fine. Then I use a 'write' call to send the string ls to FG. I've tried help and ls\n as well. They both work fine. But then I call 'read' (to see the help/ls results), and nothing is actually read: the program just blocks there without continuing execution. So I assume everything is working fine, except that I'm not using the protocol properly to retrieve information. I suppose FG is not giving information because I don't know how to ask him. What am I doing wrong? There is a second problem, related to my lack of knowledge of Linux server configuration: When I try to telnet FG from a foreign computer of the LAN, it just keeps saying Trying 192.168.1.3..., so I think I need to configure the computer where FG is running so that it accepts the telnet request. How can I do it? I'm running Fedora 6. Thanks. Pep. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG IVAO client
Hi all, as I told you some days ago, I'm about to start a project with the IVAO guys to develop a client software for FlightGear. However, as I'm new at the Linux programming environment, I'm trying to decide how should the GUI of the application be done. The application should be rather simple: just a rectangular bitmap with buttons, and a text entry box. I'm attaching a sample of the existing Ivap for MSFS look. The thing should be doing some kinda clone for FG and make it look similar to the picture. Apart from this main interface, there will be some regular forms with text fields and buttons, for entering the flight plan and configuring the application, etc. The application should be easy to show/hide from FG (via hotkeys or whatever), as if it was a popup gauge (no need to attach it into the actual cockpit). The gauge should always sit on top of FG, and hide automatically for instance when FG minimizes, closes, etc. The problem is that I want to start developing the GUI, but honestly I'm a bit lost and overwhelmed. I don't know which toolkit I should use. I've been looking at FLTK and GTK+, but I'm not sure they are the right tools to use. While they would be nice for the standard forms (flightplan and so on), I'm not sure I can use them for the main window (the picture I'm attaching). As I'm in a learning process, I prefer to start learning the right tool, so this is my question: what's your advice? How should I start with the interface? FLTK? GTK+? SDL? OSG? etc.? Sorry for my lack of knowledge :-( Thanks, Pep. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear and IVAO
Hi all, I'll explain what brings me here: I'm a member of the IVAO network (http://www.ivao.aero), which provides a background for flight simmers and virtual controllers. Perhaps many of you already know about what I'm going to explain. Virtual pilots connect to the network either as virtual ATC or virtual pilot. In this last case (pilot), the user needs in the first place, a flight simulation software (Micro$oft Flight $imulator, X-Plane, Fly!,...). In the second place, a connection software that links the simulator to the IVAO network. Usually this client software is displayed as a kinda FMS-like gauge. The IVAO pilot client for M$ FS is called Ivap. A notorious existing client for other simulators is Squawkbox. In the third place, an account in the IVAO network, which is 100% free of charge (IVAO is a free network). Thus, you can use your favourite simulator in an environment with hundreds of other pilots and controllers who are using either other flight simulators (and so other pilot clients) or ATC clients. So far, most of the people who fly online in IVAO is unfortunately using M$ FS. Some of them use X-Plane, Fly! or other simulators. So far there's no possibility to fly in IVAO with a free software simulator like Flightgear, because there's no client software for them. And that's what I intend to fix. I've had a few conversations with the software development team of IVAO and it's very likely that they'll offer me their help and support for the development of a pilot client flor Flightgear. This way, FG users will be able to fly online with thousands of pilots who actually fly other simulators. It's a few months since I moved to the Linux environment. I'm a software developer but I've always developed under (sorry! :( ) the M$ environment. What I'm asking to you is some help regarding communication between Flightgear and the client, which will have to produce an information flow between the simulator and the server, regarding weather, planes position, and so on. An optionally (as this will be my first Linux project) I'll be more than happy if someone offered to be my mentor in these my first steps in the path of the light side of the force. However I'll try not to be a burden: I have been studying a lot these last months and I learn fast. Thanks all! Pep Ribal. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and IVAO
Thanks for the interest, Thiago.
Of course all help is welcome, and I'm sure I can learn from your Linux
experience.
However I must stick to the guidelines of the IVAO staff, as there are
chances that they host the project (not confirmed yet). But there
should be no problem.
The only condition from my part is that it should be free softare (GPL
license).
Cheers.
Pep.
Thiago Drechsel escribi:
Hi Pep.
I've been working with Linux for a long time, but I'm new with FG stuff.
I can't be your "mentor", but I'd like to help you developing this
interface. I think this is an excelent learning oportunity. Can I join
your team?
Thanks.
Thiago Drechsel
On 1/25/07, Pep Ribal [EMAIL PROTECTED]
wrote:
Hi
all,
I'll explain what brings me here: I'm a member of the IVAO network
(http://www.ivao.aero), which
provides a background for flight simmers
and virtual controllers. Perhaps many of you already know about what
I'm
going to explain.
Virtual pilots connect to the network either as virtual ATC or virtual
pilot.
In this last case (pilot), the user needs in the first place, a flight
simulation software (Micro$oft Flight $imulator, X-Plane, Fly!,...).
In the second place, a connection software that links the simulator to
the IVAO network. Usually this client software is displayed as a kinda
FMS-like gauge. The IVAO pilot client for M$ FS is called Ivap. A
notorious existing client for other simulators is Squawkbox.
In the third place, an account in the IVAO network, which is 100% free
of charge (IVAO is a free network).
Thus, you can use your favourite simulator in an environment with
hundreds of other pilots and controllers who are using either other
flight simulators (and so other pilot clients) or ATC clients.
So far, most of the people who fly online in IVAO is unfortunately using
M$ FS. Some of them use X-Plane, Fly! or other simulators. So far
there's no possibility to fly in IVAO with a free software simulator
like Flightgear, because there's no client software for them. And
that's
what I intend to fix.
I've had a few conversations with the software development team of IVAO
and it's very likely that they'll offer me their help and support for
the development of a pilot client flor Flightgear. This way, FG users
will be able to fly online with thousands of pilots who actually fly
other simulators.
It's a few months since I moved to the Linux environment. I'm a software
developer but I've always developed under (sorry! :( ) the M$
environment.
What I'm asking to you is some help regarding communication between
Flightgear and the client, which will have to produce an information
flow between the simulator and the server, regarding weather, planes
position, and so on.
An optionally (as this will be my first Linux project) I'll be more than
happy if someone offered to be my "mentor" in these my first steps in
the path of the light side of the force. However I'll try not to be a
burden: I have been studying a lot these last months and I learn fast.
Thanks all!
Pep Ribal.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys - and earn
cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear and IVAO
Thanks a lot John, be sure I'll start shooting questions really soon. ;) I didn't know about the proprietary protocol of VATSIM being such a problem. Fortunately I've talked to the IVAO dev team, and despite their protocol is private as well, they keep their old protocol which they can make available to me. They have no plans to remove this functionality from the servers, so we really can develop a free software tool that uses this protocol. Thanks once more. Pep. (by the way, I found your 747 project really impressive!! congrats!) John Wojnaroski escribi: Pep Ribal wrote: What I'm asking to you is some help regarding communication between Flightgear and the client, which will have to produce an information flow between the simulator and the server, regarding weather, planes position, and so on. Hi Pep, Over the past few years we've tried to work with the VATSIM folks to develop a similar interface, but the GPL license an their proprietary stuff kept getting in the way. Perhaps with IVAO it might be different At any rate, I've been with FG for several years now and would welcome such an interface. (see the 747 project page on the FG website). Curt and I have taken the sim to several shows -- a real-time, live interface to other players/controllers would have been a show stopper. I'll be glad to help and try to be your mentor, especially in the communications area; so if you have any questions, need some code snippets, fire away with your questions. Regards John W. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
