Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 10:46 schrieb Vivian Meazza: Oliver Schroeder I *think* that the flightgear client is kind of to big and this kind of program (lets call it injector) does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. Yes FG is big, and would have unused functions. Against this has to be balanced the time and risk in developing and maintaining a stripped down version. I don't have a handle on the size of that task or the risks involved. I didn't mean to develop or maintain another version of FG, i guess an appropriate configure can do the trick. Something like configure --without-opengl --without-ATC ... I suggested some time ago that the first player's system might handle all the admin tasks - that way you get the AI traffic, carrier movements etc. virtually free. However, there are significant questions surrounding that idea: in particular what happens when the first player leaves. It ought to be possible for the 2nd player to take up the task, because both systems should be aligned. There is also the load on the individual client to be taken into account. I guess this will raise more problems then it will solve. That's why I thought of injectors. They are (read: would be) player independent. I'm not sure exactly what you mean by a scriptable client. Does this mean that it has pre-scripted AI traffic, carrier movements, weather etc.? Something like that, yes. If you are saying that the server should have as little knowledge as possible, then I would go along with that. I think the server probably needs to coordinate the network time but beyond that ... there is a case for the server to filter by range, but this could also be done by the client. The idea is to disburden the clients as they will already have enough work to do with rendering etc, especially with a gowing number of additional clients at the scene. I have no strong view on how this should be achieved. We should build on what we already have in order to achieve a fully coordinated environment. We should not be re-inventing wheels, flaps or anything else :-) Dacor, I'm always a friend of recycling ;) Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 20:14 schrieb Andy Ross: Josh Babcock wrote: Right, it would be silly to send all that data to the server when all it needs to know is where your are and what you can see. Plus the position data could be sent at low resolution. The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. This way your wingman always gets updated, and a burning/turning dogfighter will get frequent updates, but a jetliner moving in a straight line is nicely optimized and receives very few updates. You can also handle orientation error this way, by giving the object a radius and figuring that a 180 degree orientation different produces an error of that size. I am sure that I don't understand this. Anyway: Sending updates based on importance would improve rendering of nearby objects, as a client would get more/better information of objects of its interrest? In that case: can the server decide what is important to a client? Either way the server would have to be able to handle multiple instances of the same callsign. Otherwise an invisible observer could silently prevent a flier from connecting. Better would be to assign a prefix or suffix to duplicate callsigns, so that the second andy to connect becomes _andy or andy-0, etc... Actually the server doesn't care much about callsigns. It simply checks Sender-Callsign == Currentplayer-Callsign and Sender-IP == Currentplayer-IP (Currentplayer = current player when walking through the list of clients) and thus preventing sending packets back to the sender. Also, I'd suggest defaulting the callsign to the USER (unix, cygwin) or USERNAME (winnt) environment variables where available, to avoid the problem of zillions of identical flightgear-user planes flying around. Sane defaults are always good. This should be easy to implement in the client. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
Curtis L. Olson wrote: Either way, the nice thing is we have direct access to a real SR20 and a real SR20 pilot so we should be able to get as much information and as many pictures as we want. Is there anyone who'd be up for something like this? We've also got the POH, containing three view drawings: http://www.cirrus147.com/sr20poh-trimmed.pdf http://www.a1.nl/~ehofman/fgfs/download/front.rgb http://www.a1.nl/~ehofman/fgfs/download/left.rgb http://www.a1.nl/~ehofman/fgfs/download/plan.rgb Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
From: Curtis L. Olson Is there anyone out there in FlightGear developer land that would be interested in doing a Cirrus SR20 model for FlightGear? Highest priority would be the 3d model and as much of a 3d cockpit as we can do (realizing we aren't real strong on the glass cockpit stuff yet.) This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. You might want to talk to her/him about offering a bounty. What is really intended with the owned model? Selling it? Folks should beware of giving up their copyright for smallish fees, you may regret it later when you want to reuse some of your own work. Either way, the nice thing is we have direct access to a real SR20 and a real SR20 pilot so we should be able to get as much information and as many pictures as we want. Is there anyone who'd be up for something like this? Hopefully someone will pick up on this for GPL. Unfortunately I can't until probably a year from now. Doing the sr20 would be a much easier than usual task. There's a wealth of information and support on this aircraft. It would not surprise me if the manufacturer would offer some assistance in the form of data as well. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
Jim Wilson wrote: You might want to talk to her/him about offering a bounty. What is really intended with the owned model? Selling it? Folks should beware of giving up their copyright for smallish fees, you may regret it later when you want to reuse some of your own work. It's not nearly that evil. This person has a software product they plan to bring to market soon. They want to interface their product to a stock version of FlightGear to add an optional 3d visualization component. It's not required but increases the coolness factor. The software product relates to the Cirrus SR20. So it would be nice from their perspective (bot not necessary) to have the Cirrus SR20 modeled. They don't plan to sell the model. Their main focus is to sell their own software. A nice add on feature is it's ability to interface to FlightGear. And even nicer (for them) would be if FlightGear had an SR20 model. An SR20 model would be a nice addition to flightgear, so if we can find a volunteer to do this, that would be great. As Jim says, there is a lot of info available, and this person who is interested has an SR20 so he could provide all kinds of pictures and details that might be hard to dredge up from the net. If it helps motivate someone, he might be able to come up with a small amount of $$$ to do the job, but in this case, if he's spending his own money, he wants to own the result. My local airport has a certified Cirrus service center and a buddy of mine knows the main guy there so that's another potential source of information. Is anyone interested in taking a crack at this? Best regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
And remember that a robust implementation can get big speedups by handling Mostyn Gale wrote: Andy Ross wrote: The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. Also a consideration is the detail of the updates. A plane 10km away can be have an accuracy of 1m but you would like a plane in formation to fly have about 1cm accuracy. That's why the accuracy is specified in screen space, not distance. Basically, divide by the distance from the observer and that is your priority. Sending velocity and acceleration data can also smooth make flight smother, but only for nearby aircraft. They're useful for everything, actually. Consider a jetliner in a steady turn. A single packet is enough for many seconds of extrapolation if it includes acceleration, but will rapidly become incorrect But how will the server calculate this? There will be 2^N-N relationships for the computer to work out which levels of reports to send to each client. For 20 players that is over a million calculations that the computer must perform every cycle. I'm not sure where you get the exponential there. There are N^2/2 distance calculations required to get all the inter-object distances. A naive implementation (this can actually be optimized pretty well) would then need to do another N priority calculations for each client, for a total of O(N^3), or around 8000 computations per cycle. Really, it's going to be done per packet received (which are O(N), of course), so it's really more like 400 per packet for 20 clients. Not so bad at all -- computers are really fast these days. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Cirrus SR20 Model?
Curtis L. Olson writes: If it helps motivate someone, he might be able to come up with a small amount of $$$ to do the job, but in this case, if he's spending his own money, he wants to own the result. soap box I suggest mentioning the Free as in beer analogy might get the itch solved more quickly Or that someone interested in building this model might consider a dual license for it eg Free for Open Source programs but a Commercial license for commercial programs /soap box Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Tile manager customization
Hi people, I wonder if today, there is a way to customize the tile manager in preferences. Is it possible to set the number of tiles to load around view position ? The covered area to load ? Could somebody explain me the tile loading/queuing policy ? Thanks in advance. David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tile manager customization
BONNEVILLE David wrote: Hi people, I wonder if today, there is a way to customize the tile manager in preferences. Is it possible to set the number of tiles to load around view position ? The covered area to load ? Could somebody explain me the tile loading/queuing policy ? Thanks in advance. Hi David, The system is based off the visibility distance. The tile manager can compute the size (width x height) of a tile at the current location. Then it computes how many tiles vertically and horizontally it needs to load to cover the specified visibility distance completely. Then it sends a series of tile load requests to the tile loader thread. It starts out by requesting the current center tile, then it requests the first concentric square ring of tiles (3x3 minus the center tile). Then it requests the second concentric square ring (5x5 minus the 3x3 minus the center) and proceeds until all needed tiles have been requested. The loader thread checks the tile cache to see if a tile is already loaded or not. If not already loaded, it dumps an old tile out of the cache and starts loading the new one. The system is quite complex because we wanted to impliment the tile loading as much as possible in a seperate thread. But there are many unfortunate constraints with opengl and plib so we ended up with a hybrid that does some work in the tile loader thread and some work in the main thread. And as is usually the case with real world threads, there are a lot of really subtle and difficult interactions that must be considered. So if you poke around in that section of the code, please tread very carefully because any seemingly innocuous change, could blow up the whole thread interaction scheme (or introduce bugs that occur rarely and are very difficult to track down.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
From: Curtis L. Olson Jim Wilson wrote: You might want to talk to her/him about offering a bounty. What is really intended with the owned model? Selling it? Folks should beware of giving up their copyright for smallish fees, you may regret it later when you want to reuse some of your own work. It's not nearly that evil. This person has a software product they plan to bring to market soon. They want to interface their product to a stock version of FlightGear to add an optional 3d visualization component. It's not required but increases the coolness factor. The software product relates to the Cirrus SR20. Oh no, evil is quite a bit stronger than what I meant to say. I was just trying to differentiate between the emotional part of ownership and the logical part that asks how many copies could you realistically expect to sell anyway? The part about beware of giving up your copyright is really a completely different issue and I can see now it should've been written more clearly separated from the first comment. So it would be nice from their perspective (bot not necessary) to have the Cirrus SR20 modeled. They don't plan to sell the model. Their main focus is to sell their own software. A nice add on feature is it's ability to interface to FlightGear. And even nicer (for them) would be if FlightGear had an SR20 model. It sounds to me like a perfect candidate for a bounty approach. Generally bounties will get the poster more for their money, it definitely enhances a business's image and goodwill when it contributes something directly back to the community, and finally as you mentioned it isn't really critical to the overall product so why not GPL it? This is just my (hardly) 2 cents worth. :-) Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tile manager customization
Thanks Curt, I think I understand the policy. Is the visibility distance really what we can see ? I mean is there a real relation between the /sim/visibility and the far plane of the view frustum ? David Hi David, The system is based off the visibility distance. The tile manager can compute the size (width x height) of a tile at the current location. Then it computes how many tiles vertically and horizontally it needs to load to cover the specified visibility distance completely. Then it sends a series of tile load requests to the tile loader thread. It starts out by requesting the current center tile, then it requests the first concentric square ring of tiles (3x3 minus the center tile). Then it requests the second concentric square ring (5x5 minus the 3x3 minus the center) and proceeds until all needed tiles have been requested. The loader thread checks the tile cache to see if a tile is already loaded or not. If not already loaded, it dumps an old tile out of the cache and starts loading the new one. The system is quite complex because we wanted to impliment the tile loading as much as possible in a seperate thread. But there are many unfortunate constraints with opengl and plib so we ended up with a hybrid that does some work in the tile loader thread and some work in the main thread. And as is usually the case with real world threads, there are a lot of really subtle and difficult interactions that must be considered. So if you poke around in that section of the code, please tread very carefully because any seemingly innocuous change, could blow up the whole thread interaction scheme (or introduce bugs that occur rarely and are very difficult to track down.) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
On Wed, 20 Jul 2005 20:38:39 -0500, Curtis wrote in message [EMAIL PROTECTED]: This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. ..he who pays can _both_ own his paid-for SR20 and have us distribute it for him under the GPL. Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. :-) ..one of them could be spend more time explaining copyright law enforcement and the GPL to him, he either misses RMS' copyright law enforcement scheme behind the GPL, or he pretends to, like the SCO Group in Lindon, Utah. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
Arnt Karlsen wrote: On Wed, 20 Jul 2005 20:38:39 -0500, Curtis wrote in message This could go two possible directions. If someone wants to volunteer to do this, it could be contributed to FlightGear for everyone to enjoy. The person requesting this might also be able to pay some smallish amount (yet to be determined) to have this done, but if he pays for it, he wants to own the result for his own use, and it couldn't be contributed to flightgear.. ..he who pays can _both_ own his paid-for SR20 and have us distribute it for him under the GPL. sigh I'm not sure if it's worth the bother to reply here /sigh But he who pays for something to be developed can do whatever he wants with it. In this case if he pays for the model's development, he doesn't want to give it away to everyone for free. That's his right and his choice to make. If someone is developing something on their own, they can dual, triple, quadruple license it however they want, but if they want to do an open-source + commercial license, they are going to have to find someone to buy it commercially, and if it's already available as open-source, why should someone pay for it? And there may be answers to that retorical question, but in this specific case, if there's already an SR20 model in FlightGear, why would this guy want to pay for it? Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. :-) ..one of them could be spend more time explaining copyright law enforcement and the GPL to him, he either misses RMS' copyright law enforcement scheme behind the GPL, or he pretends to, like the SCO Group in Lindon, Utah. None of this last paragraph seems to make any sense in the context of this discussion. I'm not sure how useful it is to launch into a GPL/RMS/Groklaw/SCO rant every time the word commercial passes across your computer screen, especially when your comments don't seem to make any logical sense or have any connection to the topic at hand. Sorry if that sounded harsh, but I could be having a stressful day here or something like that. :-) Apparently no one is interested in doing a Cirrus model for FlightGear at this time, which is fine, I was just asking, and just presenting a couple different options for getting it done. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
Josh Babcock wrote: All you have to do is drop the file in $FG_ROOT/Nasal and set /sim/headshake/enabled='true' by the method of your choice. Then shake, shake, shake! Be sure to read the file for known bugs, and please, send me lots of comments. This is really cool. If you want to try another trick, how about a lag filter on orientation changes. My experience in lightplanes is that (for example) yaw oscillations feel like the plane is yawing around me and not that my viewpoint is shifting left and right. It might be cool if the head took a fraction of a second to catch up to the aircraft orientation. This might look cool, or it might cause nausea. But it would be fun to find out. Another thing that comes to mind is that at high accelerations, head orientation is coupled to acceleration -- bounce the plane hard and the head tilts forward, or to the side, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
Andy Ross wrote: Josh Babcock wrote: This is really cool. If you want to try another trick, how about a lag filter on orientation changes. My experience in lightplanes is that (for example) yaw oscillations feel like the plane is yawing around me and not that my viewpoint is shifting left and right. It might be cool if the head took a fraction of a second to catch up to the aircraft orientation. This might look cool, or it might cause nausea. But it would be fun to find out. I'm actually already planning this. However, it will be more closely coupled to the code I am writing to lock the view to a particular direction. Another thing that comes to mind is that at high accelerations, head orientation is coupled to acceleration -- bounce the plane hard and the head tilts forward, or to the side, etc... Again, I was considering this, and will probably implement it. Again, because there is currently no way to have an arbitrary number of deltas to the position and orientation of the view, I can't do it without closely integrating it with any existing code that manipulates these things. If you are interested, I could really use some C++ code to that effect, it is the biggest problem I have run into with both this and the locked view code. Let me know if you are interested in exactly what I envision. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cirrus SR20 Model?
From: Curtis L. Olson But he who pays for something to be developed can do whatever he wants with it. In this case if he pays for the model's development, he doesn't want to give it away to everyone for free. That's his right and his choice to make. Exactly, so long as the developer agrees of course. And in this particular case developers need to be aware that they cannot transfer rights to any existing submodels, textures or other components that might be borrowed from the currently GPL'd work. You can use them, of course. You just have to keep them GPL. If someone is developing something on their own, they can dual, triple, quadruple license it however they want, but if they want to do an open-source + commercial license, they are going to have to find someone to buy it commercially, and if it's already available as open-source, why should someone pay for it? And there may be answers to that retorical question, but in this specific case, if there's already an SR20 model in FlightGear, why would this guy want to pay for it? Feel free to contact me off-line if you like. If more than one persons responds, I guess I need to reserve the right to make some hard decisions. ..one of them could be spend more time explaining copyright law enforcement and the GPL to him, he either misses RMS' copyright law enforcement scheme behind the GPL, or he pretends to, like the SCO Group in Lindon, Utah. None of this last paragraph seems to make any sense in the context of this discussion. I'm not sure how useful it is to launch into a GPL/RMS/Groklaw/SCO rant every time the word commercial passes across your computer screen, especially when your comments don't seem to make any logical sense or have any connection to the topic at hand. Sorry if that sounded harsh, but I could be having a stressful day here or something like that. Could be? lol! Yeah that word is a hot button on an open source mail list. Kind of like saying choice at a Catholic bible group. Oh and before this comment triggers yet another flaming diversion: I can say these things because I am what you might call a recovering Catholic. Geez...now I'm in trouble! Apparently no one is interested in doing a Cirrus model for FlightGear at this time, which is fine, I was just asking, and just presenting a couple different options for getting it done. If no one steps up then I might take a stab at it next year. It does look like a great project and would encourage anyone interested in 3D modeling to give it a go. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
OK, now there's a version with a simple low pass filter implemented. Also, some more tuning went on. If your view seems to be in an odd place with this file, grab the latest CVS, there is a nasal string handling bug fix in there (thanks Andy). Without it, any minus signs in the viewpoint coordinates get lost :( Or the fast fix: 19:04:34 andy OK, Josh. There's a fix in SimGear CVS now. You'll just need to rebuild your libsgnasal.a library and relink flightgear. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] T38 and other aircraft xml files overwrite scenario settings
Today i found out, that using the T38 overwrites other scenario settings which are set in the preferences.xml file. The cause for that was the refuling scenario which was set in the T-38-set.xml file.That shouldn't be done that way. Scenarios should never be set in the aircraft's xml files. All scenarios that are set in the aircraft's xml files should get removed by default. At the moment scenarios are set in the following aircraft related xml files: Hunter/hunter-2tanks-set.xml: scenarioship_demo/scenario OV10/OV10-set.xml: scenariothunderstorm_demo/scenario T38/T38-set.xml: scenariorefueling_demo/scenario sgs233/sgs233-set.xml: scenariothermal_demo/scenario The reason to remove them is, that it's not a good idea to set them in the aircraft files when they overwrite other scenario settings that are set in the user specific preferences.xml file. Imagine that someone wants to use the sgs233 glider and fly around over the Alps. What does he do? He will create a new scenario demo file to have thermals over the Alps and activate this new scenario demo file, like it should be done in the preferences.xml file. But what happens when he starts flightgear and fly around over the Alps? He will not be able to notice the thermals over the Alps because the thermal_demo scenario that is set in the sgs233-set.xml file will overwrite every other scenario, including the Alps thermal demo scenario. Conclusion: It is bad behaviour to define scenarios in the aircraft xml files. And it is from an usability standpoint error-prone and a bad idea. Another reason to remove them is, when we take the sgs233 file again as an example: Why does someone want to have thermals over KSFO when he wants to fly over the Alps? That makes no sense. Scenarios allways depend on locations, but aircrafts are location independent. That's another reason why scenarios shouldn't be set in the aircraft xml files. Then i have another question: Is it possible to make flightgear be able to use more than one scenario demo file at the same time? This would be a nice feature, because it would allow us to make demo scenarios part of the scenery. Think about a ferry that allways drives from dover to calais and back, this could be made part of the scenery w010n50 as a local default scenery scenario. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] T38 and other aircraft xml files overwrite scenario settings
Today i found out, that using the T38 overwrites other scenario settings which are set in the preferences.xml file. It's been like that for over a year. Scenarios should never be set in the aircraft's xml files. Unless the aircraft is demonstrating an AI capability. Hunter/hunter-2tanks-set.xml: scenarioship_demo/scenario OV10/OV10-set.xml: scenariothunderstorm_demo/scenario Thunderstorm and weather radar demo T38/T38-set.xml: scenariorefueling_demo/scenario Refueling and air-air radar demo sgs233/sgs233-set.xml: scenariothermal_demo/scenario Thermal demo The reason to remove them is, that it's not a good idea to set them in the aircraft files when they overwrite other scenario settings that are set in the user specific preferences.xml file. Unless the user(s) aren't aware of the capabilities demonstrated in this way. Imagine that someone wants to use the sgs233 glider and fly around over the Alps. What does he do? He will create a new scenario demo file to have thermals over the Alps and Not in my experience. What he'll do is complain that FlightGear doesn't have any thermals and that it sucks compared to any other sim. Why does someone want to have thermals over KSFO when he wants to fly over the Alps? That makes no sense. See above. Is it possible to make flightgear be able to use more than one scenario demo file at the same time? No. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
