Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 19:27 schrieb Harald JOHNSEN: Oliver Schroeder wrote: 1) out of reach [...] I think the range should be user configurable. So it's possibly a good idea to include a similar check in the flightgear client. The server does a precheck, i.e. does not send packets from clients which are for sure out of reach, and flightgear decides for itself if it is worth building up a property tree and display the other client or not. This would mean that flightgear is capable of building a property tree on the fly. But that way we can improve the multiclient capability of flightgear. It does not need to do any rendering of clients which are not in sight, but can bravely display them eg. on radar. The other way would be to implement special network packets which tell the server the, erm, range of reach of the client (and possibly other values which might be usefull). But for these packets we need a data-received-confirmation mechanism to make sure the server really got that value(s). 2) chat messages [...] As Pigeon said, make that a separate window, because the ATC line is allready nearly impossible to read ;) It should not be hard to code but the atc code is not good for that (anyway it does not queue messages). I don't think it's a good idea to handle chat messages in another way then messages from ATC (or any other type of conversation). There should be one interface for all types of messages and every module (currently ATC and maybe chat messages in the near future) should use it. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] feature request: MultiPlayer's Callsigns in Viewport
Hi, what about a callsign identifier being displayed for each MultiPlayer airplane in the viewport of FGFS (and maybe a keyboard shortcut or an option menu for enabling/disabling the callsign visibility)? I'm thinking about something like the City-Popup discussed earlier in the ML. So we know who's the pilot flying the airplane we have around :-) It will be very usefull when multiplayer chat system will be available for team flight coordination. Airplanes still do not have other distinctive visual dientifier so a bunch of c172 look all the same. The future MP Networking code will of course have other kind of features and possibility but right now it seems to be the simplest way to identify other users in VFR. have a nice day, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: Oliver Schroeder 3) artificial life at airports [...] Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding knowledge to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 03:46 schrieb Pigeon: I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign observer, then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. I was thinking about oberservers, too. So it will be possible to build radar stations (human operated) and tower controll etc, without disdurbing the other clients (which would try to render the observer). Using the callsign observer to mark observers is possibly the best approach for the moment, as it will work with the current client (unless there are more then other 10 clients). But then again the question about reach arises. Does an observer only get information about clients in its reach or about all clients connected to the server? For generating a map of current clients connected to the server this way is not appropriate. The map generator would have to listen some seconds to the server in order to get information of (hopefully all) clients. A better way is to implement some kind of admin protocol in the server based on TCP rather then UDP to get (and maybe set, too) information on connected clients. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: Oliver Schroeder 3) artificial life at airports [...] Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. Yes FG is big, and would have unused functions. Against this has to be balanced the time and risk in developing and maintaining a stripped down version. I don't have a handle on the size of that task or the risks involved. I suggested some time ago that the first player's system might handle all the admin tasks - that way you get the AI traffic, carrier movements etc. virtually free. However, there are significant questions surrounding that idea: in particular what happens when the first player leaves. It ought to be possible for the 2nd player to take up the task, because both systems should be aligned. There is also the load on the individual client to be taken into account. This is beginning to look like some of the NATO data links where there was no central server, but each unit contributed to the whole environment. Hmm ... We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding knowledge to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? I'm not sure exactly what you mean by a scriptable client. Does this mean that it has pre-scripted AI traffic, carrier movements, weather etc.? A little crude perhaps, but effective, but see my comments above. On the other hand we could tell each client what the AI traffic should be and let the client do all the updating. Less bandwidth required, at the trade-off of a build up of errors. Good enough for AI traffic, but perhaps not for the carrier. Of course, this is what happens with the player aircraft - they must already exist on the client system, and this could also be the case for the AI traffic flightplan. If you are saying that the server should have as little knowledge as possible, then I would go along with that. I think the server probably needs to coordinate the network time but beyond that ... there is a case for the server to filter by range, but this could also be done by the client. I have no strong view on how this should be achieved. We should build on what we already have in order to achieve a fully coordinated environment. We should not be re-inventing wheels, flaps or anything else :-) Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: I don't think it's a good idea to handle chat messages in another way then messages from ATC (or any other type of conversation). There should be one interface for all types of messages and every module (currently ATC and maybe chat messages in the near future) should use it. Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I agree, we already have to model radios, so if people want to talk, let them talk on the radios. Type a message and whoever is on your freq gets that text the same way they would get it from ATC. The only problem I see is that inexperienced players might not have their radios set properly. Perhaps a hint from the server about what the local ATC freq is would be enough to solve that. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: Oliver Schroeder 3) artificial life at airports [...] Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding knowledge to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Wouldn't it be easier to just have a switch in fgfs that tells it to skip the bits regarding the FDM and rendering? That would cut out most of the CPU usage. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Diamond Katana model
Sorry for the delay -- I've been away for four days, and haven't been near a computer. Well, it's not the Katana that's doing that, it's you ;). You could use the standard Cessna or the Cub to practice circuits and lining up on final correctly. Early on I tried training in a Tomahawk and, once I switched to the Katana, found that they handle entirely differently, even though they're both trainers. I thought about trying a Cub or a 172, but thought I'd find that same phenomena, only in a model rather than the real thing. Besides, I've been watching/trying FG since 1999 and haven't contributed much, so I thought I might submit this. I have my own copy of the Katana's POH, so the three-views, handling specs, balance weights, etc (everything you'd find in the owner's manual) is available. I know how to run XFoil and I know the airfoil they're using, so I suppose I could model some of the coefficients I'm missing. I read through a Google-tranlsated version of the German MSFS/Diamond project. I wish they'd do something like this for FG, too. Would it hurt to ask if they'd be interested? I don't think it'd be appropriate for me to do it, but if Curt were to approach them they might listen; since they're an aircraft manufacturer some of the folks who work on the FDMs might carry weight, too. -j ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] view/ground intersection question
How difficult would it be to make a nasal function call that would return the lat/lon/alt of the point on the ground under the cursor? I am trying to make a nasal system to lock the view onto the end of the runway, or any arbitrary point, and I need a way to get the coords so that I can tell the nasal code where to point the view. I think that I could define a lookat view instead of th nasal stuff, but I don't want to use one of the pre-existing views, and adding a 7th view tends to cause compatibility issues with just about anything that touches the view system. Either way, I still need a way to get the coords. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: aviation movie link
I imagine there are a few people on this list that like to watch airplanes. There is some beautiful photography here (Requires quicktime plugin ...) http://www.onesixright.com/video/aerials.html Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS
Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: "I/O exception occurred: Connection refused: I HATE YOU" I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Thanks in Advance Neville van Deventer ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS
Neville van Deventer wrote: Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: I/O exception occurred: Connection refused: I HATE YOU I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Hmmm, that's not a very nice error message, I'm sure it wasn't meant literally. :-( If you tell me the exact time you tried to connect and what machine you connected from (name/ip) I could look in the server logs to see if there are any clues there. I haven't ever seen this message before so it's hard to say if it's coming from our server, or being generated locally by your cvs client. What platform are you running on? CVS involves the network, so I don't know if there could be some firewall in the middle that is blocking traffic. Do you get long time outs before the error message, or is it returned immediately? Do you have write access to your local cvs tree and enough disk space? That's all I can think of off the top of my head. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: aviation movie link
Le mercredi 20 juillet 2005 à 09:53 -0500, Curtis L. Olson a écrit : I imagine there are a few people on this list that like to watch airplanes. There is some beautiful photography here (Requires quicktime plugin ...) http://www.onesixright.com/video/aerials.html Curt. Wonderful. Thanks -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Neville van Deventer Hi List, Could anyone perhaps tell me how to connect to the cvs at cvs.flightgear.org without getting the following error Error validating location: I/O exception occurred: Connection refused: I HATE YOU I followed the Instructions on the web-site, and I get the same thing for simgear as well. Any suggestions on how I can connect to the CVS ?? Thanks in Advance Neville van Deventer Works here. What _exactly_ are you doing? Any possibility that you have a virus on your system? Regards, Vivian P.S. Please use plain text on this list ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Thanks for the responses Vivian and Curtis, In Future I Will use Plain Text, my Appologies ... OK, Setup and what I'm Doing, I Just tried it now again, while writing this message so you can check the logs for the past 5 min's or so, I've been thying this most of the day, but with no success. I'm using the guest username and password as described on the Web Page. I'm running Windows XP Professional operating System, Eclipse IDE as my Dev Environment, I Currently have 5 other cvs repositories,( 1 local and 3 on the Net codehaus.org, objectweb.org, and sourceforge.net). My IP Address is 198.54.42.106 which my alternate is 198.54.42.107, we have a 256K line, connection is via a PIX Firewall. Host name is NEVILLE_HP, and it takes about 5 seconds after clicking connect to get the message. No Outgoing ports are blocked at this time and limited ports are allowed in. No Virus on my system, I Update regularely, using Norton corporate Edition. Disk space I Also thought might be a problem so I Cleared up some space (Currently I've got about 3.5G Free). I Think that's about it... Thanks in Advance for the Help. Neville PS: Sorry about not using plain text originally. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: 20 July 2005 06:04 PM To: 'FlightGear developers discussions' Subject: RE: [Flightgear-devel] CVS Works here. What _exactly_ are you doing? Any possibility that you have a virus on your system? Regards, Vivian P.S. Please use plain text on this list ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] view/ground intersection question
Josh Babcock wrote: How difficult would it be to make a nasal function call that would return the lat/lon/alt of the point on the ground under the cursor? You certainly can't do it in Nasal alone. Code would have to be written to project a line between the eyepoint and the cursor location and intersect this with the scene graph, convert to the global cartesian coordinate system, then to a WGS84 coordinate. Non-trivial, sadly. But not impossible. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS
Neville van Deventer wrote: Error validating location: I/O exception occurred: Connection refused: I HATE YOU Heh, that's amusing. I googled this, and it turns out that I HATE YOU is the defined response in the CVS protocol for authentication failures. :) You may have a bad password in your .cvspass file. Try removing any flightgear.org lines, or removing the whole file. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Neville van Deventer Thanks for the responses Vivian and Curtis, In Future I Will use Plain Text, my Appologies ... OK, Setup and what I'm Doing, I Just tried it now again, while writing this message so you can check the logs for the past 5 min's or so, I've been thying this most of the day, but with no success. I'm using the guest username and password as described on the Web Page. This definitely works cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.9 login CVS password: guest I've just tried it. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] CVS
Done, Sorted, I've got a connection now, Thanks Nev -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ross Sent: 20 July 2005 06:41 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] CVS Neville van Deventer wrote: Error validating location: I/O exception occurred: Connection refused: I HATE YOU Heh, that's amusing. I googled this, and it turns out that I HATE YOU is the defined response in the CVS protocol for authentication failures. :) You may have a bad password in your .cvspass file. Try removing any flightgear.org lines, or removing the whole file. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Josh Babcock wrote: Right, it would be silly to send all that data to the server when all it needs to know is where your are and what you can see. Plus the position data could be sent at low resolution. The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. This way your wingman always gets updated, and a burning/turning dogfighter will get frequent updates, but a jetliner moving in a straight line is nicely optimized and receives very few updates. You can also handle orientation error this way, by giving the object a radius and figuring that a 180 degree orientation different produces an error of that size. Either way the server would have to be able to handle multiple instances of the same callsign. Otherwise an invisible observer could silently prevent a flier from connecting. Better would be to assign a prefix or suffix to duplicate callsigns, so that the second andy to connect becomes _andy or andy-0, etc... Also, I'd suggest defaulting the callsign to the USER (unix, cygwin) or USERNAME (winnt) environment variables where available, to avoid the problem of zillions of identical flightgear-user planes flying around. Sane defaults are always good. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Oliver Schroeder wrote: I was thinking about oberservers, too. So it will be possible to build radar stations (human operated) and tower controll etc, without disdurbing the other clients (which would try to render the observer). Rather than special casing this (special case abstractions are the work of the devil), why not implement the priority sorting update scheme I mentioned in the previous message and have the observers be motionless objects at some sane position like the center of the earth, so they see all clients with the same priority. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Feature request: will sound options be saved?
Hi, current situation is: FGFS v.0.9.8 win32; shutting down FGFS the sound configuration (volume and mute) is not saved as other configurable options. Will this be possible in future releases? :-) Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: aviation movie link
Nice. There's our chase view! And for those who do not have the qt plugin but do have xine you can download it with: wget http://www.terwilligerproductions.com/video/aerials.mov Best, Jim -Original Message- From: Curtis L. Olson [EMAIL PROTECTED] Sent: Wednesday, 20. Jul 2005 10:53 -0400 To: flightgear-devel@flightgear.org Subject: [Flightgear-devel] OT: aviation movie link I imagine there are a few people on this list that like to watch airplanes. There is some beautiful photography here (Requires quicktime plugin ...) http://www.onesixright.com/video/aerials.html Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
From: Jon Berndt [mailto:[EMAIL PROTECTED] I have placed a compiled tarball of yesterdays OpenAL CVS files @ http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz you might want to test these against the current FGFS before blindly overwriting your currrent installation Is this distribution modified for use with CygWin as discussed in this thread recently? Namely, the _WIN32 - WIN32 issue, as well as the #define MVC? I grabbed Norman Vine's tarball and have finally put sound into a Cygwin build. I noticed that there are still two instances of _WIN32 in the headers: One is in alu.h, and one is in alut.h. For example, in alu.h ... #ifdef _WIN32 #define ALUAPI #define ALUAPIENTRY __cdecl ... I don't know if these are intentional or by oversight. My first success was after changing the _WIN32 to WIN32 in those places. However, I cannot conclude that change was necessary due to other oversights along the way on my part. For example, one must make sure the openal32.dll used by fgfs.exe is the one distributed in Norman's tarball! Other OpenAL versions cause a runtime error. I was stuck on that one for awhile. :-) Thanks, everyone. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] current-view property question
From: Josh Babcock Are goal_heading_offset_deg and heading_offset_deg just aliases for each other? It looks like one is set from the other in view.cxx. Josh The idea is the heading_offset is gradually changed over several frames. For example if you hit the shift right arrow, then the camera view gradually (over half a second or so) pans 90 degrees right. I'm not sure off hand if that is still the case as the same thing could be accomplished with a nasal script, but last I knew the goal is the value the offset converges to. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] current-view property question
Jim Wilson wrote: From: Josh Babcock Are goal_heading_offset_deg and heading_offset_deg just aliases for each other? It looks like one is set from the other in view.cxx. Josh The idea is the heading_offset is gradually changed over several frames. For example if you hit the shift right arrow, then the camera view gradually (over half a second or so) pans 90 degrees right. I'm not sure off hand if that is still the case as the same thing could be accomplished with a nasal script, but last I knew the goal is the value the offset converges to. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I figured that was it, but it doesn't seem to work anymore. So goal is the one to set if you want it to go smoothly once this gets fixed, I guess. Thanks. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] view offsets
I can adjust the view offsets in the cockpit view, then switch to another view and back and those adjustments are still there. My question is, where is that data stored when I am in another view? The only place I can seem to find it in in current-view, but it is only visible there when I am in view 0. Obviously it is being copied somewhere else. Where? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Cirrus SR20 Model?
Is there anyone out there in FlightGear developer land that would be interested in doing a Cirrus SR20 model for FlightGear? Highest priority would be the 3d model and as much of a 3d cockpit as we can do (realizing we aren't real strong on the glass cockpit stuff yet.) This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. Either way, the nice thing is we have direct access to a real SR20 and a real SR20 pilot so we should be able to get as much information and as many pictures as we want. Is there anyone who'd be up for something like this? Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. :-) Thanks, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: fgfs hangs loading scenery objects (some AC and airports but, not all)
I did some more experimenting with two different Linux installs updated
to yesterday's CVS (plib, SimGear,fgfs, and $FG_ROOT). All the jsbsim
aircraft that I tried cause fgfs to hang at the same place when starting
from airports from w110n40.tgz. None of the yasim aircraft I tried have
this problem with these airports. By the way, before I updated my Linux
notebook to yesterday's cvs, the jsbsim aircraft did not have the
problem with airports from w110n40.
Would someone else try the default c172 with say KBJC, or KGXY, or KLBF
and see if you have the same hang?
Thanks,
Dave P.
This bug showed up when I updated from CVS last weekend. Description
follows:
(1) With the default c172, fgfs hangs with the loading scenery
objects is displayed if --airport= (any airport from w110n40) It does
not hang for the j3cub or the pa28-161.
(2) With (atleast som) airports outside w110n40 and the default c172,
it does not hang. Here are some examples:
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=j3cub
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/j3cub/cub-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=c172
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
(I killed fgfs by closing the window after it hang)
fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion
`fgState.Initialised' failed.
Aborted
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=pa28-161
Failed to find runway 28R at airport KLBF
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=pa28-161
Failed to find runway 28R at airport KBJC
RenderTexture Error: Couldn't find a suitable pixel format.
Reading xml electrical system model from
/usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml
WARNING: Legacy engine definition in YASim configuration file. Please fix.
(ran fine)
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=c172
Failed to find runway 28R at airport KBJC
RenderTexture Error: Couldn't find a suitable pixel format.
(I killed fgfs by closing the window after it hang)
fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion
`fgState.Initialised' failed.
Aborted
[EMAIL PROTECTED] FlightGear]$ ./bin/fgfs
--fg-scenery=/usr/local/Scenery-0.9.8 --airport=KDSM --aircraft=c172
Failed to find runway 28R at airport KDSM
RenderTexture Error: Couldn't find a suitable pixel format.
Initializing Nasal Electrical System
(ran fine)
[EMAIL PROTECTED] FlightGear]$
The scenery is from 0.9.8 on www.flightgear.org.
I did an update of plib, SimGear, and fgfs source as well as the
contents $FG_ROOT using cvs update -dP and did a make clean before
recompiling all before the above examples were run.
Was running great from cvs before last weekend update.
System: Athlon 3200+ XP with 512 MB of PC3200, NVIDIA FX 5600 ultra.
MB Biostar M7NCD Ultra
Wierd bug?
--
Message: 4
Date: Tue, 19 Jul 2005 12:48:30 -0500
From: Dave Culp [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] suggestions/questions regarding
multiplayer
To: FlightGear developers discussions
flightgear-devel@flightgear.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=iso-8859-1
So the question is: How can I easily calculate the distance and how
many nautical miles are out of reach (thinking of e.g. radar systems)
?
You can compute distance at an altitude using SimGear functions
Ack, don't even *think* about doing the math in a GIS datum.
I agree. You don't need overkill here. A simple check of the bounding square
should work fine. Something like this:
/* Check if position 2 is within a square of side R nautical miles that has
position 1 at a corner. This is a fast approximation of checking the distance
between them, avoiding the use of trigonometric or sqrt functions. This
assumes latitude in the range (-90,90) and longitude (-180,180).
*/
bool IsWithinRMiles( double lat1, double lon1, double lat2, double lon2,
double R ) {
double nm_per_deg_lat = 60.313;
double nm_per_deg_lon = 60.109 - fabs(lat1 * 0.66788);
double lat_diff = fabs(lat1 - lat2);
double lon_diff = fabs(lon1 - lon2);
if (lon_diff 180.0) lon_diff = 360.0 - lon_diff;
[Flightgear-devel] suggestions/questions regarding multiplayer
Andy wrote: The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. This way your wingman always gets updated, and a burning/turning dogfighter will get frequent updates, but a jetliner moving in a straight line is nicely optimized and receives very few updates. Also a consideration is the detail of the updates. A plane 10km away can be have an accuracy of 1m but you would like a plane in formation to fly have about 1cm accuracy. Sending velocity and acceleration data can also smooth make flight smother, but only for nearby aircraft. Also you might want to see moving parts, lights, smoke etc on nearby planes. Likewise the same goes for radars, which need to know nothing about moving parts or which lights are on. But how will the server calculate this? There will be 2^N-N relationships for the computer to work out which levels of reports to send to each client. For 20 players that is over a million calculations that the computer must perform every cycle. The load would be distributed more evenly if individual computers decide which data they want and send requests to the server. This would be good for accommodating the programs like radars as the server does not need to know anything about the client. Then the computer needs an N by N matrix to store this information. And needs to search through it to find which data to send. I guess the solution to this would be to have specific matricis for each level of report and just cycle through them. Andy wrote: Also, I'd suggest defaulting the callsign to the USER (unix, cygwin) or USERNAME (winnt) environment variables where available, to avoid the problem of zillions of identical flightgear-user planes flying around. Sane defaults are always good. Or you could just have no default call sign an force people to choose one before logging on. Cheers, Mostyn ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] view offsets
From: Josh Babcock [EMAIL PROTECTED] I can adjust the view offsets in the cockpit view, then switch to another view and back and those adjustments are still there. My question is, where is that data stored when I am in another view? The only place I can seem to find it in in current-view, but it is only visible there when I am in view 0. Obviously it is being copied somewhere else. Where? Are you a C++ programmer? My answer assumes that you might not be, or are just starting out (otherwise you'll just see that you missed the obvious :-)). The property subsystem is a feature of FlightGear/SimGear. C++ objects can contain data as C++ variables, but in the case of the FGViewer objects, only the CURRENT view (the one you see on the screen) is published to FlightGear's property tree. All the viewer objects are still there (not destroyed) for as long as FlightGear is running, so when you switch back and forth between views you are always switching between the same instances of FGViewer and their respective offset values. It sounds like you are reading code, so don't forget to look at the viewmgr.?xx files. Reading that as well will give you a better idea of how views are managed. In a nutshell, only the current active view is updated (i.e. SGSubsystem::update). Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
