Re: [Flightgear-devel] Some questions regarding scenery files
On Sunday, 9 November 2003 03:22, Norman Vine wrote: This scheme may not be optimal but a square degree block even though it is conceptually simple is far from optimal. Remember we are trying to tile a sphere and squares don't work, esp. if you want anything approximating an equal area subdivision. FWIW IMO the current scheme is a terrible hack but ... it works if you disregard the poles and is a *major* improvement over our earlier 'square' tiling. Well after having given it some thought I can't think of a better way of doing it either. Not that I know that much about projection systems anyway. It does make the scenery building more complex because you have to keep track of how many columns are in the tile you are currently working on. Plus you have to resolve the joining between tiles with differering numbers of columns. On the positive side it does solve the problem of squeezing too much data into a tile as you approach the poles. I wonder if TerraGear does automatic texture scaling based on lattitude ... This is one area that several of us have always intended to go back and rethink but ... it has seemed to be work well enough and there are always more pressing things todo :-) Yip, we must not neglect the other areas. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] b0105 lock
This still appears under the /models subdirectory. talk21 your FREE portable and private address on the net at http://www.talk21.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Hi, They have mentioned FlightGear as a candidate simply for the reason that it can be modified and changed to do whatever we want it to do. No restrictions on functionality. Yes, that's the advantage of open source. BTW, I have lately heard people call Targetware and MSFS/CFS open source because you can mod it, but of course that is very different to having the program source in the open. We need at least one properly/accurately modeled aircraft that we can show off. I'm talking nice visually (high poly count) and with an accurate flight model. Regarding the visuals, the easiest way is use an existing model and convert it. We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. I did that a long time ago, before the LinuxTag trade fair. It is in PPE (the open source modelle PrettyPolyEdit, which sits on top of the library PLIB, like FGFS does). You look at the terrain from above. Of course you can rotate and move the camera. You then simple click the mouse onto the spot you want to add the model. You then have three dials to edit the pitch rolll and yaw if possible. For example, with taildraggers converted from MSFS, they are normally horizontal and you have to rotate in pitch until all wheels are on the ground. I am not sure anyone used this apart from me. This should still work, but it uses ascii terra gear scenery. I do not know the status on that. Is there a converter? What 3D formats and apps are used? See the bottom of this page for file formats: http://plib.sourceforge.net/ssg/non_class.html In the big table, look for formats we can load. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
We need some nice development tools. In particular a full blown scenery editor that one can use to lay down 3D objects (trees/buildings), taxiways, aprons, roads, rivers, etc. If it's done in OpenGL then you can make it WYSIWYG. Look at http://fgsd.sourceforge.net -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Apologies for the cvs commits
John Barrett writes: Like to apologize to Curtis for the cvs commits using the cvsguest account (though I didnt do the ones to the ATC code That was me - I inadvertantly committed from the wrong tree. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer -- wire protocol implementation
http://www.camelot-software.com/fgfs/fgmps.tar Here is the patch and source files for the preliminary wire protocol implementation -- comments and suggestions welcome -- untar in the directory containing the FGFS source directory, apply the patch, autogen, configure --with-multiserver, and make -- 2 executables (buftest and msgtest) will be created in src/Servers that demonstrate the wire protocol handling, and the base class for managing messages At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? And lastly, which is the best network module to use as a reference for creating the status messages that get sent out every call to process() so that I dont miss anything critical ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote: At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? Take a look at plib/src/net. From the README in that directory: This is a C++ library for making networked games. It includes event-driven channels, support for buffering and pipelining, a monitor server for remote telnet admin, and binary messages. HISTORY Initial work by Dave McClurg [EMAIL PROTECTED] This library is based on from a high-performance internet server architecture for Python called Medusa. http://www.nightmare.com/medusa/medusa.html Added binary messages and PLIB naming conventions Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett writes: At the moment, I'm planning to build in my own socket classes to handle the net connections, as they are designed to handle multiple connections in a polling environment -- unless someone can point me at existing code in FG / SimGear / PLib thats up to handling multiple socket instances with reasonably low overhead ? PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) The 'loop' is in netChanel.cxx SimGear sockets and are built ontop of PLib/Net as is the FGFS http server, which should make an applicable stress test easy to formulate :-) for a Python based discussion of the methodology used see http://www.nightmare.com/medusa/medusa.html HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Help please!
* Sarel Theron -- Sunday 09 November 2003 06:59: On Fri, 2003-11-07 at 23:14, Melchior FRANZ wrote: * Sarel Theron [EMAIL PROTECTED] wrote: slDSP: write: Resource temporaliry unavailable [...] Or use a recent version of plib/SimGear/FlightGear (if you don't already). There was a bug in plib that could cause this together with certain sound chips/alsa drivers under Linux. I have downloaded the latest stable release of plib(plib-1.6.0) Sorry, this should have been: use the plib version from CVS. The changes that I'm referring to weren't published in an official release yet. They'll be in the next release. I run configure it can't find the GLU working directory. When I run ./configure --without-glut it can't find the OpenGL header file. Because they aren't installed? You should install these: mesaglut The Mesa Glut library mesaglu SGI's sample implementation of the GLU library mesaglu-devel Development package for mesaglu (GLU library) mesaglut-devel Development package for mesaglut (glut library) mesa-devel Development package for mesasoft (GL library) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) The 'loop' is in netChanel.cxx SimGear sockets and are built ontop of PLib/Net as is the FGFS http server, which should make an applicable stress test easy to formulate :-) ok -- I give up :) total surrender :) Interestingly enough -- the classes are quite similar to mine -- even unto line terminator handling -- prime difference being that my socket instances must register with the server class in derived implementation code, since the core socket code can be used with or without the server loop -- looks like plib handles that automatically Guess I have enuf to do the server framework and initial handshake between client and server ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett writes: From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) Guess I have enuf to do the server framework and initial handshake between client and server Might want to ask any questions or solicit ideas over on the PLib list as this Library has been used before in somewhat similar 'online' gaming apps :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote:
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome
This sounds fun, so I grabbed it and had a peek. One bug report in
messagebuf.cxx, which has some code that I can't figure out:
void FGMPSMessageBuf::put(unsigned char byte, bool raw)
{
if (!raw) {
if ((byte 0xf0) == 0xf0) {
buf += 0xff;
byte = byte ^ 0xff;
}
}
buf += byte;
}
If I read this correctly, if raw is false (which is the default
argument), then values in the range 0-239 are passed normally, while
values in the range 240-255 cause an extra byte of 255 to be inserted
in the stream, followed by the bitwise negation of the original byte.
I don't see anywhere for the extra 255 to be interpreted on read,
though.
I'll admit that I have absolutely no idea what this code is supposed
to do. :) Are you maybe trying to handle 2's complement signed values
via an escaping mechanism? If so, you need to change the bit test to
0x80, and can elide the complement operation entirely. It's best to
leave signedness determination in the hands of the user code, though.
One other nit is a collection of portability bugs in your type
declarations. A long value isn't guaranteed to be 32 bits, on an
LP64 platform (64 bit unices, but not Win64) it's a 64 bit quantity.
I also see some locations where you appear to be assuming that an
int is 16 bits, which was true on the PDP-11 and 8086, but nowhere
else; it's not clear if this extra precision will result in real bugs
or not.
Andy
--
Andrew J. RossBeyond the OrdinaryPlausibility Productions
Sole Proprietor Beneath the Infinite Hillsboro, OR
Experience... the Plausible?
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message -
From: Andy Ross [EMAIL PROTECTED]
To: FlightGear developers discussions [EMAIL PROTECTED]
Sent: Sunday, November 09, 2003 11:59 AM
Subject: Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
John Barrett wrote:
Here is the patch and source files for the preliminary wire protocol
implementation -- comments and suggestions welcome
This sounds fun, so I grabbed it and had a peek. One bug report in
messagebuf.cxx, which has some code that I can't figure out:
void FGMPSMessageBuf::put(unsigned char byte, bool raw)
{
if (!raw) {
if ((byte 0xf0) == 0xf0) {
buf += 0xff;
byte = byte ^ 0xff;
}
}
buf += byte;
}
If I read this correctly, if raw is false (which is the default
argument), then values in the range 0-239 are passed normally, while
values in the range 240-255 cause an extra byte of 255 to be inserted
in the stream, followed by the bitwise negation of the original byte.
I don't see anywhere for the extra 255 to be interpreted on read,
though.
for cooked data, values 0xf0 to 0xff are protocol reserved values and are
escaped by prefixing with 0xff and inverting the data -- you can find the
corresponding decoding in the get method
unsigned char FGMPSMessageBuf::get(bool raw)
{
if (pos = buf.length())
throw FGMPSDataException( FGMPSMessageBuf: Read past end of buffer );
if (raw) return buf[pos++];
if ((unsigned char)buf[pos] == 0xff) {
pos++;
return ((unsigned char)buf[pos++] ^ 0xff);
}
return buf[pos++];
}
I'll admit that I have absolutely no idea what this code is supposed
to do. :) Are you maybe trying to handle 2's complement signed values
via an escaping mechanism? If so, you need to change the bit test to
0x80, and can elide the complement operation entirely. It's best to
leave signedness determination in the hands of the user code, though.
Trying to make the protocol resistant to changes in message structure, and
malformed messages due to transport layer errors (for instance if this
protocol is run over serial lines or modems) -- I thought it desirable that
protocol specific values never appear in the application data and that all
data elements in a message be typed so that malformed messages could be more
easily detected (we used a similar setup over at WorldForge to make the
client/server link more tolerant when the endpoints of a connection had
different application message versions)
One other nit is a collection of portability bugs in your type
declarations. A long value isn't guaranteed to be 32 bits, on an
LP64 platform (64 bit unices, but not Win64) it's a 64 bit quantity.
I also see some locations where you appear to be assuming that an
int is 16 bits, which was true on the PDP-11 and 8086, but nowhere
else; it's not clear if this extra precision will result in real bugs
or not.
I know -- I claim fatigue as an excuse - I'm packing to move next week while
I work on this -- I'll dig in and find the portable type declarations and
update the code in the next few days :)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer -- wire protocol implementation
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, November 09, 2003 11:58 AM Subject: RE: [Flightgear-devel] Multiplayer -- wire protocol implementation John Barrett writes: From: Norman Vine [EMAIL PROTECTED] PLib/src/net is a 'reasonably' efficient implementation of using polling in a multiple connection environment :-) Guess I have enuf to do the server framework and initial handshake between client and server Might want to ask any questions or solicit ideas over on the PLib list as this Library has been used before in somewhat similar 'online' gaming apps :-) I think between the http network module and the other modules that actually move a/c data, I've got enough to get the basics in place -- my next question will be how do I add an a/c instance to the current scene and keep it updated but I can likely dig that out of the other multiplayer modules ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some questions regarding scenery files
Paul Surgeon writes: I wonder if TerraGear does automatic texture scaling based on lattitude ... Yes. 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] Apologies for the cvs commits
John Barrett writes: Like to apologize to Curtis for the cvs commits using the cvsguest account (though I didnt do the ones to the ATC code -- just the configure.ac, src/Makefile.am, src/Main/Makefile.am, and the src/Server directory) I should apologize too for inadvertantly leaving the cvs tree wide open like that. Glad to see that no one was intentionally abusing this. Curtis -- you left the src/Server directory and my code in the repository -- could you remove it so I can make correct patch files, or set me up with a developers cvs account so I can legitimatly make changes ?? I figured your changes would eventually return through proper channels so I just left that in for now. If you want me submitting patches, I will need the correct procedure for creating patches. I havent had any luck using cvs diff or diff off the command line to get the right output. The directions that were posted in the users list didnt work out either. For my approach to looking at change submissions and adding them to the source tree, it is most convenient for me to receive whole copies of any changed files. Others have different approaches and might prefer just the diff's. For submitting diff style patches, I'd recommend using cvs diff -c to get 'context' style diffs. 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] Some thoughts and ideas (LONG)
Paul Surgeon writes: On Friday, 7 November 2003 02:58, David Megginson wrote: What release is it? The 172 changed a release or two ago. 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) I would run it under Linux except that last time I couldn't maximize the screen without the FPS dropping to 1. If you are running low on video ram, enlarging the window can kill your performance (due to needing to reallocate and shuffle ram.) You can try starting with the window maximized and see if that works. 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] Some thoughts and ideas (LONG)
Jim Wilson writes: Recently I aquired a copy of the latest MSFS. It's the first I've bought since MS took it over from SubLogic! (No I haven't gone crazy and joined the other side. It was USED and very cheap so my rational was it would not put money directly into the pockets of the microsoft billionaires club :-)). After spending a two or three hours with it my impression is that there are two ways to value eye candy...quality and quantity. The MS has a lot more quantity because of all the bodies they threw at it. We're there, or better, with the quality. For those inteterested in the appearance of the scene and the aircraft, all they need to do is go to work and build some models. Yes, FlightGear's engine is pretty flexible and can do a lot of nice things. The biggest thing we are lacking now is content (i.e. aircraft and scenery features) that utilizes all the features that FlightGear provides. BTW I can also say now that I understand now how much of a threat the FLY! series was to the microsoft product. Too bad it failed...but it looks like FlightGear is destined to someday be a major influence in the popular arena. I have no desire to put a bunch of fine MS employees out of work, but hopefully FlightGear can be a big influence in the field and drive everyone to do better and better. 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] Some thoughts and ideas (LONG)
Norman Vine writes: Paul Surgeon writes: I hope FG doesn't tie textures to every single polygon in the scenery files. (faster rendering because the calculations don't have to be done at render time but larger scenery files because of all the texture co-ords tied to the vertices) This is exactly what Flightgear does for several reasons but Don't let this discourage you because I can't think of any thing in the code that would really have to change outside of the terrain parser and the low level tile class and these would have to be changed anyway to support any change in the terrain structure. I am looking forward to seeing another mechanism for a global seamless terrain rendering on a dimpled ellipsoid :-) Sure, anyone is welcome to build an alternate scenery rendering subsystem. There are a zillion different approaches out there each with it's own strengths and weaknesses. FlightGear impliments just one approach right now. 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] Apologies for the cvs commits
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] I figured your changes would eventually return through proper channels so I just left that in for now. If you want me submitting patches, I will need the correct procedure for creating patches. I havent had any luck using cvs diff or diff off the command line to get the right output. The directions that were posted in the users list didnt work out either. For my approach to looking at change submissions and adding them to the source tree, it is most convenient for me to receive whole copies of any changed files. Others have different approaches and might prefer just the diff's. For submitting diff style patches, I'd recommend using cvs diff -c to get 'context' style diffs. Ok -- I'm currently setup to generate a diff on any existing files excluding my working directory plus my entire working directory (src/Server) in a tarball -- how do you want it submitted when its ready to go in the source tree ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Alpha channels in textures
Paul Surgeon writes: Obviously FG supports alpha channels in textures used for 3D objects like trees but is the same true for ground textures? Yes, that should be supported. It's more a function of the texture, not where/how it is drawn. i.e. Can FG do multitexturing (blend two textures together based on an alpha channel)? Currently, plib does not support multi-textureing, so as a result we do not either. It's possible to mix in arbitrary opengl code with plib so multitexturing is possible, but not necessarily clean or easy (?) Someone in the past submitted multitexturing patches to plib, but they were rejected for some unfortunate reason. 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
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] Some thoughts and ideas (LONG)
Curtis L. Olson writes: If you are running low on video ram, enlarging the window can kill your performance (due to needing to reallocate and shuffle ram.) You can try starting with the window maximized and see if that works. There's also a problem with the NVIDIA drivers on some systems, just generally. For example, if I start with a very small window (say, 320x240x16) and shrink it by a few pixels, that's it for hardware rendering -- we're down to a frame every 30 seconds or so; on the other hand, I can start at 1600x1200x160 and get about 18 fps. I've had that problem for a year and a half, ever since I started using a notebook with a Geforce2Go. I don't have the problem with other 3D programs like the plib demos, only with FlightGear. We must be enabling something that triggers the driver or hardware bug. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Server RFC -- Current Status
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
[Flightgear-devel] fgrun - runtime error
This may be one for Erik ... I am using FG 0.9.3 CVS version. I have compiled fltk and fgrun on SuSE8.2 and both seemed to go fine.I compiled both with --with-x and --with threads. On running fgrun I get the following message in the console linux:~ # fgrunX_DestroyWindow: BadWindow (invalid Window parameter) 0x2acX_TranslateCoords: BadWindow (invalid Window parameter) 0x21X_TranslateCoords: BadWindow (invalid Window parameter) 0x21 and a gray (blank) window entitled FlightGear log (this leaves lines behind it when dragged). fgrun then hangs. This looks like an X-related problem? Any ideas? Tks, R ___ 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
