RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. actually resisted is not a strong enough word I realize project goals evolve but . IMO this is an admirable feature Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
Paul Morriss wrote: Hiya, since the inclusion of prior e-mails is starting to make for a long message, I will make my points about the previous message in bullet points: 6) Al West has started to put a website together for cumulas (http://www.aurora-solutions.co.uk/~cumulas/), which is where I was going to put design notes etc, if people agree? Good to see something is finally gaining speed. For one thing, you might have misunderstood me in my previous post. What I meant to say is that the server program could be a separate project (eventually to be included in the binary releases like fgrun is now), but that changes to the protocol code of FlightGear can be sent for inclusion in CVS. This looks the best available option (to me at least, others might disagree). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Compliation of CVS -Source Error BEHOLD etc
On 11/5/03 at 1:54 PM Andy Ross wrote: # Download and build SimGear: # # (This presumes you already have a working Metakit installation. I # don't install metakit globally on my machine either, but that's # because I'm paranoid; it's always been very stable across FlightGear # releases.) # cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.2 login cvs -d :pserver:[EMAIL PROTECTED]:/var/cvs/SimGear-0.2 co SimGear cd SimGear ./autogen.sh ./configure --prefix=/home/andy/fg make make install cd .. Umm, shouldn't that be SimGear-0.3 to go with the dev branch of FG? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Compliation of CVS -Source Error BEHOLD etc
On 11/5/03 at 10:51 PM Richard Hornby wrote: I understand this - I've done it more than once. The problem persists. Tks, R Just to check, you are checking out SimGear-0.3 and FlightGear-0.9, yes? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On 11/6/03 at 1:36 AM John Barrett wrote: 3. Initial Radio Message set definition a. Tower ATC messages b. Regional ATC messages c. Ground Traffic Control There is current ongoing progress in this area within FlightGear. I haven't quite got my head round what the multiplayer server actually is yet, but at a guess I imagine you'd want the ability to replace arbitrary FG ATC services with real life humans, and for others with more than one multiplayer plane at them to be consistent in what they output to each user? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
On 11/5/03 at 2:42 AM John Barrett wrote: Any other ideas that I should include in this project ?? It would be nice if current MSFS clients could also connect and participate. I realise this could be a bit of a pipe dream though given the amount of work it'll probably take to get off the ground full stop. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problems compiling simgear
hi, I'm trying to compile last flightgear version, under windows 2000/xp: FlightGear-0.9.3 SimGear-0.3.4 plib-1.6.0.tar I compiled everything succesfully under cygwin, BUT I'm not able to do the same on MSVC7 (.NET:Microsoft Visual C++ .NET 69586-335-007-18264).I'd like to compile FG also on this compiler only for sake of completness... I followed an how-to written by Fabricio Guzman and published on the mailing list (now it is no more available), trying also to compile previous versions, as described in the paper. My main problem is compiling SimGear: I'vean huge lot of errors arising from typedefs of instanciated templates (asin SkyBVTree.h etc) Can anybody help me? thanks in advance Massimo Casanova ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
* Norman Vine -- Thursday 06 November 2003 10:10: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. | | However, FlightGear does contain several military aircraft, albeit | without munitions. Doesn't sound like such a strong resistance. :- m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Thursday 06 Nov 2003 9:10 am, Norman Vine wrote: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. actually resisted is not a strong enough word What I value about FlightGear is that it attempts to *simulate* the real world and aviation in it. The landscapes and the airports are realistic, the weather is (can be made) realistic, the celestial objects are realistic, the flight dynamics themselves are realistic, and there is superb work done on making the objects (scenery and planes) look good. I agree, though, that what is missing is other inhabitants of the simulated planet :) The biggest mismatch with reality is the absence of other air traffic, or even ground movement, and I know that people have started to address these. In the real world, though (modulo conflict zones) there is no air combat. I'd welcome other flyers in the FlightGear VR, but should the primary goal for a first interaction with them be to 'blow them outa the sky'? The spirit of simulation would rather suggest building in flight planning, ground- and air-traffic control, and generally relieving the loneliness. If I thought I could do it (and I might...) I'd begin to see if we can have FlightGear generate situation-relevant ATC radio messages by doing text-to-speech translation with Festival. Even if it only warns me about other traffic that I fail to see (so no change there :¬) I don't want you to get the idea that I have some moral objection to simulated violence, I've bought, played and enjoyed many combat sims, and I've rambled enough, so I'll just throw out some questions... where does the real-world information come from to =simulate= classified weapon and weapon platform performance? How will combat damage be modelled? Will the sim assess the location of e.g. cannon shell impacts and adjust the flight model, or put equipment out of commission? Multiplayer? Great idea, and I'd support it. Combat? Not yet... and please not in the core distribution (see Erik's earlier message). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
Melchior FRANZ writes: * Norman Vine -- Thursday 06 November 2003 10:10: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. | | However, FlightGear does contain several military aircraft, albeit | without munitions. Doesn't sound like such a strong resistance. :- There is a *huge* differeance between having military aircraft in a 'flight' simulator and a 'combat' simulator. If you want to simulate combat please make it a separate project Nothing wrong with building atop of FGFS, and in fact FGFS tries to be accomodating in that respect. Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
* Norman Vine -- Thursday 06 November 2003 12:56: Melchior FRANZ writes: * Norman Vine -- Thursday 06 November 2003 10:10: FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. Doesn't sound like such a strong resistance. :- There is a *huge* differeance between having military aircraft in a 'flight' simulator and a 'combat' simulator. Really? ;-) If you want to simulate combat please make it a separate project [...] You? =I= don't want to simulate combat (although I wouldn't care, I'd even use it). I just wanted to point out that your statement (resisted is not a strong enough word) does not match the FAQ entry. Either must be wrong. And the FAQ does explicitly refer to dog fighting or bomb dropping as an option that is =not= excluded. Of course, we can change the FAQ. I'm worried, though, that fighting capabilities could mean tradeoffs for the civilian simulation, which would certainly not be acceptable. As long as the whole thing would be a separate module (like WeatherCM) that can be compiled in or not, I'd not see much of a problem. m. PS: replacing the 'MATERIAL hubschrauber' line in bo105.ac by this MATERIAL RAL7013 rgb 0.25 0.25 0.21 amb 0.4 0.4 0.4 emis 0 0 0 spec 0 0 0 shi 0 trans 0 makes a nice military helicopter. :-P ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MSVC Build Problems
hello, Frederic I'm trying to compile FG under MSVC7 but I've almost the same problems I found on MSVC6 problems with templates and typedefs. I use FlightGear-0.9.3 SimGear-0.3.4 plib-1.6.0.tar can you tell me what - compiler version (any patch?) do you use - FG version (FG+Simgear+plib) have you compiled I've, moreover, problems to configure a correct build project for Simgear, since in 0.3.4 there's no MSVC project. thanks Massimo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
On 11/5/03 at 1:38 PM John Barrett wrote: I'm aware of the basic raw multiplayer and the OLK code (which I peeked at and am still trying to figure out the details) and what is the 3rd one ?? Dont see anything in CVS for it.. I think that was probably the Ace project. It never went into CVS as far as I know - I think it might have been a student project. Does anyone know if either the 'raw' multiplayer or the OLK code actually work at the moment - is it currently possible for 2 FG users to fly together in any shape or form or not? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
Melchior FRANZ wrote: * Norman Vine -- Thursday 06 November 2003 12:56: If you want to simulate combat please make it a separate project [...] I'm worried, though, that fighting capabilities could mean tradeoffs for the civilian simulation, which would certainly not be acceptable. As long as the whole thing would be a separate module (like WeatherCM) that can be compiled in or not, I'd not see much of a problem. Good thinking. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
David Luff wrote: Does anyone know if either the 'raw' multiplayer or the OLK code actually work at the moment - is it currently possible for 2 FG users to fly together in any shape or form or not? The multiplayer code *is* working, I'm not so sure about NetworkOLK. There is however a reported problem with the default (3d) Cessna 172 in that it can't load some sort of object of the model. I'm not sure that was addressed already. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On 11/6/03 at 11:32 AM Jonathan Richards wrote: sky'? The spirit of simulation would rather suggest building in flight planning, ground- and air-traffic control, and generally relieving the loneliness. If I thought I could do it (and I might...) I'd begin to see if we can have FlightGear generate situation-relevant ATC radio messages by doing text-to-speech translation with Festival. Even if it only warns me about other traffic that I fail to see (so no change there :¬) Hi Jonathon, I've had a play with Festival in the past, and didn't really like the output - it sounded a bit un-natural. Might be just the job for AWOS / ASOS though, and apparently ATIS is moving over to synthetic voices in real life in some locations. The infrastructure exists in FG to use canned voice files for AI and ATC in a similar manner to the ATIS. If you'd like information on how to create one yourself then just shout and I'll write a quick description, and a summary of the current phraseology needed. The very very latest CVS (not the 0.9.3 release) can generate some situation-relevant messages from the tower to the user - if you'd like to participate in the ATC development then just shout, there's plenty to do! There's a similar project to Festival concerned with speech recognition. What would be *really* cool would be to get that working providing input to the ATC system, possibly via a second PC decoding the voice and sending the message over to FG. Cutting out messing about with menus and listening to one's own transmission would make it a lot more natural (I almost wrote as real as it gets there - can't think why ;-)). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
Melchior FRANZ [EMAIL PROTECTED] wrote: From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? [...] Doesn't sound like such a strong resistance. :- We could always add some more detail to that phrase :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
David Luff [EMAIL PROTECTED] wrote: On 11/5/03 at 2:42 AM John Barrett wrote: Any other ideas that I should include in this project ?? It would be nice if current MSFS clients could also connect and participate. VATSIM ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Norman Vine [EMAIL PROTECTED] wrote: FWIW Historicaly FlightGear has resisted being a Military SIM. actually resisted is not a strong enough word I realize project goals evolve but . IMO this is an admirable feature I second that, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Thursday 06 Nov 2003 1:05 pm, David Luff wrote: The very very latest CVS (not the 0.9.3 release) can generate some situation-relevant messages from the tower to the user - if you'd like to participate in the ATC development then just shout, there's plenty to do! David - I was so enthused there, that I just started a checkout, having forgotten 'waiting for ehofman's lock'. Sounds like something from the canal era :¬) Maybe later... I loaded up all the /ATC/*.cxx files into KDevelop this morning to see if I could understand how it all fits together, but rapidly got lost in the detail. Have you got a paragraph or two to hand which describes the architecture, for want of a better word? Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:51 AM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On 11/6/03 at 1:36 AM John Barrett wrote: 3. Initial Radio Message set definition a. Tower ATC messages b. Regional ATC messages c. Ground Traffic Control There is current ongoing progress in this area within FlightGear. I haven't quite got my head round what the multiplayer server actually is yet, but at a guess I imagine you'd want the ability to replace arbitrary FG ATC services with real life humans, and for others with more than one multiplayer plane at them to be consistent in what they output to each user? replace with humans for ATC simulators (human or AI pilots -- there was a neet ATC game way back when on EGA PC that I really enjoyed -- you were the tower at chicago mdw :) or the other way around -- AI ATC for human or AI pilots and yes -- consistency is important, if FG is connectect to a server, then all AI functionality should be handled by the server, else it should be handled locally (which is where the idea of having the server so tightly integrated with the FG code comes into play) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
Any other ideas that I should include in this project ?? It would be nice if current MSFS clients could also connect and participate. I realise this could be a bit of a pipe dream though given the amount of work it'll probably take to get off the ground full stop. It's actually not that far fetched of an idea. It's technically possible if you write a wedge with FSUIPC. The same could be said for X-Plane if you do the same thing with the X-Plane SDK. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
- Original Message - From: David Luff [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 5:53 AM Subject: Re: [Flightgear-devel] Multiplayer Server RFC On 11/5/03 at 2:42 AM John Barrett wrote: Any other ideas that I should include in this project ?? It would be nice if current MSFS clients could also connect and participate. I realise this could be a bit of a pipe dream though given the amount of work it'll probably take to get off the ground full stop. Is there a published specification for the MS FS wire protocol ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Jonathan Richards [EMAIL PROTECTED] I agree, though, that what is missing is other inhabitants of the simulated planet :) The biggest mismatch with reality is the absence of other air traffic, or even ground movement, and I know that people have started to address these. In the real world, though (modulo conflict zones) there is no air combat. I'd welcome other flyers in the FlightGear VR, but should the primary goal for a first interaction with them be to 'blow them outa the sky'? The spirit of simulation would rather suggest building in flight planning, ground- and air-traffic control, and generally relieving the loneliness. If I thought I could do it (and I might...) I'd begin to see if we can have FlightGear generate situation-relevant ATC radio messages by doing text-to-speech translation with Festival. Even if it only warns me about other traffic that I fail to see (so no change there :¬) I don't want you to get the idea that I have some moral objection to simulated violence, I've bought, played and enjoyed many combat sims, and I've rambled enough, so I'll just throw out some questions... where does the real-world information come from to =simulate= classified weapon and weapon platform performance? How will combat damage be modelled? Will the sim assess the location of e.g. cannon shell impacts and adjust the flight model, or put equipment out of commission? Multiplayer? Great idea, and I'd support it. Combat? Not yet... and please not in the core distribution (see Erik's earlier message). Full combat damage handling is a phase 3 effort, phase 1 is exactly what you are asking for -- get people in the world together, and enhance the ATC AI -- I would also love to see ground traffic simulation (up to and including cars on the roads in cities if you decide to turn that level of detail on !!) Seriously -- I'm more interested in WWII dogfight style combat -- guns/wing cannon, and dropped bombs only :) So we are really talking minimal changes for that type of combat. Guided weapons can wait :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC
It would be nice if current MSFS clients could also connect and participate. I realise this could be a bit of a pipe dream though given the amount of work it'll probably take to get off the ground full stop. Is there a published specification for the MS FS wire protocol ?? No. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Melchior FRANZ [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 6:34 AM Subject: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status * Norman Vine -- Thursday 06 November 2003 10:10: John Barrett writes: primary goal: blow them outa the sky !! FWIW Historicaly FlightGear has resisted being a Military SIM. (actually resisted is not a strong enough word) From the FAQ (http://www.flightgear.org/Docs/FAQ.shtml#7.4): | 7.4 - Is there support for any military scenarios like dog | fighting or bomb dropping? | | No, we do not currently support combat. Most of our developers | are primarily focused on civilian aviation. We aren't explicitly | excluding these features -- we just haven't had anyone who seriously | wanted to develop these areas. | | However, FlightGear does contain several military aircraft, albeit | without munitions. Doesn't sound like such a strong resistance. :- And I''m getting serious !! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
- Original Message - From: Erik Hofman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 7:35 AM Subject: Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status Melchior FRANZ wrote: * Norman Vine -- Thursday 06 November 2003 12:56: If you want to simulate combat please make it a separate project [...] I'm worried, though, that fighting capabilities could mean tradeoffs for the civilian simulation, which would certainly not be acceptable. As long as the whole thing would be a separate module (like WeatherCM) that can be compiled in or not, I'd not see much of a problem. Good thinking. Erik I see no problems here -- everything discussed so far impacts the current FG code only if you are involved with a server, and having an additional config option or three to control what gets compiled in is easy enough Lets see if I can run down the areas of impact: 1. keyboard/joystick event bindings for weapons 2. FDM integration for disposable stores and expendables -- useful even for civil aviation sims -- what happens if an engine falls off the pylon on a 747 ?? :) 3. HUD overlay for text messaging, GUI for radio messages -- needed in any case for ATC simulations, adding text to speech would be a plus :) 4. client and server protocol modules (can be configured in or out independently) -- in fact, totally possible to have the build process do two binaries at output -- one with server code, one without 5. aircraft specification modifications for weapons stores and damage effects (if you get hit in a specific location, what gets damage and how can that effect plane performance) 6. balistics and incremental aircraft damage system (non-guided weapons... wing cannon and bombs, falling aircraft parts [getting back to the 747 that drops an engine :) ], falling aircraft :) ) did I miss anything ?? Some of it is relevant to any simulation, the rest can be handled as optional modules, or is so low impact that its not worth making it optional (event bindings for instance) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Thu, 6 Nov 2003, John Barrett wrote: Seriously -- I'm more interested in WWII dogfight style combat -- guns/wing cannon, and dropped bombs only :) So we are really talking minimal changes for that type of combat. Plus it'd allow modelling of other interesting things - how about being able to practice your fire fighting skills? (actually, a horrible thought just occurred to me - imagine trying to model a helicopter with a water tank swinging about under it :-) How about being able to drop supplies from the back of a C130, or tow a glider (h winch launch anyone?), or many many other things that could be handled by the same code. The additional items fitted in/on aircraft don't have to go bang when they're released :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Plus it'd allow modelling of other interesting things - how about being able to practice your fire fighting skills? (actually, a horrible thought just occurred to me - imagine trying to model a helicopter with a water tank swinging about under it :-) That would be pretty cool. Just imagine the fun you could have with a 747 water bomber. :) Something needs to be done about the terrain though - it's too clean. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Jonathan Richards writes: On Thursday 06 Nov 2003 1:05 pm, David Luff wrote: The very very latest CVS (not the 0.9.3 release) can generate some situation-relevant messages from the tower to the user - if you'd like to participate in the ATC development then just shout, there's plenty to do! David - I was so enthused there, that I just started a checkout, having forgotten 'waiting for ehofman's lock'. Sounds like something from the canal era :¬) Maybe later... I haven't touched the base since 0.9.3 - from an ATC standpoint you just need to checkout the source and use 0.9.3 base. I think all the Flightgear source should be fine with 0.9.3 at the moment. Once you have the most up to date code, the current capability of the ATC/AI system can best be assessed by: 1/ Start at KEMT with comm 1 and 2 tuned to 121.2 and 125.9 respectively. Either stay where you are or fly LH circuits. This gives a good idea of the current state of ATC/AI and AI/user interaction. 2/ Fly to within about 8 miles of a controlled airport, tune to the tower frequency (I start at Nottingham, EGBN, takeoff South, and tune East Midlands tower on 124.0), press ' to bring up the ATC dialog, follow the reporting instructions, and report runway vacated when you're off it. Don't tune away from tower until you're done - it's not that robust! 3/ Contact East Midlands approach (119.65) from 10 - 20 miles out, and check out Alexander's initial stab at approach vectoring (bring up the dialog with ' again after tuning approach). 4/ Tune the ATIS in (just hit the standby - selected toggle on comm1 at the default startup) to hear the only audio currently available. I loaded up all the /ATC/*.cxx files into KDevelop this morning to see if I could understand how it all fits together, but rapidly got lost in the detail. Have you got a paragraph or two to hand which describes the architecture, for want of a better word? Hmmm, that almost sounds like a subtle insult ;-) Here goes a brief description - writing a proper description has been on my TODO list for a while, and would help me as well, so I'll try and come up with something more verbose in the next few weeks. The ATC manager, FGATCMgr (ATCmgr.[ch]xx), is the glue that holds it all together. One global instance of this is called from the main FG program each loop. The manager is responsible for deciding which ATC stations should be active based on user's position and tuned frequencies, calling the update functions of active ATC stations at a reasonable rate (it tries to spread the load and not call them all at once), reference counting voices, returning pointers to and frequencies of active ATC stations if reqd, and probably more that I can't think of. You don't want to spend too much time in ATCmgr if you value your sanity!! FGATCDisplay (ATCdisplay.[ch]xx) is a class for displaying ATC, AI and the user's radio transmissions if audio is not available or not desired. Once again, one global instance of this is called from FG each loop. FGVoice (ATCVoice.[ch]xx) is a class to encapsulate a canned voice for one ATC station and voice. The only one available currently is the default ATIS voice. FGATC (ATC.[ch]xx) is a base class for all the ATC stations. Most functions are virtual so the manager can just call update etc without knowing what type of class is being called. It also contains (or will contain) basic functionality to try to communicate at the right times, and to call the appropriate renderer for the output (Voice or text display). Various ATC types are derived from this: currently ground, tower, ATIS and approach. I intend to derive FGVectoredATC from FGATC and derive all the stations that need to vector traffic between waypoints (approach, center and departure) from that. The real messy nitty-gritty stuff is within these files. Others I can think of in the future include UNICOM, AWOS and ASOS. commlist.[ch]xx contains a class to hold details of the various ATC stations available (basically just a data store and lookup) - these are mapped by frequency and position (bucket) for quick lookup. transmission.[ch]xx and transmissionlist.[ch]xx were written by Alexander Kappes, I can't really give a description of them off the top of my head although I have hacked about at them a bit! They're to do with offloading the actual phraseology for various scenarios into config files that non-coders can modify, and which can potentially be varied according to country. FGAIMgr is analogous to FGATCMgr for the AI stuff. FGAIEntity and FGAIPlane are base and first derived class respectively for AI traffic. FGAILocalTraffic is a class that can taxi in and out and fly the traffic pattern. I intend to derive all AI VFR GA traffic from it so they can fly a pattern on arrival at an airport if necessary. If you're still enthused after plowing through that description and trying to reconcile it with the
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
I have an account with DMSO so access to HLA is not a problem, distributing it probably is ;) Database interface, what I would love to see would be a 'common' interface (base class maybe?) that the server sees (so it will have the basic get, put etc etc, the implementation of the actual db specific interface is then derived from this (maybe a design pattern would surfice?), this would allow any type of DB to be used at your leisure. I am not sure about combat, but what I would love to see is the number of ground vehicles (taxing and on the runway) change depending on the time of day Does Flightgear have a plugin type system? If not would that make a nice feature to add? Combat items such as guns could be a plugin? Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Plib-devel] Vertex Splitting, take two
Andy Ross [EMAIL PROTECTED] said: FWIW, I'd argue that exactly 45° is a very bad choice, since octagonal objects are going to be reasonably common in practice. Setting the smooth angle at exactly their corner angle means that any amount of modelling slop or round-off errors in such an object would cause some of the edges to be rounded and others not. I picked 46° hoping that this was enough to avoid such an effect. I think I originally had it at 52°, essentially playing the same game with 7-gons. But some of the planes looked a little too sharp, so I tuned it down some. I'd think that going from 46 to 52 would have the opposite effect, make the planes smoother. I might even go with 60 (6 sider). If the goal is to be 8 then even more slop than that might be good, just _under_ the next level like 50 or 51 (in other words put the margin for error just below the 7-gon rather than just above the 8-gon). Obviously there's no single value that will work for everything; I'd be happy to hear other opinions on good defaults. Guess my vote would be 60 (or 59). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
- Original Message - From: Gene Buckle [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Thursday, November 06, 2003 1:08 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status Plus it'd allow modelling of other interesting things - how about being able to practice your fire fighting skills? (actually, a horrible thought just occurred to me - imagine trying to model a helicopter with a water tank swinging about under it :-) That would be pretty cool. Just imagine the fun you could have with a 747 water bomber. :) Something needs to be done about the terrain though - it's too clean. g. Call that phase 4: Extending terrain data for low level and ground level sim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
That would be pretty cool. Just imagine the fun you could have with a 747 water bomber. :) Something needs to be done about the terrain though - it's too clean. g. Call that phase 4: Extending terrain data for low level and ground level sim Take a peek here for some great terrain modelling. This is also very low-poly stuff. http://www5.playnet.com/bv/wwiiol/movies.jsp g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
I now have cubes and cylinders of various colours moving around in the
flightgear world. Currently I specify a starting lon, lat and the roaming
distance in meters in either the lon, lat direction. I can have about 100
vehicles being updated 3 times a second each before my p4 1.4ghz really
begins to slow down (20fps). Currently the vehicles move in a rondom
direction at a randomly changing speed. The min and max speed limit is
expressed in km/h so accurate movement is not dependant on the number of
frames per second. I would like to say thanks to those that have helped
me so far.
The next step is to have the vehicles move down the real road networks
(stored in postgres using the postgis module) at
the proper speed limits. Before I do this I am trying to eek out better
performance. Here is my question:
Is it possible to determine if a vehicle is in the viewing area of the
plane using the lon, lat of the vehicle? If this is so I will be able to
eliminate large amounts of computation.
Seamus
On Tue, 4 Nov 2003, Seamus Thomas Carroll wrote:
Sorry,
I modified transform a bit and forgot to * pos.elev by SG_METER_TO_FEET.
I added that bit and models started viewing correctly. My comment was
regards to flight gear using feet when meters (to me) should be the unit
of choice internally. The international standard unit of length is meters
so I was caught off gaurd when feet showed itself.
Seamus
On Tue, 4 Nov 2003, David Luff wrote:
On 11/3/03 at 7:39 PM Seamus Thomas Carroll wrote:
I just found the bug. DoGroundElev obtains a value in meters but the
update in FGAIEntity expects a value in feet. I fixed the units and now
the models are viewing correctly. Does anyone know why the code needs to
feet and meters?
Hi Seamus,
I'm afraid I'm not at all sure what you mean! The AI system uses meters
internally, and FGAIEntity expects pos.elev() to be in meters. It is
converted to feet on the fly in FGAIEntity::Transform since that is what
SGModelPlacement requires :-( but as far as I know is maintained
consistently in meters internally:
void FGAIEntity::Transform() {
aip.setPosition(pos.lon(), pos.lat(), pos.elev() * SG_METER_TO_FEET);
aip.setOrientation(roll, pitch, hdg);
aip.update( globals-get_scenery()-get_center() );
}
where aip is an instance of SGModelPlacement.
If you could post the code that you think is wrong and your fix then I'll
have a look at it.
Cheers - Dave
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
John Barrett wrote: I see no problems here -- everything discussed so far impacts the current FG code only if you are involved with a server, and having an additional config option or three to control what gets compiled in is easy enough Lets see if I can run down the areas of impact: 1. keyboard/joystick event bindings for weapons 2. FDM integration for disposable stores and expendables -- useful even for civil aviation sims -- what happens if an engine falls off the pylon on a 747 ?? :) 3. HUD overlay for text messaging, GUI for radio messages -- needed in any case for ATC simulations, adding text to speech would be a plus :) 4. client and server protocol modules (can be configured in or out independently) -- in fact, totally possible to have the build process do two binaries at output -- one with server code, one without 5. aircraft specification modifications for weapons stores and damage effects (if you get hit in a specific location, what gets damage and how can that effect plane performance) 6. balistics and incremental aircraft damage system (non-guided weapons... wing cannon and bombs, falling aircraft parts [getting back to the 747 that drops an engine :) ], falling aircraft :) ) All of these could be implemented without them being exposed to the user. No configure option needed IMHO. The only thing that needs a configuration option is the actual armament release code. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Thursday 06 Nov 2003 8:13 pm, David Luff wrote: Jonathan Richards writes: I loaded up all the /ATC/*.cxx files into KDevelop this morning to see if I could understand how it all fits together, but rapidly got lost in the detail. Have you got a paragraph or two to hand which describes the architecture, for want of a better word? Hmmm, that almost sounds like a subtle insult ;-) Oh hell, no! I didn't mean to imply any criticism of the code. I'm not qualified to comment...[1] I bought Teach Yourself C++ in 21 Days, but more than 21 days ago. I still can't do much more than hazily understand other people's code :¬) Your explanation of what does what is just the ticket. I'll experiment. Regards Jonathan [1] In the Real World (tm) my job title is Systems Architect, but it always sounded a bit portentous, and now that I've seen The Matrix: Revolutions I think I'll get it changed! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Some thoughts and ideas (LONG)
Hi guys Intro == I've been watching the FlightGear project for the last 2-3 years and am interested in contributing to the project once I get a new video card. (TNT2 is just not cutting it) Flight Unlimited III is effectively dead and MSFS is continually dissapointing me because of the inability to get features added like proper support for vertical wind generation/modeling (themals, ridge, wave lift) Then there is the fact that I prefer using Linux and have done some C++ and OpenGL coding (terrain rendering with satellite image overlays) which was fun. I have several questions, suggestions and ideas so if you're in a hurry or the kids are screaming just hit delete. I've tried to be as brief and concise as I can be so please forgive me if I take up some of your development time. ;) Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. For instance there are several very talented guys on the Avsim Flight Unlimited III forum and some of them are looking at moving onto another sim. They have mentioned FlightGear as a candidate simply for the reason that it can be modified and changed to do whatever we want it to do. No restrictions on functionality. If we can at least get them interested using some showcase material then FlightGear development can get a major boost. There are plenty such developers around in other places. Suggestions == Suggestion 1 The menu systems could do with some major enhancments. A nice menu system for picking airports and aircraft, joystick configuration and key mappings would go down well. Getting everything menu driven will help a lot. Most people hate playing in shells passing huge lists of arguments to get what they want. Suggestion 2 --- We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Suggestion 3 --- Some nice showcase scenery would also go down very well. A nice area with lots of trees and buildings and good ground textures. Suggestion 4 --- We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. One way to do this is to incorporate a scenery edit mode into FlightGear like the one in FLY2. You pause the game and go into edit mode and can lay down trees and objects. Then hit unpause and fly around your creation. I personally think a seperate editor would be the answer since it won't interfere FlightGear development and one can add as many features as one likes. Questions == Question 1 Has there been any thought or development on auto generated scenery like that used in MSFS 2002/2004? i.e. Automatically generate trees and buildings based on land use data. The other alternative is to generate the 3D object positions when building the scenery packages. Flying over forests makes a world of difference when it comes to realism. Question 2 The site is a bit sparse with info about who is doing what. Has anyone writen a scenery editor yet? Question 3 What 3D formats and apps are used? I find Blender very powerful and of course it's open source and free which is great. Question 3 If I manage to get some nice high res DEM data available for a certain area how do I go about getting it built into the next release of FlightGear? Conclusion == By now you probably think that I'm an ungrateful idiot with a huge wish list. Fortunately that is not the case. Here is a list of
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Fri, 07 Nov 2003 02:22:54 +0200 Paul Surgeon [EMAIL PROTECTED] wrote: The menu systems could do with some major enhancments. A nice menu system for picking airports and aircraft, joystick configuration and key mappings would go down well. Getting everything menu driven will help a lot. Most people hate playing in shells passing huge lists of arguments to get what they want. FG Launch Control http://sourceforge.net/projects/fgrun/ is a standalone GUI app that does some of what you describe. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. One way to do this is to incorporate a scenery edit mode into FlightGear like the one in FLY2. You pause the game and go into edit mode and can lay down trees and objects. Then hit unpause and fly around your creation. I personally think a seperate editor would be the answer since it won't interfere FlightGear development and one can add as many features as one likes. FG Scenery Designer http://sourceforge.net/projects/fgsd/ is another standalone app that lets you modify scenery and place objects. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
Suggestion 2 --- We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. Well, I think the X-15 generally works pretty good, but I need to revisit it and finish off the things I've always meant to finish up. BTW : I took the Cessna 172 for a flip and was dissapointed. The At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Interesting. Can you give more specifics of your test? This is theoretically one of our most detailed flight models. Maybe you've found a rough edge. Can you give the command line you used to start this up, and which version did you use? Thanks (and welcome)! Jon Berndt Coordinator, JSBSim Project (a Flight Dynamics Model used in FlightGear) www.jsbsim.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
Seamus Thomas Carroll writes: Is it possible to determine if a vehicle is in the viewing area of the plane using the lon, lat of the vehicle? No FWIW Using a Lat Lon representation of your position is horribly inefficient So I recommend doing all your motion relative to a local plane then use a slightly modified HitList::fgCurrentElevation() to determine your actual contact point It's not really not that tough but there are a few wrinkles that you must internalize i.e. current tile center based world Note that the hitlist structure saves a pointer to the actual PLib Collection intersected and the index of the 'hit' triangle from which you can determine your new position. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. What release is it? The 172 changed a release or two ago. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Is that true? I've never taken a 172 that fast in real life, but they are very draggy. In fact, when someone in a slick gets into a spiral, one of the recommended emergency procedures is to drop the gear (which will then have to be inspected before further flight). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Some thoughts and ideas (LONG)
At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Is that true? I've never taken a 172 that fast in real life, but they are very draggy. In fact, when someone in a slick gets into a spiral, one of the recommended emergency procedures is to drop the gear (which will then have to be inspected before further flight). David I just tried the default Cessna 172-3D. It climbed out at 2500 rpm (engine rpm) and when I got to 1,500 feet I pushed the nose over to a 45 degree downward pitch and accelerated quickly past the redline and was still accelerating at 155 knots when I pulled up to avoid the obstacle in front of me (a looming planet). The recent release seems to work fine in the above-questioned regard. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
Can you direct me to where i can find HitList::fgCurrentElevation()? i have run grep on simgear and flightgear plus searched in google and I still cant find mention of this function. Seamus On Thu, 6 Nov 2003, Norman Vine wrote: Seamus Thomas Carroll writes: Is it possible to determine if a vehicle is in the viewing area of the plane using the lon, lat of the vehicle? No FWIW Using a Lat Lon representation of your position is horribly inefficient So I recommend doing all your motion relative to a local plane then use a slightly modified HitList::fgCurrentElevation() to determine your actual contact point It's not really not that tough but there are a few wrinkles that you must internalize i.e. current tile center based world Note that the hitlist structure saves a pointer to the actual PLib Collection intersected and the index of the 'hit' triangle from which you can determine your new position. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Friday, 7 November 2003 02:58, David Megginson wrote: What release is it? The 172 changed a release or two ago. 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) I would run it under Linux except that last time I couldn't maximize the screen without the FPS dropping to 1. Anyway it's not an issue - I haven't played around with all the models yet. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) That's pretty ancient. Our current 172 looks a fair bit better. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer RFC -- wire protocol spec -- preliminary
Here is a quick and dirty 1st cut at a wire protocol definition, and some requirements for the message handling classes that will implement the protocolPreliminary FlightGear Server (FGS) wire protocol specification 0xFFEscape prefix for 0xF? bytes in the data next byte is inverted, except for data type prefixes 0xFEBegin message, 8 bit message ID 0xFDBegin Message, 16 bit message ID CodeTypeC/C++ equivalent 0xF0byteunsigned char 0xF1wordunsigned int 0xF2dword unsigned long 0xF3qword unsigned long long 0xF4signed byte char 0xF5signed word int 0xF6signed dwordlong 0xF7signed qwordlong long 0xF832bit float float 0xF964bit doubledouble 0xFAundefined 0xFBundefined 0xFCstring, next byte is length char* unterminated binary data Unless there are objections, byte order is little endian, and floats are intel FPU standard (ok -- i'm making it easy on the PCs that will likely be used to run display clients :) Messages are constructed by sending a Begin Message byte, followed by the message ID, and then each data element.. clients/servers that dont understand a given message should be able to skip past to the next start of message marker. the FGSMessage base class will define an array of type/pointer that identifies the type, and location to store each element of a message. Derived classes will load this array with the correct associations for the specific message being sent or recieved. Recieved messages must have the same types in the same order or the message is rejected as invalid. All platform specific data conversion will happen in the FGSMessage base class during packing/unpacking of the message. Message objects derived from the FGSMessage base class will register with base class using static methods to establish a factory style instantiation mechanism such that an inbound message can be passed to a static method of FGSMessage, and the return value will be a pointer to an object of the correct message type. FGSMessage::recieve will be equally able to handle UDP packets with multiple messages, or TCP packets with partial messages, buffering message fragments until the next time the recieve method is called.___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some thoughts and ideas (LONG)
On Fri, 7 Nov 2003 11:46 am, [EMAIL PROTECTED] wrote: Preface == I would like to see the sim become more friendly to casual users especially on the eye candy side of things. This does not need to detract from the scientific/academic nature of FlightGear - you guys can carry on with the great work. My reason for this is that a lot of people who play with sims can also develop addons but there needs to be an incentive to get them involved and screenshots say more than a thousand words can. As a counterpoint, I would like to request that this either not take priority, or that it be an option in the configure stage. I want fast framerates as the priority. For me, this is a _flight_ sim and I don't see the point of eyecandy. ( Personally, I was disappointed with FS2002 and much preferred the playability of FS98. FS2002 devoted too much to eyecandy and was so obtuse in actually getting to the point where you were in the air and flying that I stopped using it. It took about five minutes of configuring various options before you could take off.) We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Most people using recent commercial flightsims are running 1.5 GHz PCs with at least 64MB GeForce 4's so poly counts can be fairly high. I disagree with this assessment. I think lower spec machines should be able to run a _flight_ sim and shouldn't be excluded just for the sake of eyecandy. I agree with the OP re terrain mapping. BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. I don't agree with this assessment. I think it is modelled quite well. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I know this may be anathema to some people, but I rarely use the external view and don't really care what the plane looks like from the outside.My priorities are: 1) accurate flight model; 2) high framerate; 3) accurate panel (in the sense the instruments do what they should, and that they are all represented, not in the sense that the panel looks like the real plane's panel). For example, there is a fault in the heading bug in some panels. If the DI is not slaved to the compass, the main HSI heading bug does not rotate with the change in direction and consequently, the heading bug never reaches the top of the card. It constantly rotates against the change in direction. Try the seahawk for an example. I'm not trying to rain on the OP's parade; I think he has some good ideas. It's just that I would prefer to see development take priority in the fields I am interested in, naturally enough. Nick, offering another viewpoint. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
