Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Vassilii Khachaturov wrote: Sorry if it's been known mentioned already --- among the 0.9.9 features I think it's would be great to get back the high-res IFR version of a c172 aircraft (c172-610x-null). (BTW, is it not there in the CVS version because of the new electrical c172 system approach?) I've untied the c172 knot in the past because it was to tied to each other. In the process I took the liberty to remove some of the less useful configuration files. It would be easy to add it again since the high-res panel is still available in Aircraft/c172/Panels. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
Sorry if it's been known mentioned already --- among the 0.9.9 features I think it's would be great to get back the high-res IFR version of a c172 aircraft (c172-610x-null). (BTW, is it not there in the CVS version because of the new electrical c172 system approach?) Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Am Tuesday 04 October 2005 12:51 schrieb Harald JOHNSEN: > > Some 3d models have conditional displays based on the view number. In > internal view their often don't draw > most of the external model to be fps friendly. A simple solution for > that problem is to set the view number > to 'external' when drawing MP planes. But this is not enought, 3d models > should have LOD and handle > correctly the fact that they can be used as MP/AI aircraft (some > animation rules could be different then > for the user aircraft). > AFAIK flightgear does support dynamic Level-Of-Detail, and most ACs already have an anppropriate XML.set. But this is for sure something we have to draw some more attention in the future. > You will spend a lot of your time replying to question on irc or lists > when suddenly more and more people > start to use the mp feature. Or you could give the user some feedback on > what's happening. > Is the host reachable, is the server launched, how many users are > connected ? What the hell do you > want me to do in a console ? Give the user the tool he needs or you'll > spend you time doing the hot line. Of course I want to give as much information to the user as is necessary and useful. But currently all I can do is to print some information to the console which started fgfs (and I'm already doing it). The more appropriate way would be to display information within the simulation on screen, or in a seperate window. But currently it's simply not possible. All in all flightgear has a long way to go, before we can consider the multiplayer part to be something like "real" (or "good enough") But the question in this thread is: what do we need to solve before the next release is done and can it be done in the next, say, 2 months? My impression is that MP is working good enough for now, and all enhancements should be done after the next release. Any comments welcome, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Oliver Schroeder wrote: Am Tuesday 04 October 2005 09:26 schrieb George Patterson: I was not aware that it is possible to switch to another clients cockpit. However, if this really depends on properties which get not transmitted over the network yet, we should disable this in the upcoming release. Sending properties over the net is more complicated than sending some values. I will address this in a seperate thread in the next days. Some 3d models have conditional displays based on the view number. In internal view their often don't draw most of the external model to be fps friendly. A simple solution for that problem is to set the view number to 'external' when drawing MP planes. But this is not enought, 3d models should have LOD and handle correctly the fact that they can be used as MP/AI aircraft (some animation rules could be different then for the user aircraft). I'm not sure what we gain if you (fgfs respectively) can ping the server. If you only want to debug the transmitted data you can simply connect 2 clients directly, without a server in the middle. Note that you can only connect 2 clients directly, not more. If you only want to know if the server recognises your (or any other) connection, you can simply telnet to the server and see the list of it's clients. The telnet port is commonly CONNECT-PORT +1. You will spend a lot of your time replying to question on irc or lists when suddenly more and more people start to use the mp feature. Or you could give the user some feedback on what's happening. Is the host reachable, is the server launched, how many users are connected ? What the hell do you want me to do in a console ? Give the user the tool he needs or you'll spend you time doing the hot line. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Tue, 2005-10-04 at 11:11 +0200, Oliver Schroeder wrote: > Am Tuesday 04 October 2005 09:26 schrieb George Patterson: > > > > The cockpit view of other planes need to be fixed. For those that aren't > > aware of it. If you view another players/pilot's plane, you only see the > > cockpit panels and perhasp part of the tail or insignia. This is because > > the property list isn't send over the network. I think I have explained > > it right. > > > > I was not aware that it is possible to switch to another clients cockpit. > However, if this really depends on properties which get not transmitted over > the network yet, we should disable this in the upcoming release. > Sending properties over the net is more complicated than sending some values. > I will address this in a seperate thread in the next days. > It's not possible. Excuse my explanation. I meant that only the other planes cockpit panels are viewable from your cockpit and not the whole plane. > > Also can we add a "ping" function to flightgear which requests the > > server to send a packet back to the user's client. This will make is > > easier to debug people's MP setup. The MP server will not send the > > player's packets back to itself, fair enough decision except if there is > > only one player connected. > > I'm not sure what we gain if you (fgfs respectively) can ping the server. If > you only want to debug the transmitted data you can simply connect 2 clients > directly, without a server in the middle. Note that you can only connect 2 > clients directly, not more. > If you only want to know if the server recognises your (or any other) > connection, you can simply telnet to the server and see the list of it's > clients. The telnet port is commonly CONNECT-PORT +1. > Yes, but just checking if the client is connect demonstrates that the client is sending the udp packets out okay. It does not show if the packets are able to get back in through someones firewall/NAT gateway. We have seen this happen on #flightgear irc channel a few times with a player saying that they can see other players but not be seen themselves. Maybe I'm barking up the wrong tree. George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Am Tuesday 04 October 2005 09:26 schrieb George Patterson: > > The cockpit view of other planes need to be fixed. For those that aren't > aware of it. If you view another players/pilot's plane, you only see the > cockpit panels and perhasp part of the tail or insignia. This is because > the property list isn't send over the network. I think I have explained > it right. > I was not aware that it is possible to switch to another clients cockpit. However, if this really depends on properties which get not transmitted over the network yet, we should disable this in the upcoming release. Sending properties over the net is more complicated than sending some values. I will address this in a seperate thread in the next days. > Also can we add a "ping" function to flightgear which requests the > server to send a packet back to the user's client. This will make is > easier to debug people's MP setup. The MP server will not send the > player's packets back to itself, fair enough decision except if there is > only one player connected. > I'm not sure what we gain if you (fgfs respectively) can ping the server. If you only want to debug the transmitted data you can simply connect 2 clients directly, without a server in the middle. Note that you can only connect 2 clients directly, not more. If you only want to know if the server recognises your (or any other) connection, you can simply telnet to the server and see the list of it's clients. The telnet port is commonly CONNECT-PORT +1. cheers, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
George Patterson wrote: The nicer lighting would be good for those that want to compare Microsoft Flight Simulator 2004 with FGFS. gives a fairer comparison. I'm not sure what you mean by this, better lighting *effect* or just better sky lighting? If so, what do you think could be improved? I've heard several comments on the day/night lighting that suggest that it's pretty close to reality. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Mon, 2005-10-03 at 19:57 +0200, Melchior FRANZ wrote: > * Melchior FRANZ -- Monday 03 October 2005 19:47: > > * Durk Talsma -- Monday 03 October 2005 18:08: > > > > (B) which bugs need to be fixed (and by whom :-)? > > > > > - Setting a wrong path for --fg-scenery results in an abort > > > > I'll look into this. > > It behaves exactly as it is supposed to: If no paths are given, > the default is used. If paths are given, fgfs uses all that do > actually contain scenery. (It doesn't complain about paths that > don't!) But if a user specifies one or more paths but *none* > contains valid scenery, it aborts with this error message: > > Fatal error: No valid scenery path defined! > > What do you think fgfs should do with no scenery? I consider > this bug "fixed". :-) > "Works for me" might be closer. If flightgear can't find valid scenery in the area specified, what else can we do about it? Perhaps, popping up a dialog box but the message is okay. George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Mon, 2005-10-03 at 14:02 +0200, Melchior FRANZ wrote: > And here is what I have to say. :-) > > > (A) will a new official plib release be required? > I'm not really qualified to answer this one. > > > > (B) which bugs need to be fixed (and by whom :-)? > > I ran into another groundcache endless loop yesterday. This is IMHO > a showstopper that needs a fix. I'll look into that next time I see it > (and let Mathias fix it ;-). > > A fix for the cut-off 3d clouds would be nice. They collide with > overcast cloud layers. Probably not easy to fix. No show-stopper. > > The cockpit view of other planes need to be fixed. For those that aren't aware of it. If you view another players/pilot's plane, you only see the cockpit panels and perhasp part of the tail or insignia. This is because the property list isn't send over the network. I think I have explained it right. Also can we add a "ping" function to flightgear which requests the server to send a packet back to the user's client. This will make is easier to debug people's MP setup. The MP server will not send the player's packets back to itself, fair enough decision except if there is only one player connected. > > (C) which features need to be completed? > > replacing the non-GPL-compatible sun/moon stuff > Using an alternative GUI theme by default would IMHO be a good idea. > Doesn't have to be mine, of course. The sharper and smaller pixmap > fonts look better, the dark color is night-flight-friendlier, and > a new look would cause an immense AAAHHH effect. :-) > The nicer lighting would be good for those that want to compare Microsoft Flight Simulator 2004 with FGFS. gives a fairer comparison. > The new shadows should possibly be activated by default. Or does > not enough 3D hardware/software support it, so that this would > cause too many problems? Activate 3D clouds by default, too? > > > (D) which a/c should be included? > > I don't even know which a/c were in the last release. But the b1900d > has such a nice cockpit, that it should get added if it isn't already. > Yes, the b1900d is very nice and suitable for inclusion. The Citation has a few issued with the nose wheel shimmying across the runway during take off. (my opinion :-) ) > > > (E) for when could/should the release be planned (i.e. how much time > > is left to fix bugs etc.)? > I'll stay out of this one as well, seeing I haven't been subscribed to the -devel list for the last release. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Monday 03 October 2005 20:31, Melchior FRANZ wrote: > * Durk Talsma -- Monday 03 October 2005 20:18: > > Could not find VVNS > > Could not find VVNT > > Aborted > > [EMAIL PROTECTED]:~/src/FlightGear-0.9/source-devel> > > You have compiled with glut? And not used the -fexceptions flag? > That's possible. I'm using freeglut, but didn't compile this one myself. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
* Melchior FRANZ -- Monday 03 October 2005 20:31: > You have compiled with glut? And not used the -fexceptions flag? Well, it's the same for SDL, of course ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
* Durk Talsma -- Monday 03 October 2005 20:18: > Could not find VVNS > Could not find VVNT > Aborted > [EMAIL PROTECTED]:~/src/FlightGear-0.9/source-devel> You have compiled with glut? And not used the -fexceptions flag? In this case you don't get flightgear's error messages, but a simple and meaningless "abort". This is not a FlightGear bug, but a broken setup. Compile (free)glut like so: $ CFLAGS="-fexceptions $CFLAGS" LDFLAGS="-fexceptions $LDFLAGS" ./configure glut is pure C, but the compiler/linker does still need the stack unwinding information to hand the exceptions from C++ through C (glut) over to main.cxx. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Monday 03 October 2005 19:57, Melchior FRANZ wrote: > * Melchior FRANZ -- Monday 03 October 2005 19:47: > > * Durk Talsma -- Monday 03 October 2005 18:08: > > > > (B) which bugs need to be fixed (and by whom :-)? > > > > > > - Setting a wrong path for --fg-scenery results in an abort > > > > I'll look into this. > > It behaves exactly as it is supposed to: If no paths are given, > the default is used. If paths are given, fgfs uses all that do > actually contain scenery. (It doesn't complain about paths that > don't!) But if a user specifies one or more paths but *none* > contains valid scenery, it aborts with this error message: > > Fatal error: No valid scenery path defined! > Hmm, I think there's more to it than meets the eye: I had FlightGear die right after I had upgraded my Linux box, but before I discovered I had not yet moved the scenery tree over from my backup drive. I have specified: --fg-scenery=/home/durk/FlightGear-Scenery-0.9.7/ When this path exists everything works fine, but if I move FlightGear scenery to some other path, I get Could not find VVNS Could not find VVNT Aborted [EMAIL PROTECTED]:~/src/FlightGear-0.9/source-devel> (With the two "Could not find" Messages coming from the Traffic manager) Problem is not that FlightGear refuses to run without scenery( which makes sense), but that the error message I'm seeing in this case isn't particularly insightful. I think the problem here is not that FlightGear scans directories that don't contain scenery, but that FlightGear is trying to open a directory that doesn't exist. HTH, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
* Melchior FRANZ -- Monday 03 October 2005 19:47: > * Durk Talsma -- Monday 03 October 2005 18:08: > > > (B) which bugs need to be fixed (and by whom :-)? > > > - Setting a wrong path for --fg-scenery results in an abort > > I'll look into this. It behaves exactly as it is supposed to: If no paths are given, the default is used. If paths are given, fgfs uses all that do actually contain scenery. (It doesn't complain about paths that don't!) But if a user specifies one or more paths but *none* contains valid scenery, it aborts with this error message: Fatal error: No valid scenery path defined! What do you think fgfs should do with no scenery? I consider this bug "fixed". :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
* Durk Talsma -- Monday 03 October 2005 18:08: > > (B) which bugs need to be fixed (and by whom :-)? > - Setting a wrong path for --fg-scenery results in an abort I'll look into this. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Melchior FRANZ wrote: > The new shadows should possibly be activated by default. Or does > not enough 3D hardware/software support it, so that this would > cause too many problems? Activate 3D clouds by default, too? I like it very much to have 3D clouds and shadows and on an ATI Radeon X800-sized board they don't have noticeable impact on the performance. On older boards in the Radeon R200-range performance breaks down significantly. I vote for disabling both by default as it is very convenient to toggle these features via the menu at runtime, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
* Melchior FRANZ -- Monday 03 October 2005 14:02: > > (B) which bugs need to be fixed (and by whom :-)? Forgot my own homework: I'll fix endless querying of stale METAR data. It seems to have been done for the init phase already (Harald?), but should also be considered later on. Then there is the carrier "nearplane" problem that was already fixed and re-occurred in r1.25 of renderer.cxx. The fact that one can't see the deck around the aircraft, but a big hole. Why was this reverted? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
Melchior FRANZ wrote: > > The new shadows should possibly be activated by default. Or does > not enough 3D hardware/software support it, so that this would > cause too many problems? Activate 3D clouds by default, too? > Both shadows and 3d clouds, although great eye candy, both cause a significant frame rate hit, and should therefore be off by default IMHO. And I'm not sure that we have a cvs version which compiles under Cygwin, at least last time I tried a couple of days ago we hadn't. Or perhaps I should say I haven't. That's not a FG problem - I haven't been able to compile OpenAL under Cygwin yet. I have a workaround, of course. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
And here is what I have to say. :-) > (A) will a new official plib release be required? Depends: fgfs with legacy GUI does probably not need a new plib, at least I'm not aware of relevant bugfixes. (any important js fixes?) If we advertise GUI theming (which we IMHO should) -- and maybe even switch to a new theme -- then a new release would be advisable: pixmap fonts aren't handled correctly by the last release, as well as some widget colors. Another color problem is yet to be fixed, but no show-stopper. > (B) which bugs need to be fixed (and by whom :-)? I ran into another groundcache endless loop yesterday. This is IMHO a showstopper that needs a fix. I'll look into that next time I see it (and let Mathias fix it ;-). A fix for the cut-off 3d clouds would be nice. They collide with overcast cloud layers. Probably not easy to fix. No show-stopper. > (C) which features need to be completed? replacing the non-GPL-compatible sun/moon stuff Using an alternative GUI theme by default would IMHO be a good idea. Doesn't have to be mine, of course. The sharper and smaller pixmap fonts look better, the dark color is night-flight-friendlier, and a new look would cause an immense AAAHHH effect. :-) The new shadows should possibly be activated by default. Or does not enough 3D hardware/software support it, so that this would cause too many problems? Activate 3D clouds by default, too? > (D) which a/c should be included? I don't even know which a/c were in the last release. But the b1900d has such a nice cockpit, that it should get added if it isn't already. > (E) for when could/should the release be planned (i.e. how much time > is left to fix bugs etc.)? That's up to the master to decide. But I would really like to know soon enough for when the release is planned. Let's say, two weeks before. It would also be nice if we could see the list of new features. There was so much changed that some things are possibly missing (although Curt usually does an amazing job here). That's what I can say off the top of my head, but I'll probably add some points as I run into them ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
