Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Gene Buckle wrote: 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.. There is a configuration file in FlightGear/data/Protocol/ At this moment it is an ASCII output protocol only implementation but it wouldn't bee too hard to add input support also. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
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.. There is a configuration file in FlightGear/data/Protocol/ At this moment it is an ASCII output protocol only implementation but it wouldn't bee too hard to add input support also. Thanks Erik. I'll take a look at it tonight when I get home. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer Server RFC -- Current Status
OK, while I'm an avowed lurker, I find that this thread has even more possibilities While I certainly want realistic flight performance of A/C to be the priority (I hope to learn to fly a real plane someday -- probably in my next life 8-( -- and I'd love it if my FG experience could translate to the real world), there ARE non-violent (or at least non-aggressive) reasons for having weapons in FG a) How about an asteroids or missile command-type simulation? These were great games, it would be interesting to tie them into a great simulation like fg. You're defending the Earth, KSFO, whatever from asteriods, missiles, what have you. Maybe even dive bombing pink flamingos, perhaps... (You're the groundskeeper and hate the cleanup after the flamingos leave... No flamingos are actually hurt of course! 8-)) Also for those with frame-rate problems, maybe a Game graphics mode that models everything in the sim fast but not necessarilly prettily. b) How about a game of tag (catch me if you can) with aircraft? (Maybe chasing a small remote control thing or a UFO) (could be weapons or without -- what about paintball or something?) c) Maybe we could create mythological 'aircraft' -- griffons, dragons, etc. and fly them or go after them Or weaponless: Or something like orienteering (follow the path) or even a scavenger hunt (find all the things on this list by flying over it), where there could be a moderator/designer setting things up, possibly real-time If missiles are out, perhaps we can shoot arrows. I don't mean to belittle anyone's beliefs, I'm pro-peace (realistically speaking, who could be pro-war, Genghis Khan?), and think the concept of spending billions on weaponry when children are starving all over the world and dying daily due to lack of imunizations for preventable diseases poor judgment to say the least... Don't even get me started on the atomic/nuclear weapons thing... OK off my soap box. Great sim, hope to help with developing it someday. I love it if we had some name or information in the scenery that could be popped up over, say, a building/landmark when it is visible in the distance. Crater Lake, Berlin wall, Sears tower, RFK stadium, etc. Some of us aren't used to looking at the world from above ground level. There's an MS flightsim add-on that does this, I don't recall the name, landmark, maybe? I'll go back to lurking now Ima 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. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Tuesday 11 November 2003 09:46 am, Ima Sudonim wrote: OK, while I'm an avowed lurker, I find that this thread has even more possibilities Wow, is Sudonim our first troll, or have there been others? Dave ___ 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] 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] 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
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] 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
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
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] 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] 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] 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
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] 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
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
Jonathan Richards writes: 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). I've just started reading through the multiplayer thread. Good to see some action on this front and it sounds like you guys know a lot more about it, and have a lot more experience with the issues than I do, so I'll generally just sit back and leave this to the experts. However, let me point out that some people have a big problem with even pretending to shoot people. Personally, I have no problems with shoot 'em up games as long as you don't play them so much you start dreaming about it. :-) We should recognize however that many people feel *very* strongly about this ... strong enough to leave this project if they sense we are trending towards a pure combat sim. 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. 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. 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
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? Jon ___ 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: Curtis L. Olson [EMAIL PROTECTED] 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. 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. Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) Jon Berndt wrote: 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. I disagree -- if they are hooking to a multiplayer server they should be visible by default, conversely, if they choose to be invisible on a combat active server, weapons should be disabled, as well as a/c collision detection (i.e. get a birds eye view of a running battle without actually being involved) -- this could be handled very easily by setting up a client connection that sends nothing to the server -- just monitors the active server traffic -- another option for the peer connection module :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. 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
John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. That's fine, as long as when I start up my instance of FLightGear (on my Internet attached system) that I am my own self with no Internet connetivity whatsoever. Jon ___ 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: Jon Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 4:24 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. That's fine, as long as when I start up my instance of FLightGear (on my Internet attached system) that I am my own self with no Internet connetivity whatsoever. absolutly -- you must --mp-client or --mp-server on the command line -- just like the other protocols ___ 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: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 4:16 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. I'm talking more along the idea that the server operator will choose if the world is combat or not combat -- rather than trying to do both in the same world -- once I get the core online and move on to the community webserver, server config including combat/non-combat status will be displayed so you can choose the type of world you wish to participate in and no reason I can think of not to run multiple servers on a single machine, or multiple machines, some combat, some not, if, as a server operator, you wish to provide a broad range of environments for flyers thats getting into the scenario system and setting a startup scenario for the server -- for instance, starting at a particular airport with only single engine prop planes allowed for civilian GCA practice, or having multiple starting airports and full combat for a capture the enemy bases scenario like Air Warrior (anyone thought of doing a tank sim based on the FG core code ?? -- both pilotable and AI driven ?? EvilGrin ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Sunday 09 November 2003 21:16, Curtis L. Olson wrote: John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. 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 Wouldn't it be better to have several instances of the server, running either a non-combat environment or a combat environment, but not trying to do both at the same time? Non-combat servers would talk to other non-combat servers, and like-wise with the combat servers. I'd be a bit concerned about problems with, for example, the combat environment affecting the non-combat environment, and visa-versa. LeeE ___ 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: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 5:05 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Sunday 09 November 2003 21:16, Curtis L. Olson wrote: John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. 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 Wouldn't it be better to have several instances of the server, running either a non-combat environment or a combat environment, but not trying to do both at the same time? Non-combat servers would talk to other non-combat servers, and like-wise with the combat servers. I'd be a bit concerned about problems with, for example, the combat environment affecting the non-combat environment, and visa-versa. Ohhh we arent even CLOSE to talking about distributed servers yet -- lets get a single server system online and tested first -- THEN we can talk about a distributed system that simulates the entire world !! (which I think would be ultimatly kewl -- non-combat, recent a/c, simulated ATC and RATC, etc) I'm already thinking about chopping off data updates for a/c that are not within visual/radar range to keep the message traffic reasonable for sims covering large terrain in the single server setup -- distributed servers will need much more than that :) Something along the lines of regional ATC servers covering large areas, then a server for each airport to handle approach control and ground traffic Though actually -- a single master server could handle all the position updates without that much trouble given the update limiter code and headless (no opengl display) operation -- offload the airport and regional ATC to stand alone apps that interface to the master server as clients. (thats going to take some work on the ATC system to make it interface to the system like a network peer, even for single user operation, such that you can startup instances of the ATC code for specific airports and RATC) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Sun, 9 Nov 2003, John Barrett wrote: Though actually -- a single master server could handle all the position updates without that much trouble given the update limiter code and headless (no opengl display) operation -- offload the airport and regional ATC to stand alone apps that interface to the master server as clients. (thats going to take some work on the ATC system to make it interface to the system like a network peer, even for single user operation, such that you can startup instances of the ATC code for specific airports and RATC) Presumably you could just have a client config which specified the area of interest, and have the server send out only arcraft within that - obviously this imposes a higher load on the server though - maybe it'd be possible to do a very coarse cull on the main server, and output data to regional machines - if the protocols are consistent throughout then you'd end up with a scalable system which should (in theory) be able to cope with an awful lot of aircraft, controllers, etc etc. As the system expanded then more localised features could be implemented further down the chain. -- 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
On Sun, 9 Nov 2003, John Barrett wrote: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be Yeah, it's certainly a much faster calculation. very fast for the server to do that check before forwarding data to a given client Will clients be able to select relevant data types too? (Obviously you're gonna want different data for an ATC client and a sim client, although there will be a certain amount of overlap). -- 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
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 6:13 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Sun, 9 Nov 2003, John Barrett wrote: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be Yeah, it's certainly a much faster calculation. very fast for the server to do that check before forwarding data to a given client Will clients be able to select relevant data types too? (Obviously you're gonna want different data for an ATC client and a sim client, although there will be a certain amount of overlap). Probably not for 1st cut -- but certainly possible ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be very fast for the server to do that check before forwarding data to a given client Please - remember FGFS is not a flat earth system so get rid of the degrees and the square degree block concepts, as these are very inefficient and inaccurate when operating on a sphere. Position is an ECF vector and distance can be degrees of arc if you insist, but 'chord distance' is a one to one mapping and is *much* quicker to compute. http://www.flightgear.org/Docs/Scenery/CoordinateSystem/CoordinateSystem.html Norman ___ 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: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 6:28 PM Subject: RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status John Barrett writes: If each client instance specified I'm only interested in events which happen within 20deg of my current position (use a square around current lat/lon offset by the range specified, rather than circular) -- should be very fast for the server to do that check before forwarding data to a given client Please - remember FGFS is not a flat earth system so get rid of the degrees and the square degree block concepts, as these are very inefficient and inaccurate when operating on a sphere. Position is an ECF vector and distance can be degrees of arc if you insist, but 'chord distance' is a one to one mapping and is *much* quicker to compute. http://www.flightgear.org/Docs/Scenery/CoordinateSystem/CoordinateSystem.html whatever works -- if the computation gets too intense, it can always be handled periodically (every 60-120 seconds perhaps) and keep a list of entities for which we are interested in their updates -- entity IDs are going to be 32 bit integers, so we wont be hitting memory all that hard even with 100s of planes in the air -- or even reverse it -- each entity keeps a list of entities to which it will send updates -- list updated periodically -- then we dont have to walk the list of entities looking for those that are interested ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status
On Sunday 09 November 2003 22:23, John Barrett wrote: - Original Message - From: Lee Elliott [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 5:05 PM Subject: Re: [Flightgear-devel] Multiplayer Server RFC -- Current Status On Sunday 09 November 2003 21:16, Curtis L. Olson wrote: John Barrett writes: Would a --no-combat option on the server be acceptable ?? (i.e. someone can pull the trigger, but it wont do anything to the multiplayer world -- they could still use you for a target, but you would never see the ordinance) That sounds reasonable. I would add the additional condition that people running with --no-combat would not even see people running with --combat. I think we should keep the two worlds completely separate. I suppose if the combat people want to see me, that's ok, but I don't want to see them. The idea is that if a few of us are flying around the pattern following civilian rules, it doesn't make sense to have a bunch of combat planes looping around and making high speed passes on us. That doesn't make sense for the civilian world ... and if we are doing what we are supposed to be doing, seeing the combat aircraft using as as target practice could be very disruptive. Ultimately I think I would vote for keeping the two worlds entirely separate. 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 Wouldn't it be better to have several instances of the server, running either a non-combat environment or a combat environment, but not trying to do both at the same time? Non-combat servers would talk to other non-combat servers, and like-wise with the combat servers. I'd be a bit concerned about problems with, for example, the combat environment affecting the non-combat environment, and visa-versa. Ohhh we arent even CLOSE to talking about distributed servers yet -- lets get a single server system online and tested first -- THEN we can talk about a distributed system that simulates the entire world !! (which I think would be ultimatly kewl -- non-combat, recent a/c, simulated ATC and RATC, etc) I'm already thinking about chopping off data updates for a/c that are not within visual/radar range to keep the message traffic reasonable for sims covering large terrain in the single server setup -- distributed servers will need much more than that :) Something along the lines of regional ATC servers covering large areas, then a server for each airport to handle approach control and ground traffic Though actually -- a single master server could handle all the position updates without that much trouble given the update limiter code and headless (no opengl display) operation -- offload the airport and regional ATC to stand alone apps that interface to the master server as clients. (thats going to take some work on the ATC system to make it interface to the system like a network peer, even for single user operation, such that you can startup instances of the ATC code for specific airports and RATC) I read your later post after I'd sent that:) I agree that the server operator choosing the type of world is a good idea. However, there's potential for quite a wide range of realistic scenarios including elements of both non-combat and combat features. For example, air/sea rescue missions (and their code infrastructure) would be appropriate in most multiplayer scenarios, both non-combat and combat - if you were flying ga into/out of, or in the vicinity of an airfield that hosted air/sea rescue services in a non-combat world it would be realstic for those operations to occur at the same time and even interfere with normal flying in that world, according to the appriopriate procedures. 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;) Similarly, and bearing in mind that some work has been done on simulating failures, it could be possible for an a/c to declare an emergency, say an engine fire on a multiple, that disrupts all the other folk in the curcuit. Realistically, civil airliners have also been shot down, but I can't see anyone really wanting to try that scenario as it's a bit pointless, or seems so to me. LeeE ___ 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: Lee Elliott [EMAIL PROTECTED] I read your later post after I'd sent that:) I agree that the server operator choosing the type of world is a good idea. However, there's potential for quite a wide range of realistic scenarios including elements of both non-combat and combat features. As I see it -- the client and server should both be capable of the full range of activities, the only question is then do weapons work or not ??. Practicing aircraft carrier landings does not require weapons :) For example, air/sea rescue missions (and their code infrastructure) would be appropriate in most multiplayer scenarios, both non-combat and combat - if you were flying ga into/out of, or in the vicinity of an airfield that hosted air/sea rescue services in a non-combat world it would be realstic for those operations to occur at the same time and even interfere with normal flying in that world, according to the appriopriate procedures. That applies to most everything one might do with FG except weapons code, and I consider the weapons code to be a small burden to non-combat users in terms of increased executable size and additional airplane information that wont get used in their scenarios -- the combat system doesnt need to be intrusive, but it needs to be there :) And except for specific items such as missiles and cannons, many parts of the combat system are useful for non-combat scenarios -- flying with drop tanks, changes in FDM based on changes in load -- crop dusting :) 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. Similarly, and bearing in mind that some work has been done on simulating failures, it could be possible for an a/c to declare an emergency, say an engine fire on a multiple, that disrupts all the other folk in the curcuit. Be interesting to see how AI ATC code could be setup to deal with that :) Realistically, civil airliners have also been shot down, but I can't see anyone really wanting to try that scenario as it's a bit pointless, or seems so to me. No 9/11 here please !!! Someone may want to do scenarios like that, its certainly possible, but not something I'm personally interested in. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
John Barrett writes: Norman Vine writes Please - remember FGFS is not a flat earth system whatever works -- if the computation gets too intense, it can always be handled periodically (every 60-120 seconds perhaps) and keep a list of entities for which we are interested in their updates -- entity IDs are going to be 32 bit integers, so we wont be hitting memory all that hard even with 100s of planes in the air -- or even reverse it -- each entity keeps a list of entities to which it will send updates -- list updated periodically -- then we dont have to walk the list of entities looking for those that are interested Or perhaps use an appropriate global tesselation that just happens to make finding all entities within some distance trivial by just checking those buckets that are within the distance criteria. Then by just keeping track of which bucket all entities are in the operation is just a trivial check of the pertinent buckets lists :-) This mechanism would be useful for *many* related lookups and is an elegant solution to the spherical distance query. it just happens to be similar to what is used in several actively pursued star search projects which have the exact same *heavily* researched problem albeit an inverted manifestation AFAIK all such tesselations are built from either (1) spherical triangular facets or (2) their mathematical dual the corresponding spherical 'dirchlet' or 'vornoi' tesselation. There are several papers desribing these and other global grids at the link I posted recently in the Re: [Flightgear-devel] Some thoughts and ideas (LONG) thread trying-to-practice-what-Columbus-proved'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[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 thanks, Mick. ___ 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: 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 ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
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 -- 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 -- 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] 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] 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 -- 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 -- 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] 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] 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] Multiplayer Server RFC -- Current Status
We have covered a LOT of territory the last couple of days, so I think we are due for a summary to date: Phase 1 1. Server implementation to be integrated with the current FG code a. --fgspeer= protocol module with HUD updates b. --fgsserv= protocol module and basic reflector server c. --headless option for standalone server operation d. --webserv= remote config/status module e. --commserv= community server publishing url 2. Protocol design and implementation a. TCP streaming protocol b. message packing/unpacking classes c. message base class 3. Initial Radio Message set definition a. Tower ATC messages b. Regional ATC messages c. Ground Traffic Control 4. Basic Community Server a. PHP based b. Mysql database backend if needed c. Netscape and IE launcher integration allows a link to start FG with correct settings primary goal: multiplayer flight Phase 2 1. weapons stores with FDM integration 2. dynamic shared library system for weapons behaviors 3. server extensions for ordinance instance management 4. scenario system design and initial implementation 5. web-based scenario builder design and prototype 6. community server enhancements primary goal: shoot and record hits (no damage) secondary goal: Red Flag scenarios Phase 3 1. damage system integration 2. incremental system damage effects 3. FDM damage effects 4. AI surface to air weapons (AA, SAM, etc) 5. dynamic shared library system for AI pilots 6. server extensions for AI aircraft instances 7. web based scenario builder functional for current features primary goal: blow them outa the sky !! There is a lot more to cover, but this should be more than enough to keep us busy for a while :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
