[Flightgear-devel] Multiplayer crashes with unknown aircrafts, any solution?
Hi, I was playing with Oliver Schroeder's multiplayer FGFS server. I like this stuff :-) But FGFS crashes every time a new user joins the server with an aircraft which is not in my dir tree. The problem is common to many people who used this multiplayer mode. Is there any chance we can get a new binary with a workaround? The problem is really annoying because very many people use aircrafts which do not belong to the base distribution so the crash happens very often. Thx, Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
* Roberto Inzerillo -- Friday 15 July 2005 11:04: But FGFS crashes every time a new user joins the server with an aircraft which is not in my dir tree. The problem is common to many people who used this multiplayer mode. Is there any chance we can get a new binary with a workaround? The binary workaround can be downloaded here: http://www.flightgear.org/Downloads/aircraft/ m. :-} ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Melchior FRANZ ha scritto: * Roberto Inzerillo -- Friday 15 July 2005 11:04: But FGFS crashes every time a new user joins the server with an aircraft which is not in my dir tree. The problem is common to many people who used this multiplayer mode. Is there any chance we can get a new binary with a workaround? The binary workaround can be downloaded here: http://www.flightgear.org/Downloads/aircraft/ m. :-} Of course, Melchior ... I know :-| But this solution doesn't fit to this specific problem. FlightGear will crash _before_ I know which http://www.flightgear.org/Downloads/aircraft/ I need to download! Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? R. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Andy Ross Vivian Meazza wrote: You certainly are! The Boost Control works by adjusting the _throttle_ (in accordance with reality and your earlier suggestion). Why not just use a solution setting that doesn't involve the boost control cutout? Why? The Merlin has a Boost Control Cutout, and the code works. But you are still confused - the Boost Control replaces the function of the misnamed wastegate, controlling the manifold pressure by retarding the throttle. This was your proposal which I implemented with Melchior's assistance. I'd think that a flat out solution would be most likely wrong anyway -- that's where engines are going to vary the most between installations. Choosing anything at the edge of a performance envelope and expecting the conditions to hold in the middle is always problematic. What's wrong with using a cruise value for the cruise solution? I do use the cruise value - based on the full throttle altitude. It's fine. YASim provides a good solution. Very impressive. The patch in my previous email, combined with your recent cvs input does all that is required, both now and in preparation for the supercharger/turbo charger thing. If you can suggest a way of doing it using the existing code, then I'm listening. As I read it, though, your patch is currently a noop. All it does is add a new configuration option and adjust the handling of the wastegate in a way that will never make a difference in practice (skipping the wastegate handling for superchargers is irrelevant -- supercharged engines already have a very high wastegate setting that cannot be reached by an engine, running or not). I'm afraid that you are quite, quite wrong here. Supercharged engines do not have a high wastegate setting, and it is readily reached by the running engine over much of its operating range. This is what the full throttle height means. The Merlin's Boost Control operates from sea level up to the full throttle height, which can be up to 22,000ft depending on model. I'm not arguing against it in principle. I'm just saying that I'm going to wait until we have a real issue that needs to be solved; using the _running boolean (which just indicates whether fuel is being burned) Actually it means that the magnetos are O and engine rpm 60, but of course you know that. But I'm going to revisit this. is not the right mechanism long-term. Can you explain again, really carefully, exactly what behavior this patch gives you that you need right now? This patch does the following: a. ensures that the manifold pressure is ambient when the engine is not turning. b. allows a windmilling engine to develop supercharger/turbo pressure c. skips the wastegate if the parameter 'supercharger' is true so that the Boost Control function which _you_ suggested be written (in Nasal), and which Melchior and I spent several days writing and tuning, can operate instead of the wastegate function. d. It allows accurate data to be used in the wastegate parameter. While the wastegate function is skipped, the wastegate parameter still has to be entered accurately to allow YASim to solve properly. This patch really is needed to allow the Merlin engine simulation to work properly. With it in place it is possible to plug in the numbers from the contemporary performance curves and get a simulation which closely matches the published figures. I'm going to try to do some work on Josh's B29 engines next. Hope this answers all your queries. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Robicd wrote: Melchior FRANZ ha scritto: The binary workaround can be downloaded here: http://www.flightgear.org/Downloads/aircraft/ Of course, Melchior ... I know :-| But this solution doesn't fit to this specific problem. Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Robicd wrote: Of course, Melchior ... I know :-| But this solution doesn't fit to this specific problem. FlightGear will crash _before_ I know which http://www.flightgear.org/Downloads/aircraft/ I need to download! Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? It would make sense to default to using the glider model if the correct one can't be found. Otherwise anyone connecting to such a server with an aircraft they're developing presents the other users with something of a problem (ignoring the obvious DoS aspect if someone wanted to be malicious). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Other aircraft showing on radar would be excellent. I've been playing with the t38 refuelling scenario recently, and it's a lot of fun - definitely teaches you the value of minute stick and throttle inputs :-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
* Robicd -- Friday 15 July 2005 11:31: Melchior FRANZ ha scritto: Is there any chance we can get a new binary with a workaround? The binary workaround can be downloaded here: http://www.flightgear.org/Downloads/aircraft/ Of course, Melchior ... I know :-| Just kidding. ;-) But this solution doesn't fit to this specific problem. FlightGear will crash _before_ I know which http://www.flightgear.org/Downloads/aircraft/ I need to download! That's why you install *all* of them! And fgfs doesn't really crash. It just throws an exception that is only caught in bootstrap.cxx and causes a 'regular' abort(). That's called error handling! :-) Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? I guess I fixed that in CVS. Haven't tested it, though. And I can't make binary packages ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
That's why you install *all* of them! And fgfs doesn't really crash. It just throws an exception that is only caught in bootstrap.cxx and causes a 'regular' abort(). That's called error handling! :-) Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? I guess I fixed that in CVS. Haven't tested it, though. And I can't make binary packages ... Nice to know :-) I will wait the next binary. I am looking at mpmessages.hxx since Oliver told me the UDP packet structure is in there. I'd like to try writing some code in order to get some moving models on the ground. I am not skilled with python/perl/java and so on, but I guess forging some UDP packets is not that big effort and could be made even with PHP too, right? Any hint before I start doing that in a totally wrong way? R. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Josh Babcock Vivian Meazza wrote: Josh Babcock ought to be asking for the turbo charger for the B29 now, but hasn't yet (perhaps he's now using JSBSim?). I've been unable to find much available on the web for the Wright R-3350. I'm doing some work on the aircraft carrier right now, but I've done some preparation for the turbo simulation. Nope, I've just been busy with animations and other non-fgfs stuff. I don't have much data on the R-3350-23, but I do have the pilot's manual and a lot of web sites. If someone is offering to help with the engines I would love it. I am available to give all the info I have. I don't really feel I know enough about engines to do this properly myself. If by 'someone' you mean me, then I guess I should help here. I need some thing to test my putative modifications to YASim on anyway. I need a few hard numbers, which perhaps you could give me or point me at a suitable web site/s: 1. propeller gearing. 2. max manifold pressure. 3. full throttle altitude which may also be described as the critical altitude. 4. the rated HP and the rated altitude. 5. take-off HP. 6. Copies of the relevant pages of the Pilot's Manual. Post these somewhere that I can access/fetch. Particularly any description of the variable boost control. That would be a good start. If the best data you have is already in the existing config file, then I can work with those. I take it that you YASim config file in cvs contains the right locations etc for the engines? I can re-measure, of course, but it will save time. This should be too difficult if we can get some good data. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
Vivian Meazza wrote: I do use the cruise value - based on the full throttle altitude. It's fine. YASim provides a good solution. Very impressive. Clearly I'm very confused then. You were asking for the boost control to work during solution earlier. Is that not a requirement? The cutout lever will not be used during cruise, so I can't see why that is an issue. As I read it, though, your patch is currently a noop. All it does is add a new configuration option and adjust the handling of the wastegate in a way that will never make a difference in practice (skipping the wastegate handling for superchargers is irrelevant -- supercharged engines already have a very high wastegate setting that cannot be reached by an engine, running or not). I'm afraid that you are quite, quite wrong here. Supercharged engines do not have a high wastegate setting, and it is readily reached by the running engine over much of its operating range. Blargh. I'm talking about *code* here, not aircraft. A YASim engine without a wastegate setting has a _maxMP value of 1.0e06. I assure you this is correct. I wrote it. The point being that your patch just implements current behavior in a different way. Actually it means that the magnetos are O and engine rpm 60, but of course you know that. But I'm going to revisit this. And now, yet again, you're getting snippy. Stop it. That's the *condition* for the _running boolean, not the effect. Read the code more carefully. a. ensures that the manifold pressure is ambient when the engine is not turning. OK, that's an easy fix. b. allows a windmilling engine to develop supercharger/turbo pressure But not in a realistic way. Like I said earlier, I'm going to skip this until we get a sane model worked out. c. skips the wastegate if the parameter 'supercharger' is true so that the Boost Control function which _you_ suggested be written (in Nasal), and which Melchior and I spent several days writing and tuning, can operate instead of the wastegate function. And here is where you've gotten confused. You shouldn't have a wastegate=xxx setting on your engine any more. If this is missing, like it should be, then it is automatically set to 1.0e06 and your patch, like I said, is a noop. You might like this code, but it does not behave any differently from what is in CVS. d. It allows accurate data to be used in the wastegate parameter. While the wastegate function is skipped, the wastegate parameter still has to be entered accurately to allow YASim to solve properly. But you said earlier that you are using a *cruise* configuration in the solver. The cutout lever is not used during cruise. So I simply don't see how this is a problem. We're about to go in circles again, and my blood pressure is rising. So try this: DON'T reply to my message paragraph by paragraph. Start from scratch, post a configuration file that you want to use that does not work. Explain why. Use numbers. Ask for suggestions. Don't touch the C++ code until you have convinced me of what you want to do. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New super/turbo MP code is in
I wrote: We're about to go in circles again, and my blood pressure is rising. So try this: DON'T reply to my message paragraph by paragraph. Start from scratch, post a configuration file that you want to use that does not work. Explain why. Use numbers. Ask for suggestions. Don't touch the C++ code until you have convinced me of what you want to do. OK, I gave this some thought on the train on the way to work, and I think I understand now what you are trying to say: the cutout system is Nasal-based, and won't run during solution. It also engages during the specified cruise parameters, something that I was expecting it would not*. So you want to use the wastegate setting as a proxy for the boost control, but you are stymied because if you use the wastegate, it then becomes active at runtime. * Are you sure it does? The boost control will be actively modifying the throttle at low altitudes and high throttle settings. Cruise is generally at high altitude and middle throttle. My guess is that it would *not* be active, honestly. High performance cruise is what the engine was tuned for -- the boost control is there to prevent it from damaging itself in non-optimized situations. Does that sound like what you want? If so, then I argue that the way to do this is to map a property input to the wastegate pressure. You can then use an otherwise-unused property to set it to whatever value you want for solution, and leave it at a very high value in the property system for runtime usage. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Melchior FRANZ wrote: Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? I guess I fixed that in CVS. Haven't tested it, though. And I can't make binary packages ... Here is one : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20050715.zip As always, it may need an up-to-date ( I mean CVS ) base package. Just try it and report success or failure. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? I guess I fixed that in CVS. Haven't tested it, though. And I can't make binary packages ... Here is one : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20050715.zip As always, it may need an up-to-date ( I mean CVS ) base package. Just try it and report success or failure. -Fred Thx Fred, it works with distribution package too but ... is keypad working differently now? I was used holding down Pag-Up key for increasing RPM, now I have to push it several time in order to increase RPM step by step; I can't get it increasing by simply holding down the key. Is this behaviour related to the new binary or something I am missing? Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Frederic Bouvier ha scritto: Here is one : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20050715.zip I get the following in console: WARNING: ssgSGIHeader::: Failed to open 'g:/Programmi/FlightGear/data/Textures/Sky/cl_cumulus.rgb' for reading. WARNING: ssgSGIHeader::: Failed to open 'g:/Programmi/FlightGear/data/Textures/Sky/cl_stratus.rgb' for reading. WARNING: ssgLoadAC: Failed to open 'g:/Programmi/FlightGear/data/Aircraft/c172r/Models/c172-dpm.ac' for reading That's because I used 0.9.8 base package and it misses those things. It works anyway. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
* Robicd -- Friday 15 July 2005 20:35: I was used holding down Pag-Up key for increasing RPM, now I have to push it several time in order to increase RPM step by step; I can't get it increasing by simply holding down the key. Is this behaviour related to the new binary or something I am missing? Yes, you are missing the base package. Keys are now only repeatable if repeatable is actually set for this key in $FG_ROOT/keyboard.xml. There was a bug before that did always enable autorepeat. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
On July 15, 2005 01:25 pm, Frederic Bouvier wrote: As always, it may need an up-to-date ( I mean CVS ) base package. Just try it and report success or failure. -Fred There were some problems related to multiplayer reported by CVS users yesterday. Specially, regardless of other planes actual position, they are all jammed around the CVS users' camera. People who use the original 0.9.8 don't experience this problem. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Yes, you are missing the base package. Keys are now only repeatable if repeatable is actually set for this key in $FG_ROOT/keyboard.xml. There was a bug before that did always enable autorepeat. How should I set this property for a key? Something like what follows? key n=360 namePageUp/name descIncrease throttle or autopilot autothrottle./desc repeatableyes/repeatable ... /key I tried that, it doesn't work, I get: Error reading properties: mismatched tag at g:/Programmi/FlightGear/data/keyboard.xml, line 1134, column 3 What's the correct syntax? Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
* Ampere K. Hardraade -- Friday 15 July 2005 21:06: There were some problems related to multiplayer reported by CVS users yesterday. Specially, regardless of other planes actual position, they are all jammed around the CVS users' camera. Uneducated guess: Mathias' tile center stepping patch (fix for jitter problem) broke the multiplayer position setting. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
* Robicd -- Friday 15 July 2005 21:17: key n=360 namePageUp/name descIncrease throttle or autopilot autothrottle./desc repeatableyes/repeatable ... /key Error reading properties: mismatched tag at g:/Programmi/FlightGear/data/keyboard.xml, line 1134, column 3 What's the correct syntax? The syntax is correct in what you posted. But apparently not in your file. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Andy Ross I wrote: We're about to go in circles again, and my blood pressure is rising. So try this: DON'T reply to my message paragraph by paragraph. Start from scratch, post a configuration file that you want to use that does not work. Explain why. Use numbers. Ask for suggestions. Don't touch the C++ code until you have convinced me of what you want to do. OK, I gave this some thought on the train on the way to work, and I think I understand now what you are trying to say: the cutout system is Nasal-based, and won't run during solution. It also engages during the specified cruise parameters, something that I was expecting it would not*. So you want to use the wastegate setting as a proxy for the boost control, but you are stymied because if you use the wastegate, it then becomes active at runtime. Yes, good old train. Nearly right, except we now have a Boost Control (nasal) which replaces the function of the wastegate. The Boost Control Cutout is part of this implementation. This is just terminology - your analysis is correct. We no longer need a wastegate for the supercharger (and only the supercharger - not the turbo), but have to have an accurate 'wastegate-mp'(perhaps we should call it max-mp) setting so that YASim solves correctly. * Are you sure it does? The boost control will be actively modifying the throttle at low altitudes and high throttle settings. Cruise is generally at high altitude and middle throttle. My guess is that it would *not* be active, honestly. High performance cruise is what the engine was tuned for -- the boost control is there to prevent it from damaging itself in non-optimized situations. Yup. Absolutely sure - we have curves of boost against altitude at max power rpm which show exactly at which altitude the Boost Control stops operating for most of the Merlin variants. This altitude is called the full throttle altitude. So we set the cruise values at the full throttle altitude. We know exactly the relevant data at this point. With a bit of experimentation we can derive an accurate turbo-mul parameter and everything falls into place for the full speed supercharger gear ratio, including non-full throttle settings. We also have full throttle altitudes for the medium speed supercharger gear, so we can experiment further to get the right number for the lower boost setting. The combat power also falls out along the way when the Boost Control Cutout is operated. We have a very good simulation at the cost of very little effort or code. Does that sound like what you want? If so, then I argue that the way to do this is to map a property input to the wastegate pressure. You can then use an otherwise-unused property to set it to whatever value you want for solution, and leave it at a very high value in the property system for runtime usage. I'm not sure about this on 3 counts: 1. Does Nasal initialise before YASim runs the solver or after? 2. I'm not clear what you mean by an otherwise-unused property 3. We have a perfectly good solution in C++ already. As you have said we will need the supercharger Boolean when we need to differentiate between gear-driven superchargers and turbos. This is nigh, because Josh has reached the point where he would like to do the B29 turbo-charged engines. We (I that is) will shortly be testing a more appropriate curve for turbo output pressure v rpm. It would also be highly desirable to fix the ambient pressure at zero rpm and the windmilling outputs. The diff does this, albeit I realize that you consider it imperfect, it is better than that in cvs right now, and would surely do as a temporary fix until you can find the time to come up with something better. The diff certainly doesn't break anything. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
On July 15, 2005 05:41 am, Erik Hofman wrote: Looking at the Multiplayer code I can see this code can use a good overhaul anyway. It needs to adapt the SGSubsystem style and use the AIModel code to display the models, which will also allow it to show up on the radar. It's probably not too much work to do since most of the current code could be reused. Erik I think it will be more flexible if the networking portion of FlightGear can be modified to exchange properties. For starter, the nodes /accelerations, /positions, and /surface-positions can be exchanged among users. Properties under /accelerations can allow one client to interpolate the position of others, thus eliminating jitters. Properties under /position are basically what being exchanged right now. As to /surface-positions, the properties inside this node can allow one to see the animations of others correctly. To make this even more flexible, one can include a XML file under each aircraft's folder to specify what nodes/properties should be exchanged during online sessions. To cut down the amount of data being sent/received, a client only have to broadcast the above nodes once, and resend individual properties when needed. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
key n=360 namePageUp/name descIncrease throttle or autopilot autothrottle./desc repeatableyes/repeatable ... /key Error reading properties: mismatched tag at g:/Programmi/FlightGear/data/keyboard.xml, line 1134, column 3 What's the correct syntax? The syntax is correct in what you posted. But apparently not in your file. m. My mistake. You are right. The error went out when I didn't properly close the repeatable tag. Anyway, with the correct above syntax nothing happens and key Pageup doesn't repeat at all. Maybe I really need more then the updated binary provided by Fred to make it work. Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
