Re: [Flightgear-devel] fgrun - runtime error
Richard Hornby wrote: This may be one for Erik ... I am using FG 0.9.3 CVS version. I have compiled fltk and fgrun on SuSE8.2 and both seemed to go fine. I compiled both with --with-x and --with threads. On running fgrun I get the following message in the console linux:~ # fgrun X_DestroyWindow: BadWindow (invalid Window parameter) 0x2ac X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 and a gray (blank) window entitled FlightGear log (this leaves lines behind it when dragged). fgrun then hangs. To be honnest, I'm not very familiar with fltk. But searching the net for simillar errors doesn't provide a clue on what's happening. Mostly they say these messages are harmless ... This looks like an X-related problem? It does, but I can't think of a solution right now (except getting the latest XFree86, X-drivers and/or fltk). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett wrote: Hmm... perhaps the person who was thinking about puting some life on the ground might like to try shipping first as it might be easier than trying to follow roads;) Keep going -- lotsa other things that can be added :) One issue is consistency of display -- I would say making ship/vehicle positions determinstic based on time, so that all clients can use the server clock as a reference for controlling motion, and all the clients on a given server will see vehicles of this type at the same locations and with the same motions. SimGear provides random functions that give the same result on every platform provided they use the same seed and the same access order. That way we were able to synchronize the random objects across different displays in a multi-display system. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun - runtime error
On Mon, 10 Nov 2003 00:14:07 + Richard Hornby [EMAIL PROTECTED] wrote: This may be one for Erik ... I am using FG 0.9.3 CVS version. I have compiled fltk and fgrun on SuSE8.2 and both seemed to go fine. I compiled both with --with-x and --with threads. You don't need to specify --with-x since it is the default. fgrun doesn't have a --with-threads option. fltk-1.1 has a --enable-threads option but I've never used it. I suggest you don't either. On running fgrun I get the following message in the console linux:~ # fgrun X_DestroyWindow: BadWindow (invalid Window parameter) 0x2ac X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 and a gray (blank) window entitled FlightGear log (this leaves lines behind it when dragged). fgrun then hangs. This looks like an X-related problem? fltk comes with several programs in the test directory. Try some of those to check your installation. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett wrote: headless would be without any graphical display at all multiplayer does multiple planes in the scene, but expects the controlling logic for all but the local plane (none in the case of headless) to be handled by processes over the network I would VERY much like to see the ability to have a plane instance not attached to an OpenGL scene updating at a set frequency (for AI driven planes at the server, rather than at the client) -- This basically asks for an autopilot only FDM. It might be worth a few minutes of programming to extend the NULL FDM with autopilot functionallity. given that, having the plane able also to attach to an existing scene would achieve the 1st half of your requirements (attach as many planes as you like), then the input routines would need to be isolated from a specific plane instance, and made able to attach to any locally running plane instance via a menu for starters, we would need: 1. local plane instances that can operate with or without a local OpenGL scene, optionally with PSL scripting for AI This is done in the ATC code of David Luff. 2. keyboard/mouse/joystick interface isolated from the plane instance, with the ability to attach to any local plane instance (i.e. you could detatch from all planes and only the menus would be active, or you could be attached) This doesn't sound too difficult either. What this gets us: 1. a running FGFS instance can have multiple planes without multiplayer, with the planes scripted if desired to play out a scenario (civilian scenario: cope with a plane invading your airspace while on approach/combat scenario: obviously :) blow them outa the sky :) ) 2. running headless connected to a multiplayer server, the FGFS instance can handle multiple AI driven planes in the world on behalf of the server, creating a distributed server environment for larger simulations (would take a little tweaking of the multiplayer code to cope with multiple plane instances at the client, but very possible, and quite desirable IMO) I'm not sure I like the idea of FlightGear set up as a server. This will however keeps the code between the server and the client as close as possible. Are any of these abilities in the current code, or how much work are we looking at to make it work this way ?? There already is an option to disable out of the window view which is used for the c172-610x/panel only aircraft, but this one still displays the panel. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Multiplayer Server RFC -- Current Status
Cameron Moore [EMAIL PROTECTED] wrote: In case you are misunderstanding what I am talking about, let me clarify. Noone (that I know of) is opposed to multiplayer/multipilot capabilities being in FG. Absolutely correct ! [...] What we are debating is combat -- ie. modelling projectiles such as bombs, bullets, [...] and collisions. You should keep collisions in mind in case you intend to run 'combat' and 'non-combat' on a single server (or on distributed and connected servers), 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
John Barrett [EMAIL PROTECTED] wrote: What this gets us: [...] 2. running headless connected to a multiplayer server, the FGFS instance can handle multiple AI driven planes in the world on behalf of the server, creating a distributed server environment for larger simulations [...] I'd like to plug a possible scenario here that didn't get mentioned yet: People running FGFS on a machine without direct internet connection, no masquerading, not port-forwarding. These people read their web-pages via Squid and get their EMail from a local mail- gateway. These people would me delighted to see the FG server function as a proxy on their internet gateway - also a scenario that would fall under distributed server environment. Just as a side note 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
[Flightgear-devel] SimGear/matlib.cxx: problem with gcc-3.3 and PowerPC
On a PowerPC platform (iMac) the gnu compiler gcc-3.3 (from Xcode) creates a bad object file when optimisation are turned on. This causes FlightGear to crash at startup. There is no problem when optimisations are off (-O0) for this file. I didn't found such a problem on another file. Olivier A. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Static objects in scenery and performance
I have an Apple iMac (G3 500 MHz - 384 Mb RAM, with ATI Rage pro 128 - 16 Mb). Turning on static objects in the scenery decreases a lot the frames per second rate (about a 33% penalty!) whereas random objects (trees, small buildings, ...) are rather fast to render: There is only a 10% or less penalty on the fps rate. Why there is such a difference ? It's frustating because the SF area is so nice, especially the Golden Bridge! But on my iMac, the fps rate goes down to about 2-3! (at KFSO, on the runway, fps is about 10 without objects, about 9 with random objects, about 6 with all the default behavior. It increases to 45 fps above the sea.) Olivier A. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear/matlib.cxx: problem with gcc-3.3 and PowerPC
On 10 Nov 2003, at 13:38, Olivier ABILLON wrote: On a PowerPC platform (iMac) the gnu compiler gcc-3.3 (from Xcode) creates a bad object file when optimisation are turned on. This causes FlightGear to crash at startup. There is no problem when optimisations are off (-O0) for this file. I didn't found such a problem on another file. That explains a lot . can we do a #pragma optimization level 0 in the file, or is it only CodeWarrior that supports such options? HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear/matlib.cxx: problem with gcc-3.3 and
Olivier ABILLON [EMAIL PROTECTED] wrote: On a PowerPC platform (iMac) the gnu compiler gcc-3.3 (from Xcode) creates a bad object file when optimisation are turned on. Ah, I got some broken binaries on RS6k/AIX-5.1 using GCC and '-O3' '-O1' should work on most platforms - at least it does for the platforms _I_ use, 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] Static objects in scenery and performance
Olivier ABILLON writes: Turning on static objects in the scenery decreases a lot the frames per second rate (about a 33% penalty!) whereas random objects (trees, small buildings, ...) are rather fast to render: There is only a 10% or less penalty on the fps rate. Why there is such a difference ? I designed the random objects small -- tiny textures, only a few polys each. They look fine up to 1000m away, which is as close as most users usually get. It's frustating because the SF area is so nice, especially the Golden Bridge! But on my iMac, the fps rate goes down to about 2-3! There's your answer. Big textures and hundreds or thousands of polys look great, but really hurt the system. We need to make sure that we're displaying static 3D models with, at most, a few dozen triangles each (and even that only for the most famous buildings) unless the viewpoint is very, very close. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Jon Berndt [EMAIL PROTECTED] said: I would propose that the server be structured so that a purely civilian/non-combat version could be run. I don't want it to be possible for some idiot to come and blow me out of the sky when I'm practicing ILS approaches in my C172 at my local airport. I guess there ought to be an explicit flag the user can set at startup stating whether or not they want to be seen or not. THe default would be invisible. When thinking about the design of such things, it would be good to consider what kind of separation we can keep between the military/combat features and the rest of the core simulation. Are there *analogues* to combat that could be made an enjoyable and ethically acceptable part of FlightGear such that those who wanted simulated combat training or historical battle reenactments to be present could make them be present? An earlier thread mentioned some other things including a Reno race course based game. That would be very interesting. I tend to be in the non-weapons camp. There may be some (not myself) who find it offensive to even have source code included that discusses in weapon terms, so it might be wise to bring up an RFC thread on that when the time comes. It seems to me that generic the FDM and AI functions that have been discussed here could serve as an underlying layer for the type of things that both John and Lee mentioned. Perhaps these specific applications like a Reno race game, search and rescue, and combat features could be handled as seperate pluginable projects that run on top of a multi user simulation layer that has all the capabilities including Jon Berndt's child FDM concept. 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: Erik Hofman [EMAIL PROTECTED] I'm not sure I like the idea of FlightGear set up as a server. This will however keeps the code between the server and the client as close as possible. I felt there were too many instances where the current simulation code would be highly useful for a server (which could have been handled with a seperate executable linking what was needed), but the ability to have a running FG instance be a server for a small group of flyers (load up and fly with a few friends) without having to have a dedicated server made integrating the server worth while. Are any of these abilities in the current code, or how much work are we looking at to make it work this way ?? There already is an option to disable out of the window view which is used for the c172-610x/panel only aircraft, but this one still displays the panel. Doesn't sound like we have far to go, or that its going to take major architectural changes to make any of it happen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Static objects in scenery and performance
David Megginson [EMAIL PROTECTED] said: There's your answer. Big textures and hundreds or thousands of polys look great, but really hurt the system. We need to make sure that we're displaying static 3D models with, at most, a few dozen triangles each (and even that only for the most famous buildings) unless the viewpoint is very, very close. It might be interesting to incorporate some ability to scale textures dynamically, based on a property. This seems to be what MSFS does. I think their parameter has about 6 or so levels (small texture to large texture). It could be configurable for just aircraft, ground cover, static objects or all three. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle [EMAIL PROTECTED] said: it offensive to even have source code included that discusses in weapon terms, To me this is absurd to the extreme. To you maybe. This may not be the proper forum for you to be asserting judgements like that anyway (see alt.politics.*) :-D And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
it offensive to even have source code included that discusses in weapon terms, To me this is absurd to the extreme. To you maybe. This may not be the proper forum for you to be asserting judgements like that anyway (see alt.politics.*) :-D ...with cross-posts to alt.save.da.fwuffy.bunny and alt.wesley.crusher.die.die.die. :) And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. I read the whole post. Really! :) I guess my problem is that I'm totally unable to understand why someone would object to just the _presense_ of munitions code even being present. It completely baffles me. Even as I sit here pondering the why, all I can come up with is pejorative commentary and that's unfortunate. BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one if its kind. ___ 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: Monday, November 10, 2003 2:14 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status it offensive to even have source code included that discusses in weapon terms, To me this is absurd to the extreme. To you maybe. This may not be the proper forum for you to be asserting judgements like that anyway (see alt.politics.*) :-D ...with cross-posts to alt.save.da.fwuffy.bunny and alt.wesley.crusher.die.die.die. :) And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. I read the whole post. Really! :) I guess my problem is that I'm totally unable to understand why someone would object to just the _presense_ of munitions code even being present. It completely baffles me. Even as I sit here pondering the why, all I can come up with is pejorative commentary and that's unfortunate. Same here -- I deleted the post before sending it -- tolerance and understanding of others ideas is what makes a community -- I've tried to do that by consenting to add code for strictly non-combat simulations -- I hope for the same from the non-combat folks about the combat code -- I'll leave it at that BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. Lets make their day !!! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 21:14, Gene Buckle wrote: BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. I like the idea of FlightGear being able to support military type stuff but where do we draw the line? If there is too much military specific code hooking into core parts of FG then it could get messy and even slow things down both framerate wise and development wise. There are so many things that are specific to aircraft like the F16 that require more than just an instrument display. For instance ground radar and FLIR systems. Being able to acquire and lock onto ground targets has nothing to do with general aviation but is absolutely necessary for military simulations. That means there would have to be an interface between the panel system and terrain rendering system. We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. One could go a step further and reason that FlightGear should support space simulation as well. (probably not that hard considering that FG simulates the celestial bodies pretty well) Take that far enough and we'll soon have lunar rovers and ... and ... and ... What is the chief goal/aim of FG? I thought it was trying to simulate just general and commercial aviation. However having said that I would love an F16 multiplayer simulation. :) BUT not at the expense of general aviation. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: I guess my problem is that I'm totally unable to understand why someone would object to just the _presense_ of munitions code even being present. It completely baffles me. Even as I sit here pondering the why, all I can come up with is pejorative commentary and that's unfortunate. I should just stay out of this, but let me just say one thing. I don't think the problem is so much the presence of virtual guns and virtual shooting. Most of us have played our share of video games over the years and starting with the Apple ][+ I've blown away more than my share of virtual bad guys. I think the problem is more that FlightGear could (or in a few small cases is/was) being used by companies in conjunction with developing military sims or developing things in support of military sims. Note I'm not saying that flightgear is being used in a full, all out military combat training setting ... I'm not aware of that being true. But as we move forward, the Flightgear structure is just as attractive to companies with military contracts as it is to companies with purely civilian goals. Personally, I don't think there's any way around that. I could be a bread maker and some of that bread could be fed to combat troops fighting for some cause I don't necessarily agree with. Does that mean I stop making bread altogether? The US military found that condoms were immensely useful for keeping sand out of their rifles in Iraq. They sent over truckfulls of condoms. Does that mean we should stop producing condoms? I'm guessing there are probably a lot of opinions on that subject, few having anything to do with the military applications. I think people have to weigh the pros and cons and ultimately make a decision based on their best conscience, and we need to in turn respect that. But FlightGear is open-source and licensed under the terms of the GPL, so anyone who abides by our terms is free to use it. That's part of the nature of a free society I guess. Personally, I think that if a person is opposed to war (which I believe is a reasonable position in most cases) they can probably find a lot more effective things to further there cause besides abandoning FlightGear. And I should say that personally, my focus for FlightGear is accurate, realistic, FAA certifiable civilian training simulators. I'll generally oppose anything that takes away from that, and generally be as flexible as possible for other people to achieve thier various goals within the FlightGear framework. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: I read the whole post. Really! :) Hey Gene since I am the one who initially brought up the issue I guess you are the one responsible for my ears burning :-) However note I never objected to the presence of munitions in FlightGear. http://baron.flightgear.org/pipermail/flightgear-devel/2003-November/022301.html http://baron.flightgear.org/pipermail/flightgear-devel/2003-November/022310.html What I *was* objecting to and *will* continue to object to is a 'primary goal' of 'blow them out of the sky' and any attempts at turning the goal of FGFS into such !! Since FGFS is OpenSource with many parts designed to be library components it shoudn't be too hard for anyone wanting such a system to build it on top of FGFS. If there is 'dual use' code that would be useful in a general purpose SIM then it is probably better placed in FGFS then in another project but IMO any 'shoot em up' should be in another project as there is little to be gained from having it in FGFS and ptentially at least a lot to lose. Also please note our goals are succintly stated on our home page actually the introduction page now The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application Granted some may see Combat and Gaming as falling under 'other interesting' or 'sophisticated' flight simulation but that's a mighty *big* stretch in my book :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 21:14, Gene Buckle wrote: BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. I like the idea of FlightGear being able to support military type stuff but where do we draw the line? If there is too much military specific code hooking into core parts of FG then it could get messy and even slow things down both framerate wise and development wise. Understood. The only feature that I can think of that cannot be an external plug-in is collision detection. There are so many things that are specific to aircraft like the F16 that require more than just an instrument display. For instance ground radar and FLIR systems. Being able to acquire and lock onto ground targets has nothing to do with general aviation but is absolutely necessary for military simulations. That means there would have to be an interface between the panel system and terrain rendering system. This can be made a plug-in that uses the same terrain data that FG is using. All the code that is the FLIR (or LANTIRN, or LITENING II, etc) could (and should!) be implemented as an external plug in. If it's executing on the same host as the simulation, it would need write permission to the main frame buffer to allow its display to be shown. This same method could apply to a glass flight director or ADI, engine displays, etc. A plug-in system like that would be a universal technology that could be applied to both military and civilian/commercial systems. We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. *eyes glaze over* Oooh. *wistful sigh* One could go a step further and reason that FlightGear should support space simulation as well. (probably not that hard considering that FG simulates the celestial bodies pretty well) Take that far enough and we'll soon have lunar rovers and ... and ... and ... YES! What is the chief goal/aim of FG? I thought it was trying to simulate just general and commercial aviation. However having said that I would love an F16 multiplayer simulation. :) BUT not at the expense of general aviation. Of course not. The two genres can live together quite well as long as there are not any squabbling about the glue points between the two worlds. Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* g. -- Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ 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: Monday, November 10, 2003 3:40 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Monday, 10 November 2003 21:14, Gene Buckle wrote: BTW, I know a group of virtual F-16 drivers that would practically wet themselves over software they could use to drive their cockpits with. :) Falcon 4.0 doesn't go far enough with their data exports. I like the idea of FlightGear being able to support military type stuff but where do we draw the line? If there is too much military specific code hooking into core parts of FG then it could get messy and even slow things down both framerate wise and development wise. Understood. The only feature that I can think of that cannot be an external plug-in is collision detection. There are so many things that are specific to aircraft like the F16 that require more than just an instrument display. For instance ground radar and FLIR systems. Being able to acquire and lock onto ground targets has nothing to do with general aviation but is absolutely necessary for military simulations. That means there would have to be an interface between the panel system and terrain rendering system. This can be made a plug-in that uses the same terrain data that FG is using. All the code that is the FLIR (or LANTIRN, or LITENING II, etc) could (and should!) be implemented as an external plug in. If it's executing on the same host as the simulation, it would need write permission to the main frame buffer to allow its display to be shown. This same method could apply to a glatss flight director or ADI, engine displays, etc. A plug-in system like that would be a universal technology that could be applied to both military and civilian/commercial systems. I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc We could also add some sort of online, persistent, dynamic, war engine for multiplayer missions. *eyes glaze over* Oooh. *wistful sigh* Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) One could go a step further and reason that FlightGear should support space simulation as well. (probably not that hard considering that FG simulates the celestial bodies pretty well) Take that far enough and we'll soon have lunar rovers and ... and ... and ... YES! MORE MORE MORE :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Hey Gene since I am the one who initially brought up the issue I guess you are the one responsible for my ears burning :-) Wasn't me. I'd chase down the guy with the matches. :) What I *was* objecting to and *will* continue to object to is a 'primary goal' of 'blow them out of the sky' and any attempts at turning the goal of FGFS into such !! We both agree on this. My only concern is the blocking of shared technologies from the source repository simply because it's used by other portions to support combat features that are not practically implementable as a plug-in. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) Persistant world period. The benefits would be just too phenomenal to think about, especially from the just-wanna-have-fun user end of this thing. Here's a scenario for ya: User connects up, and picks where they want to fly from and what class of aircraft they want to fly. They're then deposited in the FBO, terminal building or AFB hangar on the field they're going to fly from. They could then pick what they wanted to fly by menu, _or_ by walking outside and picking the plane they wanted from a selection of them parked on the ramp. All the while seeing AI and real traffic above them and other users wandering around on the ground with them. Makes me all squishy-headed just thinking about the possibilities. *sigh* MORE MORE MORE :) NOW NOW NOW! :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 22:40, Gene Buckle wrote: Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* Not sure if you're just kidding or serious ... There's plenty of free C++ info online but here are a couple of free books : Bruce Eckel's Thinking in C++, 2nd Edition http://www.mindview.net/Books/DownloadSites If you're programming on the Linux platform Advanced Linux Programming (threads, processes, IPC, etc) http://www.advancedlinuxprogramming.com/downloads.html Good sites with links : http://www.thefreecountry.com/documentation/onlinecpp.shtml http://www.cprogramming.com http://cpp-home.com/tutorials/ excellent tutorials for n00bs to pro I'm not a very good C++ programmer and I keep forgetting stuff so I'm forever referring back to my library of downloaded tutorials, books, etc. Maybe I'm not the only one. :) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* Not sure if you're just kidding or serious ... There's plenty of free C++ info online but here are a couple of free books : Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) http://cpp-home.com/tutorials/ excellent tutorials for n00bs to pro This looks like what I'm after. Thanks! I'm not a very good C++ programmer and I keep forgetting stuff so I'm forever referring back to my library of downloaded tutorials, books, etc. Maybe I'm not the only one. :) Do you know of a small paper quick reference that's any good? g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle writes: Anyone know of a good C++ tutorial? :) Something tells me I'm gonna need it. *g* Not sure if you're just kidding or serious ... There's plenty of free C++ info online but here are a couple of free books : Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) Sounds like you need a varient of the following t-shirt (credit to Mark Barry.) http://www.markbarry.com/pictures/bombtech.jpg Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Monday, 10 November 2003 23:40, Gene Buckle wrote: Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) I also come from a Delphi background but find the switch very easy. Both support OOP. Both support pointers (C++ does it MUCH more easily BTW) Both use similar language structures (just slight syntax differences) Why does C++ scare you? Do you know of a small paper quick reference that's any good? A reference for the C++ language syntax or for C++ libraries? C++ apps tend to use many different libraries so you really need documentation for each of them. I use glibc docs, libstdc++ docs, opengl docs, etc and then if I can't find anything I search the library source code for key words. :) If you manage to find an all-in-one let me know! Paul ___ 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: Monday, November 10, 2003 4:29 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status I think a dynamic shared library system that lets an a/c load up a module of its particular code when it is loaded needs to be added to the system -- be a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events Give me a LITTLE time to get the basics online :) (Or a persistent dynamic civilian world -- hehehe read in airline flight schedules daily) Persistant world period. The benefits would be just too phenomenal to think about, especially from the just-wanna-have-fun user end of this thing. Here's a scenario for ya: User connects up, and picks where they want to fly from and what class of aircraft they want to fly. They're then deposited in the FBO, terminal building or AFB hangar on the field they're going to fly from. They could then pick what they wanted to fly by menu, _or_ by walking outside and picking the plane they wanted from a selection of them parked on the ramp. All the while seeing AI and real traffic above them and other users wandering around on the ground with them. Makes me all squishy-headed just thinking about the possibilities. *sigh* MORE MORE MORE :) NOW NOW NOW! :) g. ___ 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] Multiplayer Server RFC -- Current Status
Thanks Paul. I pay my mortage with Delphi, VB Pick. My C/C++ skills are just enough to be able to identify it on sight and begin running the other way. :) Sounds like you need a varient of the following t-shirt (credit to Mark Barry.) http://www.markbarry.com/pictures/bombtech.jpg Yep, pretty much. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 7, Issue 34
Message: 2 Date: Mon, 10 Nov 2003 16:07:15 +1100 From: Michael Matkovic [EMAIL PROTECTED] Subject: [Flightgear-devel] Multiplayer Server RFC -- Current Status To: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed Could you describe the --headless option (Phase 1 changes)? Sounds a little like what I'm trying to get Flightgear to do. / /I was hoping to have multiple airplanes (each controlled by an individual program), each being updated once per video render instead of having independent execution frequency. Using version 0.9.2's multiplay option, I can get a number of planes visible but the 'once per video render' update still needs some work. Til now I've been viewing the group of planes from one of the players' views. I'm not sure if this idea can be done, but (considering what I'm trying to do) is it possible to have flightgear toggle between each player's view? For instance, starting up several 'players' but only having one screen... and being able to switch between each player's view. Sounds like a weird idea? maybe I should back on the coffee :-P thanks, Mick. -- Message: 3 Date: Mon, 10 Nov 2003 00:47:27 -0500 From: John Barrett [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status To: FlightGear developers discussions [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 - Original Message - From: Michael Matkovic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 10, 2003 12:07 AM Subject: [Flightgear-devel] Multiplayer Server RFC -- Current Status Could you describe the --headless option (Phase 1 changes)? Sounds a little like what I'm trying to get Flightgear to do. / /I was hoping to have multiple airplanes (each controlled by an individual program), each being updated once per video render instead of having independent execution frequency. Using version 0.9.2's multiplay option, I can get a number of planes visible but the 'once per video render' update still needs some work. Til now I've been viewing the group of planes from one of the players' views. I'm not sure if this idea can be done, but (considering what I'm trying to do) is it possible to have flightgear toggle between each player's view? For instance, starting up several 'players' but only having one screen... and being able to switch between each player's view. Sounds like a weird idea? maybe I should back on the coffee :-P headless would be without any graphical display at all multiplayer does multiple planes in the scene, but expects the controlling logic for all but the local plane (none in the case of headless) to be handled by processes over the network I would VERY much like to see the ability to have a plane instance not attached to an OpenGL scene updating at a set frequency (for AI driven planes at the server, rather than at the client) -- given that, having the plane able also to attach to an existing scene would achieve the 1st half of your requirements (attach as many planes as you like), then the input routines would need to be isolated from a specific plane instance, and made able to attach to any locally running plane instance via a menu for starters, we would need: 1. local plane instances that can operate with or without a local OpenGL scene, optionally with PSL scripting for AI 2. keyboard/mouse/joystick interface isolated from the plane instance, with the ability to attach to any local plane instance (i.e. you could detatch from all planes and only the menus would be active, or you could be attached) What this gets us: 1. a running FGFS instance can have multiple planes without multiplayer, with the planes scripted if desired to play out a scenario (civilian scenario: cope with a plane invading your airspace while on approach/combat scenario: obviously :) blow them outa the sky :) ) 2. running headless connected to a multiplayer server, the FGFS instance can handle multiple AI driven planes in the world on behalf of the server, creating a distributed server environment for larger simulations (would take a little tweaking of the multiplayer code to cope with multiple plane instances at the client, but very possible, and quite desirable IMO) Are any of these abilities in the current code, or how much work are we looking at to make it work this way ?? -- At the moment, the mods to our FlightGear include our own protocol which freezes execution until a socket connection is established. Once the external controller code connects, FlightGear starts up the simulation. This works great for a single plane. Its also works for two using --multiplay. Only problem is, I have to start up 1 FlightGear session per plane. With the two planes on screen (running identical code / settings), one of them would fly
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I also come from a Delphi background but find the switch very easy. Great! I'll help you write the server in Delphi. We can cross compile with FPC. *laughs* Why does C++ scare you? Well scare is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. The last time I tried getting my feet wet in code here got me bitched out by the plib author for basically not doing something his way. Instead of giving him precise and graphic instructions about what he could do with his way, I dropped it and walked away. These days I'd be just as likely to have verbally shot his high horse out from under him and beat him stupid with the corpse. :) I never have taken well to unhelpful criticism(sp!) Do you know of a small paper quick reference that's any good? A reference for the C++ language syntax or for C++ libraries? Just a syntax ref would be nice. O'Reilly makes a neat one for PHP but I don't know about any C++ offering they have. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C++ question...
I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. I would think the above would be functionally different than: limit_value (double *value, const SGPropertyNode *arg) I think of the multiplication operator when I see whitespace after the *, but I know(for small values of know) that if it were really parsed as trying to multiply a variable by a variable type, the parser would throw a fit. Why the extra whitespace in the declaration? g. ___ 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: Monday, November 10, 2003 5:37 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status a nice place to stick information unique to that plane that is dynamic in nature -- can handle specialized panel displays, hud, etc In that case, some kind of framework should be built so that the plug-in could run on a seperate machine if needed. um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
On Tuesday, 11 November 2003 00:47, Gene Buckle wrote: I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. C syntax : type *p C++ syntax : type* p The compiler doesn't care which you use. They both mean the same thing. Why the extra whitespace in the declaration? Cause some developer felt like coding that way. (I don't like his/her style but it's still valid) The compiler knows that it's not multiplication because it is a type declaration. Remove the type and it would mean multiplication. The same rule applies to multiplying integer/floating point variables. a* b = a *b = a * b The compiler knows the difference between variables and types. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
Thanks for the clue Paul. :) g. On Tue, 11 Nov 2003, Paul Surgeon wrote: On Tuesday, 11 November 2003 00:47, Gene Buckle wrote: I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. C syntax : type *p C++ syntax : type* p The compiler doesn't care which you use. They both mean the same thing. Why the extra whitespace in the declaration? Cause some developer felt like coding that way. (I don't like his/her style but it's still valid) The compiler knows that it's not multiplication because it is a type declaration. Remove the type and it would mean multiplication. The same rule applies to multiplying integer/floating point variables. a* b = a *b = a * b The compiler knows the difference between variables and types. Paul ___ 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] Multiplayer Server RFC -- Current Status
um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
On 11/10/03 at 2:47 PM Gene Buckle wrote: I see code like this: limit_value (double * value, const SGPropertyNode * arg) .and wonder about the placement of the pointer operator. I would think the above would be functionally different than: limit_value (double *value, const SGPropertyNode *arg) I think of the multiplication operator when I see whitespace after the *, but I know(for small values of know) that if it were really parsed as trying to multiply a variable by a variable type, the parser would throw a fit. Why the extra whitespace in the declaration? The extra whitespace is irrelevent. Personally I prefer int* ip; since I like to think of ip as an int-pointer. Kernighan and Richie specifically say in The C Programming Language though that they like to write int *ip; since it reinforces the point that dereferencing ip (*ip) gives an int. Cheers - Dave ___ 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: Monday, November 10, 2003 6:19 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status um ?? for code/data local to an a/c instance ?? remoting that would slow down the response time to realtime events For virtual cockpits, you're correct. however, when you're working with a physical cockpit, you need to have your displays on separate physical hardware. If the simulation reacts within 150ms of the real thing, you're still good for Class D anyway. 150ms is an eternity for most computers. Even on a 10BaseT network you should be ok whoa whoa whoa !!! thats more slaving the kb/mouse/stick inputs to an exterernal source, and feeding out info that would normally drive the panel/hud -- arent there native_ctrls/native_fdm/native_gui that handle that ?? (though I would be much happier seeing that handled completely seperate from any network multiplayer -- i.e. a plugin cockpit i/o module, as you could have a physical cockpit sim driven by FG hooked into a network multiplayer server) I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) I'm only guestimating based on the filenames :) Now -- how much does one of these physical cockpits cost ?? I want one for the basement :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ question...
Personally I prefer
int* ip;
That would turn me into a gibbering idiot. :)
Kernighan and Richie specifically say in The C Programming Language though
that they like to write
int *ip;
since it reinforces the point that dereferencing ip (*ip) gives an int.
Now THAT makes sense. You have to understand though, the last time I
wrote anything serious in C, the only way to define functions was this:
main(argc, argv)
int *argc;
char **argv;
{
}
...note that it's been *years* since I had more than a passing
accquaintance(sp) with main() so I probably got the parameters
backwards...
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
I'm just getting back into rooting around in the code and I don't yet have a solid grasp on all the parts. AFAIK, the only native support for an external module is OpenGC from what I've seen so far. I was referring the creation of a universal method of obtaining data from the sim via network - but only if such a mechanism doesn't already exist. If it does, point me to it and I'll go away. :) I'm only guestimating based on the filenames :) Well I feel like a total idiot right now. Everything I'm thinking about that needs to be done has already had the core done. *slaps forehead* The entire groundwork has been laid by the contents of the src/Network directory. The work done for OpenGC stands as a great example of building an external plug-in. I suspect that generic.cxx defines a method of building an interface via an XML configuration file, but I need to study (and understand!) it further. Is there anything that uses this generic interface? I'd like to see an example of the XML it reads if possible... I think that for non-visual systems, you could have sub-assembly programs running that all talk to FG via the already present network layer. Since it's basically localhost stuff, it should be as fast as it would ever need to be. Is that a valid assumption? Now -- how much does one of these physical cockpits cost ?? I want one for the basement :) The correct answer is How much you got? :) In all seriousness, you can spend as little or as much as you'd like. A first place to stop is http://www.simpits.org and join the mailing list. We're always happy to see a new vic^H^H^Hhobbiest join our little group. There are examples from my F-15C, to scratch build F-16s and a home-made 777. A recent discussion on rivets was started by pics of a new guys' Vultee Vulture, a fictious WWII era airplane named for the Vultee logo that is on the rudder pedals he's using. (The seat came out of a BT-13) g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Combat anti-flame
[Starting a new thread, since the original is getting a little strung out. :)] In an attempt to depoliticize the combat flame war as much as possible, it's worth pointing out that, irrespective of people's opinions on the matter, there are not a lot of combat features we can really avoid implementing: + A missile is just another aircraft with (perhaps) a variant FDM configuration. Ditto for a bomb. + A collision is a collision, be it with a guided missile, a partner in your close formation flight, or the tanker from which you are refueling. + Hydraulic/control system failures (or whatever) don't behave differently depending on whether the leak was caused by wear or a shell fragment. Overstressed civilian aircraft have been known to shed ailerons, wings, or tails on occasion. I'm sure others can come up with many more examples. Here are the only three combat only features I can actually think of which will require code or features we don't already have: + Weapon damage code. The system failures themselves can already be modeles (or will need to be at some point for civilian simulation). But computing how much failure results from a given event is something that will need to know about what a warhead is and how it differs from a bullet. + Gun trajectory modelling. Even this could *almost* be done with generic collision code by treating each shell as a separte object with its own FDM (do the math -- there aren't that many shells on an airplane, and computers are mind bogglingly fast these days). But still, the simplest gun implementation is going to be doing gun-specific stuff. + Missile homing code. This could easily be plugged into a generic autopilot framework, of course. But other than the framework boilerplate, this isn't likely to share code with any civilian autopilot implementations. :) Beyond that, all the combat stuff I can think of is going to be server-side functionality. Stuff like radar coverage handling, battlefield AI, etc... is all handled more cleanly by a separate, shared server application. Hopefully this will help to push the flames down until someone actually submits code to flame over. FWIW, I'm a mild, civically minded democrat and peacenik. I still enjoy the occasional dogfight; I've even been known to play Quake. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Combat anti-flame
Andy Ross writes: In an attempt to depoliticize the combat flame war as much as possible, it's worth pointing out that, irrespective of people's opinions on the matter, there are not a lot of combat features we can really avoid implementing: I've been deleting the combat thread unread, but I got the impression that there was a lot of heated discussion about military stuff. I'd hate to see FlightGear become nothing more than another shoot-em-up game, but I think we've already gone too far for that to happen. I also (personally) think we're a little heavy on the warbirds (especially U.S.) and would like to see more civilian aircraft, but I'm too lazy to get off my behind and make them, so I guess I don't have a right to complain. Otherwise, please wake me up when the discussion is over. All the best, David (peaceful but non-dogmatic Canadian) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle [EMAIL PROTECTED] said: And in case someone didn't read my earlier post, I do not hold this opinion myself, but I do think that a topical RFC should be posted before any war related code is committed, even with a configuration flag. This _is_ a hot button whether anyone thinks it should be or not. I read the whole post. Really! :) I know you did :-) That was just a repeat for the benefit of others. Most everyting that has been discussed in this thread sounds very interesting. I am eagerly awaiting the results! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Combat anti-flame
On Mon, 2003-11-10 at 16:17, David Megginson wrote: Andy Ross writes: In an attempt to depoliticize the combat flame war as much as possible, it's worth pointing out that, irrespective of people's opinions on the matter, there are not a lot of combat features we can really avoid implementing: I've been deleting the combat thread unread, but I got the impression that there was a lot of heated discussion about military stuff. I'd hate to see FlightGear become nothing more than another shoot-em-up game, but I think we've already gone too far for that to happen. I also (personally) think we're a little heavy on the warbirds (especially U.S.) and would like to see more civilian aircraft, but I'm too lazy to get off my behind and make them, so I guess I don't have a right to complain. Hopefully will not be another shoot'em up, actually doubt anyone would let that happen right? Realism is the name of the game? Why cannot both co-exist? Anyone think of any Flight sim on any platform that is a great Civilian flightsim and also has very accurate warplanes too? Otherwise, please wake me up when the discussion is over. :) Matt ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compile issues
Ok, I'm having a bit of trouble getting the release version of flightgear to compile under cygwin. I'm hardly an expert at getting major projects to compile, so I'm not quite sure what the problem even is. I've pasted the error at the bottom, so if anyone has any thoughts on it, maybe you can help. Also, where can I find an absolutely updated document which lists all of the configure options, as well as the currently required packages to compile the Release and CVS versions of FG (Do I need metakit or not? Zlib? You get what I mean). Error message follows, Thanks, JD $ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1$ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1 -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile issues
I'm also runnng cygwin and hit that one -- you need latest CVS versions of plib and simgear for starters -- try that then build fg -- I recommend --prefix=/usr on both plib and simgear builds -- cygwin doesnt have /usr/local/lib in the ld search path :) - Original Message - From: JD Fenech [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 10, 2003 9:05 PM Subject: [Flightgear-devel] Compile issues Ok, I'm having a bit of trouble getting the release version of flightgear to compile under cygwin. I'm hardly an expert at getting major projects to compile, so I'm not quite sure what the problem even is. I've pasted the error at the bottom, so if anyone has any thoughts on it, maybe you can help. Also, where can I find an absolutely updated document which lists all of the configure options, as well as the currently required packages to compile the Release and CVS versions of FG (Do I need metakit or not? Zlib? You get what I mean). Error message follows, Thanks, JD $ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1$ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1 -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ 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] Combat anti-flame
On Mon, 10 Nov 2003, David Megginson wrote: [...] I also (personally) think we're a little heavy on the warbirds (especially U.S.) and would like to see more civilian aircraft, but I'm too lazy to get off my behind and make them, so I guess I don't have a right to complain. Speaking of which... I've yielded to temptation, and took flying lessons. I've now got a license to fly one of these cool toys: http://www.comco-ikarus.de/ (click on the C42; their website sucks eggs). Apologies for missing the mention of the first solo here. Hah, and for all that money I didn't even get to keep the plane after the course! :-) There should be an EULA dialog in FlightGear: By clicking Sure, I agree that I accept any risks, be they financially or otherwise, associated with running FlightGear, including but not limited to developing a desire to obtain a pilot license and/or otherwise attempt powered flight. It could become very expensive. [No way] [Sure] Anyway, obviously I'd like to fly a C42 in FlightGear if weather doesn't allow flying a real one. Does anyone know of a freely available model of a C42, or anything that's close enough to it? The good folks at Comco are going to kill me over this, but something close like the Rainbow Cheetah would do me just fine :-) Cheers, -- Bert -- Bert Driehuis -- [EMAIL PROTECTED] -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle wrote: Paul Surgeon wrote: Why does C++ scare you? Well scare is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. If C++ doesn't scare you, you have no business using it. Sorry, but that was just too open. I had to take the shot. But seriously, there's more truth in that statement than a sarcastic retort like it deserves. The time to run screaming from a project is the moment the architect declares that it *has* to be written in C++ because no other language will do. I'm serious; use with caution. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status [now C++]
If C++ doesn't scare you, you have no business using it.
Sorry, but that was just too open. I had to take the shot. But
seriously, there's more truth in that statement than a sarcastic
retort like it deserves. The time to run screaming from a project is
the moment the architect declares that it *has* to be written in C++
because no other language will do. I'm serious; use with caution. :)
I fully second Andy here.
If you want to learn about object-oriented programming, C++, Java,
PHP, etc. is the wrong place to start. Get
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/ObjC.pdf
and read the introduction to OO programming. It really gives you the
insight you need to understand C++ and also what's wrong with it.
Pity Objective-C never really made it outside of {Next,Open,GNU}Step.
If you start a project and need OO features, either do it properly (in
Python or Objective-C), or do it the hard way with GLib/GObject.
I'd better shut up on the mailing list of a giant project written in
C++... I still admire you folks for getting it this far even with C++!
Andras
===
Major Andras
e-mail: [EMAIL PROTECTED]
www:http://andras.webhop.org/
===
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status [now C++]
If you start a project and need OO features, either do it properly (in Python or Objective-C), or do it the hard way with GLib/GObject. Naw, Object Pascal is my first love. :) I'd better shut up on the mailing list of a giant project written in C++... I still admire you folks for getting it this far even with C++! Well look at it this way, maybe they're too brain fried to go after you. :) *gdr* g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] C++ Terror!
On Mon, 10 Nov 2003, Andy Ross wrote: Gene Buckle wrote: Paul Surgeon wrote: Why does C++ scare you? Well scare is probably too strong a word. :) I'm just unfamiliar with it. I can follow C ok, but the object references tangle me for some odd reason. If C++ doesn't scare you, you have no business using it. Hehehe. It's as good an excuse as any to stick with Pascal. :) Sorry, but that was just too open. I had to take the shot. But seriously, there's more truth in that statement than a sarcastic retort like it deserves. The time to run screaming from a project is the moment the architect declares that it *has* to be written in C++ because no other language will do. I'm serious; use with caution. :) I'll poke it with a stick long enough to make it do what I need and then I'll leave it all angry and ready to bite...someone else. :) I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
Gene Buckle writes: I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. As far as I understand WideFS, FlightGear can do all that already. You can set up one copy to be a master, and any number of additional copies to be slaves. For each display channel you can specify view offset direction and fov. You can set up anything from a simple 3 monitor display system to some huge convoluted mess if you want to gang up 20 machines. I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. I did something similar on an old agwagon sim I had access to once. Fancy old joystick ... I write a little program that could read the joystick and blast positions to flightgear via the net. Seemed to work ok. Latency wasn't too bad. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] External view
I wanted to see what the aircraft looks like when there is a wind - for gear debugging. What are the keyboard commands I will need in viewing my aircraft from a nearby location or aircraft? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
Gene Buckle writes: I'm going to talk to Peter Dowson about modifying WideFS for use with FlightGear now that I've got the barest inkling of what the generic network frame can handle. We'll see how it goes. As far as I understand WideFS, FlightGear can do all that already. You can set up one copy to be a master, and any number of additional copies to be slaves. For each display channel you can specify view offset direction and fov. You can set up anything from a simple 3 monitor display system to some huge convoluted mess if you want to gang up 20 machines. I wasn't clear. I would like to try to get Peter to _modify_ WideFS to utilize the FGFS network interface so that packages like Project Magenta or SquawkBox could be used unmodified with FGFS. I may try building a small module that would direct joystick movement from my EPIC card into the sim and see how bad the latency is. I did something similar on an old agwagon sim I had access to once. Fancy old joystick ... I write a little program that could read the joystick and blast positions to flightgear via the net. Seemed to work ok. Latency wasn't too bad. Ok. I may give it a shot with the analog ports on a Phidget too. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Combat anti-flame
On Monday 10 November 2003 23:47, Andy Ross wrote: [Starting a new thread, since the original is getting a little strung out. :)] In an attempt to depoliticize the combat flame war as much as possible, it's worth pointing out that, irrespective of people's opinions on the matter, there are not a lot of combat features we can really avoid implementing: + A missile is just another aircraft with (perhaps) a variant FDM configuration. Ditto for a bomb. + A collision is a collision, be it with a guided missile, a partner in your close formation flight, or the tanker from which you are refueling. + Hydraulic/control system failures (or whatever) don't behave differently depending on whether the leak was caused by wear or a shell fragment. Overstressed civilian aircraft have been known to shed ailerons, wings, or tails on occasion. I'm sure others can come up with many more examples. Here are the only three combat only features I can actually think of which will require code or features we don't already have: + Weapon damage code. The system failures themselves can already be modeles (or will need to be at some point for civilian simulation). But computing how much failure results from a given event is something that will need to know about what a warhead is and how it differs from a bullet. + Gun trajectory modelling. Even this could *almost* be done with generic collision code by treating each shell as a separte object with its own FDM (do the math -- there aren't that many shells on an airplane, and computers are mind bogglingly fast these days). But still, the simplest gun implementation is going to be doing gun-specific stuff. + Missile homing code. This could easily be plugged into a generic autopilot framework, of course. But other than the framework boilerplate, this isn't likely to share code with any civilian autopilot implementations. :) Beyond that, all the combat stuff I can think of is going to be server-side functionality. Stuff like radar coverage handling, battlefield AI, etc... is all handled more cleanly by a separate, shared server application. Hopefully this will help to push the flames down until someone actually submits code to flame over. FWIW, I'm a mild, civically minded democrat and peacenik. I still enjoy the occasional dogfight; I've even been known to play Quake. :) Andy Identifying some of the specific bits is a good idea - it helps clarify things. The more I think about it, there seems to be more possibilities that match with both non-combat and combat environments - bird-strikes and large hail-stones were the latest things to occur to me, that might might require the same or similar code. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Heading Bug
I'm trying to track down a fault with the heading bug where it does not rotate with the compass card, meaning that the autopilot doesn't roll level at the desired heading (the heading bug never makes it to top-dead-centre). I've looked at the c310 and the seahawk in depth, and glanced at the others . The c182 and c310 work correctly. The a4, b52 and seahawk don't. As far as I can tell, the similar factor is that the c182 c310 don't have autopilot configurations in the *-set.xml file, whereas the a4, b52 and seahawk do. In those *-set.xml files that do have autopilot entries, they don't have an entry for the heading bug; however, I am guessing that the autopilot configs override some default entry and prevent the autopilot heading bug from rotating. I'm not a programmer and aren't skilled enough to look at the source code, but does this ring any bells with anyone? I'm happy to work with someone to fix this. Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Just a new bit of H/W
Just thought I'd post a link to this article about near state of the art video h/w. http://www.theinquirer.net/?article=12599 Not a bad 'bunch' of journos - I was out on a drink-up with them last Friday:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile issues
Thanks, That got it. JD John Barrett wrote: I'm also runnng cygwin and hit that one -- you need latest CVS versions of plib and simgear for starters -- try that then build fg -- I recommend --prefix=/usr on both plib and simgear builds -- cygwin doesnt have /usr/local/lib in the ld search path :) - Original Message - From: JD Fenech [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 10, 2003 9:05 PM Subject: [Flightgear-devel] Compile issues Ok, I'm having a bit of trouble getting the release version of flightgear to compile under cygwin. I'm hardly an expert at getting major projects to compile, so I'm not quite sure what the problem even is. I've pasted the error at the bottom, so if anyone has any thoughts on it, maybe you can help. Also, where can I find an absolutely updated document which lists all of the configure options, as well as the currently required packages to compile the Release and CVS versions of FG (Do I need metakit or not? Zlib? You get what I mean). Error message follows, Thanks, JD $ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1$ make Making all in tests make[1]: Entering directory `/usr/src/flightgear-0.9.3/tests' g++ -g -O2 -o test-up.exe test-up.o -lsgmath -lsgdebug -lplibsg -lplibul /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../../i686-pc-cygwin/bin/ld: cannot find -lsgmath collect2: ld returned 1 exit status make[1]: *** [test-up.exe] Error 1 make[1]: Leaving directory `/usr/src/flightgear-0.9.3/tests' make: *** [all-recursive] Error 1 -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ 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 -- A scientist claims in court that the reason he ran a red light is that, due to his speed, the color was blueshifted till it appeared green. Needless to say, the charges of running the red light were dropped and he lost his license for speeding excessively. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
