[Flightgear-devel] Seamless noise distributions
I'd like to ask for a few opinions. The problem: Vertex shader coordinates are continuous only within a terrain tile, so the noise distributions we use show discontinuities across terrain tiles - seen most prominently in snow or fog patches. The solution: Emilian and Fred have figured out a way to transform vertex coordinates to global world coordinates - these are contiinuous across tiles, so we can use those. The fine-print: The numerical accuracy of world-coordinates is limited and much worse than tile-internal coordinates - which means that, dependent on system and implementation details, they can't be used for noise below a 25 m - 5m scale, i.e. to generate fine-grained noise we still need the local tile-internal coordinates. In addition, there's no set of 2D coordinates which doesn't have distortions and covers Earth seamlessly, so noise lookup in world coordinates has either other discontinuities (i.e. is valid at startup only and noise 'jumps' every 1000 km of flight, or is valid at startup but looks weird after 8000 km,...) or it needs to be 3D noise. Now, 3D noise is quite a bit more costly than 2D noise - if done by texture, memory consumption goes resolution ^3 instead of resolution ^2, if done by function it's a bit more than double the computational load of 2d noise (2d Perlin noise needs 4 random numbers and 3 interpolations, 3d Perlin noise needs 8 random numbers and 7 interpolations). The bill: In order to make this work, we'd need an additional varying vec3 to transport world coordinates in every shader in addition to the varying vec2 to transport local tile coordinates, and convert the low frequency noise to 3D computations, doubling their computational load. This has to be in every terrain shader to avoid fog discontinuities across different effects. There's a lot of other eye candy that can be generated for this pricetag. So what I'd like to know is - what are the current concerns - performance, the seams, something else ...? I think based on my tests I could implement the seamless noise scheme as above, but it'd slow things down by probably 25% on many systems. Opinions - should we be doing this? * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Is it possible to extrat a Independent cockpit module ?
Hi everyone: I'm involved in a ship driving simulation project which use many digital dashboard panels like these in flightgear cockpit. It is expensive to develop a new digital dashboard module, so i would like to know if it is possible to extrat a Independent cockpit module from flightgear for my ship driving simulation project? Landon 2013.1.20 -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: release branches are ready,
Hi, On Thursday, January 17, 2013 20:23:23 Torsten Dreyer wrote: Done. Version 2.10.0 now lives on the release/2.10.0 branches on SimGear, FlightGear and FGDATA to be released around the 17th of February. SimGear and FlightGear next branches as well as FGDATA master branch are now on version 2.11.0. These branches are again open for regular development. Thank you all for adhering to our feature freeze policy. Curt, James, ThorstenB and Tat: Please create our first release candidate as soon as possible to give many users without source code compile expertise the chance to test our new version. Thanks! Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Thursday, January 17, 2013 16:31:57 Renk Thorsten wrote: For example here on an nvidia 8800GT with 313.09 linux driver I have: MAX_VERTEX_UNIFORM_COMPONENTS 4096 MAX_FRAGMENT_UNIFORM_COMPONENTS 2048 Nevertheless, that would make 50 seem a rather harmless number. Especially when I'm going to assume that no one with a much older card will be able to run a shader with 6 overlay textures in anything resembling a usable framerate anyway. So I will for the time being consider a number of below 100 uniforms harmless, and we can change strategy once actual problems crop up. Any objections? Yes. Any uniform needs to be handled by the driver. And any of them takes cpu cycles to load. I think having lots of them is one factor that accounts for the long draw times I see here. Looking at profiles the function collecting them and putting it into a buffer for use in the gpu is always in the top 5 functions on the cpu where exactly this takes a lot of cpu time. So, just putting a lot of uniforms somewere because the maximum allowed number is so far away is not a good idea. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Slave flightgear as external view to monitor traffic
Hi, On Saturday, January 12, 2013 12:03:07 Wolfram Wagner wrote: We have the idea to use flightgear to display the external view onto the airport for OpenRadar. (OpenRadar Version 2) This is something that would add a necessary grade of realism and would make ATCing more attractive. As it is possible to use flightgear as view slave for another fg instance, this seems to be possible. I think I need an invisible airplane, position it a the tower position and tell it, where to look to. Is there a documentation that helps me? I guess there is a protocol that I have to use, once I have started the flightgear instance. As of today, you can send some udp messages and run flightgear with the external fdm. That's a pretty simple packet format. Details better looked up into the code. I believe Erik has at some time added a more flexible packet format that is also able to set some properties and freely configurable. Details from him. And finally fgviewer is not at the point where this is already usable as the viewer is not complete and the code I am talking about is not yet in a usable state. But If you have just a single configured viewpoint this already works by adding the apropriate hla objects and attaching the viewer to them. In the long term this is probably the viewer to use as it is designed to be used in an environment like this. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.0 Changelog - help required
Hi Stuart, On Friday, January 18, 2013 00:04:35 Stuart Buchanan wrote: 1) Are there any significant features/enhancements that have been missed? (Matthias: what HLA enhancements have been made, and can you provide a couple of suitable sentences describing them? I'm happy to wordsmith any text) Well, nothing user visible I think. There is a lot of private code pushed into the repositry, and at some point this tied together will make a lot of sense I think. But up to now just a lot of loose ends. What is there is a sketch of an AI module working on top of hla objects, this sketch also shows how you can roll on ground - at least for solid ground. Also fgviewer gained a lot of unfinished hla code that enables fgviewer to sit on a hla configured view - more or less. At least a python script that I regularily use for development providing this works fine. Together with fgviewer there is also some work done on the scenegraph that is used there. fgviewer is since some time just able to display a whole world paged model that has the stg/btg files in the leafs. With this work there is also some level of detail work done in the leaf nodes that is used by the usual fgfs scene. On my setups here these changes accounted for some performance gains which are also partly visible with fgfs. So not sure if this is worth to be mentioned as there is nothing finally useful for an end user there. Greetings and thanks for collecting this. Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
Yes. Any uniform needs to be handled by the driver. And any of them takes cpu cycles to load. I think having lots of them is one factor that accounts for the long draw times I see here. Looking at profiles the function collecting them and putting it into a buffer for use in the gpu is always in the top 5 functions on the cpu where exactly this takes a lot of cpu time. So, just putting a lot of uniforms somewere because the maximum allowed number is so far away is not a good idea. Well, that wasn't quite the question. I know that having lots of uniforms is more expensive than not having lots of uniforms. But if I want to have 10 different hues of rock - is it preferable to create 10 different rock textures and manage those, or is it better to have one rock texture and a uniform vec3 for each? Likewise, if I have to decide between running 5 different shaders or one shader taking two uniforms to configure its action - what is more efficient (leaving aside the fact that just having one is vastly more maintenance-friendly). * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bucket change
Hi, like already negotiated with the scenery guys, I have now pushed a change to the bucket tiling at the poles. The current scenery does not handle these cases well anyway, the tiles there look very much broken. So, there is not much lost in the current state by this change. The scenery guys promised me that the next scenery build is nearing, so the hope is that they will pick up this change and we get by that a whole world scenery without holes, even including the 2 degrees around the poles. In any case this is at the very beginning of the development cycle so that problems arising from this change should have enough time to be iterated out before the next release. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
On Sunday, January 20, 2013 14:44:17 Renk Thorsten wrote: Yes. Any uniform needs to be handled by the driver. And any of them takes cpu cycles to load. I think having lots of them is one factor that accounts for the long draw times I see here. Looking at profiles the function collecting them and putting it into a buffer for use in the gpu is always in the top 5 functions on the cpu where exactly this takes a lot of cpu time. So, just putting a lot of uniforms somewere because the maximum allowed number is so far away is not a good idea. Well, that wasn't quite the question. I know that having lots of uniforms is more expensive than not having lots of uniforms. But if I want to have 10 different hues of rock - is it preferable to create 10 different rock textures and manage those, or is it better to have one rock texture and a uniform vec3 for each? Likewise, if I have to decide between running 5 different shaders or one shader taking two uniforms to configure its action - what is more efficient (leaving aside the fact that just having one is vastly more maintenance-friendly). Well, if you ask in that way, then the question is: Do we need 10 different flavours of rock? If your question means: if procedural textures are good or not. I think that this is worthwhile to have and make a lot of sense. But I expect that for a very long time this will probably just look like bad chewing gum as realistic materials are a lot of work to make them look good. It's normal that this takes time and that it looks wierd in the first place. As always if this is optional I am fine with that. I still think that a traditional fixed function renderer has its applications in certain areas. We had a sufficiently good lookin one there and if this would have been preserved this would still be applicable where it was sufficient. And please finally teach your mailer not to drop the reply reference! ... if you write just one less of these lenghty mails you should be able to find that knob. Thanks! Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Joystick THRUSTMASTER Hotas X: I have a problem of installation
Good morning, I have installed 3 months ago FLIGHTGEAR Version 2.8.0.5, and it works very well. I usually play with keyboard and mouse. Now I bought the joystick THRUSTMASTER Hotas X (joystick + throttle), but I have a problem to use it with FLIGHTGEAR. The joystick is correctly recognized by my system (Microsoft VISTA), and I can see in the Control Panel of VISTA that it works well. The joystick is also correctly recognized when I start FLIGHTGEAR : in Help-Joystick informations, the name and model of the Joystick is correct, and if I move the joystick (the joke or the throttle), the value displayed of the correspondent axis changes according with the movement. The problem is the point of view: when I start FLIGHTGEAR, and I select the cockpit view, the point of view is not steady forward, but it immediately rotates to the extreme left (almost to the back of the aircraft). All the movements of the joystick are transmitted correctly to FLIGHTGEAR (joke up and down, left and right, throttle up and down and so on), but I can't drive the aircraft. The point of view returns forward in the cockpit only if I push the big red button on the joystick, but in this way I have the brake on! I tried to push other buttons on the joystick, but I can't get over the problem. Anyone can help me? Thanks in advance, and best regards Stefano Piccoli -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Color-shifts for textures
Well, if you ask in that way, then the question is: Do we need 10 different flavours of rock? If we want to look a scene roughly as it would in the location, the answer is yes - volcanic rock on Hawaii looks very different from Alpine rock in France. Rock in Iran looks very different again. If we're happy with one recognizable generic fast-rendering look for Flightgear, the answer is no. Personally I'm in the first camp. The problem is that there's always somebody unhappy. People are unhappy because the base package download size is large, so we'd not want any more textures. People are unhappy because FG doesn't look like FSX, so we'd want better texturing. People are unhappy because framerates are bad, so we'd want less GPU load. People are unhappy because insert name of game here has grass moving in the wind and FG has not, so we'd want more fancy effects. I'm trying to sort the reasonable from the unreasonable here and to identify genuine problems before they occur. The point is - less uniforms, more distinct textures render faster. Any rendering load can even be optional. What can not be optional is the size of your base package once I start adding textures to it. So it's a question of pain because a scene looks bad vs. pain because of large download vs. pain because of high performance needs. And please finally teach your mailer not to drop the reply reference! ... if you write just one less of these lenghty mails you should be able to find that knob. This goes via a webmail interface that is managed by my University's beloved IT department - please don't ask me any more, or I would tell a few really good stories... Suffice to say, it doesn't seem possible to do. In the overall scheme of things, this is a minor annoyance... * Thorsten -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] CI server
Hi Sorry for that and I don't want to shout loud about anything (mostly), but after some months ... is it possible to get the images back somehow on the official CI server? I mean, with all respect for whatever console, but I need to note that this server is some kind of a flag for some less well-off developers and users probably too, and beside of that ... I stop know, but really, is it possible? At least during a pre-release and release cycle? ;-) -Yves -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bucket change
Hi Mathias Does this also solve the NSZP problem, the south-pole-crossing-runway-problem now? Good news ... A lot of contemporary geodesic software has problems with this, good to hear that flightgear is walking through the last two degrees. I do not ask how this is done, this is far from whatever I could understand with such. But great! Yves Am 20.01.2013 um 15:49 schrieb Mathias Fröhlich mathias.froehl...@gmx.net: Hi, like already negotiated with the scenery guys, I have now pushed a change to the bucket tiling at the poles. The current scenery does not handle these cases well anyway, the tiles there look very much broken. So, there is not much lost in the current state by this change. The scenery guys promised me that the next scenery build is nearing, so the hope is that they will pick up this change and we get by that a whole world scenery without holes, even including the 2 degrees around the poles. In any case this is at the very beginning of the development cycle so that problems arising from this change should have enough time to be iterated out before the next release. Greetings Mathias -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.0 Changelog - help required
Hi All, I've taken a quick pass through the git logs from the last 6 months and added a selection of new/updated aircraft. I've used a somewhat arbitrary judgement about what to include, and it's likely I've missed some, particularly if there was a major update made in a single commit with an innocuous commit message :). I'd also like to have a set of images/videos illustrating the specific new features where possible. I'm thinking of something different from the screenshot contest that we usually run (Gijs - are you intending to run that again this release?), more of a gallery that goes through the various features with an image illustrating each in turn. So, if anyone has particular images to highlight their favourite new features, please get in touch. -Stuart -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.10.0 Changelog - help required
Hi, I'm thinking of something different from the screenshot contest that we usually run Usually Curt just asks for images and then Durk, I and a few others send in some shots. Last year's screenshot contest was really a special case, to celebrate FlightGear's 15th birthday. I didn't plan to run a contest for this release and as I don't have much time this week, it'd would've been to late to organize something anyway. I think the usual approach of just collecting a few shots highlighting specific new features works well. Do note that we'd like to have all shots in the same aspect ratio, so they can be put together nicely. I don't remember the exact number, but I believe it was something like 3:2. For banners, (forum, facebook, Google+) we also need a few wide images, or images that can be easily cut to a landscape size, without cutting the subject in half. Cheers, Gijs -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_123012___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Settings and Profiles
hello developers, developers developers... And one thing Tonite I realise is that we need to some get more of a grip on the launch settings for FG.. As were running an Aeronautical Simulation company we have a problem. And these problems are manfest with some .fgrc setting here and an ini there or whatever.. and mac issues.. And then an end user crashed on start and etc etc.. So being a fanboy, launch on linux and its works etc and launch on WindosxP Not and alike... So what I really want is to 1) have a some neutral terrority where we cansutall user fined things and incontrol of end user.. whatever the age.. We need to basically make all the hack visible and the config u want.. 2) We need a common format.. and for that we use the lowest common DENOMITER.. and these are thousand and millions of thise files on windows machines.. BUT main decision we take here is to make it ini.. works done tested et all.. (yaml awaits in the utf8 wing) This is would be cool.. Even an ini file in /foo.bar.skel.inican make sense.. BUT I hasten to AADD.. These are settings and INI and initialiaton and config Havive to windows == 80% of market and by value decreasting.. 3) UP the Scale.. We need to share this stuff.. Aand somehow work out and REMOVE all the inricasiez of a platfrom etc.. What is the orginal orde for example.. Suerly a command setting of viz can be overriden by a metar etc.. Dark runway in Wales.. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear Multiplayer jitter using Matlab/Simulink
Hi all, I am a starter here.I'm doing a university project. I need to control two aircrafts for close formation with two Simulink at the same time. I do as vbnhu's post in viewtopic.php?f=4t=3165p=174710#p174710http://www.flightgear.org/forums/viewtopic.php?f=4t=3165p=174710#p174710, and met the same jitter problem. One plane flies well and another jitters. fgfs --aircraft=c172p --fdm=network,localhost,5501,5502,5503 --multiplay=in,25,localhost,5701 --multiplay=out,25,localhost,5702 fgfs --aircraft=c172p --fdm=network,localhost,5507,5508,5509 --multiplay=in,25,localhost,5702 --multiplay=out,25,localhost,5701 Then, I tried the LAN fgms, There are two computers for two simulink controlled fgfs, one computer as the fgms. There is still the jitter problem. Now, I find the implementation of network control with simulink in viewtopic.php?f=36t=16200http://www.flightgear.org/forums/viewtopic.php?f=36t=16200 . I wonder if I must implement the multiplayer protocol in simulink and if the jitter problem can be avoided. Any suggestion from anybody? Thank you,all. -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
