Re: [Flightgear-devel] FlightGear Tracker crash
On Fri, 21 May 2010, Peter Morgan wrote: a restart is also required after a DNS change of a server, or a new one etc. Is there a way to reset an mpserver remotely? eg reloading config every hour or remote telnet command ? No and yes. :) There is no way built into fgms (and adding one would require thinking about the security implications) but I would guess that most fgms administrators have remote access to the box that runs the server. IIRC fgms can almost but not quite reload the configuration file when receiving a hangup (SIG_HUP) signal. Fixing that and/or adding the function to re-resolve the relay names each day (or so) could be useful. Something related: 06 changed IP address last weekend so servers that haven't been restarted since need to be restarted to relay correctly. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Proposal] Class-based MP aircraft visibility
Hi All, My patch to hide other MP aircraft opens the door to providing a useful function to allow multiple different communities of flyers to use the global FG airspace independantly, without requiring additional sets of MP servers. The main use-case is a group of pilots wishing to practise flying in a ATC-controlled environment (e.g. TGA events) using FGCom. They would like all the aircraft in the area to be on FGCOM, and behave as realistically as possible. Furthermore, they would prefer for new aircraft not to spawn on the runway, even though there are no define parking positions. At present, this relies on going somewhere outside of the default tile, and an element of luck that someone doesn't randomly turn up. Note that this is not really anyones fault - it's just a side-effect of sharing a single virtual world. My proposal is that users may optionally set a class or community they are flying in (say /sim/multiplay/class) that is exposed over MP. Using some Nasal, other users may choose to automatically hide or show aircraft from specific classes. The class itself would be free-form, but I would expect to define some standard classes along with a GUI to allow selection of the user's own class and the visible classes. For example: Default - the default Newbie - for new flyers Student - those training - might be reseting regularly FGCom - those using FGCom - implies they will use realistic radio procedures Dogfight - for those engaged in mock dogfights (ignored by default) Ignore - for those who wish to be ignore (ignored by default) So, in the use-case above, all the aircraft using FGCom under ATC would select a class FGCom, and use a dialog to only display other aircraft in that class. If a new aircraft wanted to take part, they could spawn on the runway (having not set their /sim/multiplay/class), taxi to the parking area, set their class to FGCom, thereby making themselves visible, and contact ATC for taxi instructions. Other pilots just wanting to fly around would be able to see all these aircraft. Other use-cases include 1) A developer testing some aircraft systems that rely on MP, but not wanting to disturb other people. By setting a class of Ignore they would by default be ignored by all other aircraft. 2) A group of pilots wanting to engage in a dog-fight over San Francisco without disturbing other pilots. The obvious downside of this is that it may fragment the user-base. However, if by default everyone is able to see everyone else, I think that risk can be minimized. Thoughts? -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Proposal] Class-based MP aircraft visibility
On Fri, 21 May 2010, Stuart Buchanan wrote: The obvious downside of this is that it may fragment the user-base. However, if by default everyone is able to see everyone else, I think that risk can be minimized. Thoughts? Hi, Sounds like a pretty good idea. One technical comment: Given the current MP protocol and its less than ideal string encoding I'd rather not see yet another (mostly) constant string property being sent in every packet. The maximum packet size is limited after all. I'd suggest an int either with a well defined class assignment or, less reliably, a hash of the class string. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Developers
Peter Morgan wrote: Its is/was bit of a dark how to get commit permission to FG and its seems to be one Curt in control. Can someone explain to process to submitting patches to this new git scenario, or are we to be held in the grey area of hopefulnes as well ? eg I'd like to submit a patch for the 787 that actually makes it boot up! pete -- As always, you can submit your patch on this list, along with a clear description of what problem it is solving and how it solves it. That serves as notification to the original aircraft developer (Josh Wilson in this case) and gives others on the list a chance to see the changes in case Josh is on walk-about. If he doesn't respond and folks on the list agree to patch is cool, I'm sure someone will commit it. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Proposal] Class-based MP aircraft visibility
Csaba Halász wrote: On Fri, May 21, 2010 at 11:26 AM, Stuart Buchanan wrote: My proposal is that users may optionally set a class or community they are flying in (say /sim/multiplay/class) that is exposed over MP. For example: Default - the default Newbie - for new flyers Student - those training - might be reseting regularly FGCom - those using FGCom - implies they will use realistic radio procedures Dogfight - for those engaged in mock dogfights (ignored by default) Ignore - for those who wish to be ignore (ignored by default) While you are at it, it might be a good idea to incorporate some other class too, such as single engine ga, 2 engine jet and so on. Then, even if a client doesn't have the model, it could pick a similar replacement. Your class could simply be preassigned transponder codes (ranges), thus achieving two goals for the price of one (I am thinking of more realistic ATC/IFR). I think the class of aircraft you fly is really orthogonal to the way that you are flying. My aim here is to create broad classes which are largely mutually exclusive, so users only select one, to represent the type of flying they are doing. There is certainly a case for including a aircraft class as a separate property. However, that would better be represented as a per-aircraft property to be exposed over MP, so the receiver could then choose the generic model to use. Of course, such an aircraft-class would also allow us to group aircraft more effectively within a launcher. However, that is really another enhancement :) -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Tracker crash
If we get to for example 50 mpservers, then there's gonna be a lot of admin involved for every change On Fri, May 21, 2010 at 8:34 AM, Anders Gidenstam anders-...@gidenstam.orgwrote: On Fri, 21 May 2010, Peter Morgan wrote: a restart is also required after a DNS change of a server, or a new one etc. Is there a way to reset an mpserver remotely? eg reloading config every hour or remote telnet command ? No and yes. :) There is no way built into fgms (and adding one would require thinking about the security implications) but I would guess that most fgms administrators have remote access to the box that runs the server. IIRC fgms can almost but not quite reload the configuration file when receiving a hangup (SIG_HUP) signal. Fixing that and/or adding the function to re-resolve the relay names each day (or so) could be useful. Something related: 06 changed IP address last weekend so servers that haven't been restarted since need to be restarted to relay correctly. Cheers, Anders -- --- Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Developers
On Fri, May 21, 2010 at 1:19 PM, Reagan Thomas thomas...@gmail.com wrote: Peter Morgan wrote: Its is/was bit of a dark how to get commit permission to FG and its seems to be one Curt in control. Can someone explain to process to submitting patches to this new git scenario, or are we to be held in the grey area of hopefulnes as well ? eg I'd like to submit a patch for the 787 that actually makes it boot up! pete -- As always, you can submit your patch on this list, along with a clear description of what problem it is solving and how it solves it. That serves as notification to the original aircraft developer (Josh Wilson in this case) and gives others on the list a chance to see the changes in case Josh is on walk-about. If he doesn't respond and folks on the list agree to patch is cool, I'm sure someone will commit it. 1) ave tried to contract Josh for a long time but is missing 2) two patches have already been submitted to this list and NONE have been appliced 3) Developers do not want to mess with an aircraft designers repos.. 4) Catch 22 Imho we might as well remove 787 from the Repos, its broken, unmaintained, and just taking up space, as well as frustrating other users who might want to try. pete -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Developers
Peter Morgan wrote: 2) two patches have already been submitted to this list and NONE have been appliced As far as my memory serves (I might be wrong and I'm currently not in a position to check) someone's been posting plausible objections against at least one patch for the B787 which (the objections) had never been adressed. Therefore the patch has not been applied so far. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Developers
Martin Spott wrote: As far as my memory serves (I might be wrong and I'm currently not in a position to check) someone's been posting plausible objections against at least one patch for the B787 which (the objections) had never been adressed. Yup, here's the respective posting: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg25828.html As far as I understand this means: The patch doesn't contain the proper fix. Therefore I've refrained from committing to CVS (now: GIT). Looks like the patch needs a patch ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] Selectively ignore other MP aircraft
Stuart Buchanan wrote: Alexander Barrett wrote: Excellent idea and one I think many will appreciate. I haven't had time to look at it yet so please excuse the question if its obvious from within the code: Does this reset with every MP session, or is it easy to clear the list either selectively or in its entirety? At present, it will reset when you restart FG or if the MP aircraft disappears and then re-appears. However, on my machine I've integrate it with the Ignore checkbox on the MP pilot list. Once I've checked in those changes, it will be indirectly tied to MP call-signs, and should therefore be resilient to a re-connection This has now been done. -Stuart -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
