What I could go for is:1) Total CLR/.NET integration2) (Sorry Pete), an "official" IPC module which offers an XML, C and CLR/.NET interface3) A comprehensive Modeling studio (I'll pay extra)4) At the very least, an alternative to reverse polish notation within XML gauges (God that stuff is arcane).5) A comprehensive .air file editor - this mysterious black box needs opening.6) A replacement system for the ABL (looks like there's a hint of that in the announcement).Please chime in anyone.J-

As distasteful as I find "bumps" I am hoping an MSFS team member or even some 3rd party developers might have something to say?J-

I can't say much myself, but I can say that the FS team are well aware that developers need more tools and better interface to the system.Other than that, I know no more...

>As distasteful as I find "bumps" I am hoping an MSFS team>member or even some 3rd party developers might have something>to say?I would agree with this post. Although I am extremely grateful for Pete Dowson's work. I would love to find another way than having to connect to pointers in memory to control weather features on FS9. With .net expanding so much now I would love to see this end open up a little more for the creation of real fronts, smoother transitions in weather, and really building weather. To watch a frontal boundary from the distance to grow from mere cumulus to towering terrors of thunderheads would be my dream.But maybe that might be FSXI. One can dream can't they.

1) why? The existing tools do there job just fine - ie if there is a problem, it's not because they aren't .net. I just want to have tools that get the job done, no matter which technology used.2) Firstly, I don't think .net is a very good idea at all. Bloating the C code to add VB support isn't really ideal for a real-time game. And if you only know VB chances are that you shouldn't be writing modules anyway. Modules written in XML - that's impossible. XML is a data format, not a programming language.Secondly, while I agree in principle, we don't need another link module. What we need instead is an understanding how to link into FS natively - ie like the gauges do. With a whole lot of extra info, we could write some very powerful modules. There are some problems though. No one in the team will have enough time to write some decent documentation (and pruning the include files and macros they'd have to provide). Then, there are only a handful of people who probably could make good use out of all that info. On top of that MS wouldn't want to open the program so much that anyone could do what they want (ie replace the renderer), although I don't think this would be a huge problem as even if FS would be complete open-source no-one would ever come up with something that is heavily modified and better (lack of resources). On the other hand, personally I would really like to be able to make use of some FS internals apart from gauges. I'm planning to write an article about the amazing possibilities we would have (eg adding GIS capability). Maybe the FS team could make a special 'FS internals' SDK for registered/selected developers.3) gmax / 3dsmax is good enough5) couldn't agree more. The problem again here is that we'll need a good set of documentation. There's probably only a handful of people (well, maybe two or three handful) who understand flight dynamics well enough to produce decent air files.Cheers,Christian

>1) why? The existing tools do there job just fine - ie if>there is a problem, it's not because they aren't .net. I just>want to have tools that get the job done, no matter which>technology used.>>2) Firstly, I don't think .net is a very good idea at all.>Bloating the C code to add VB support isn't really ideal for a>real-time game. And if you only know VB chances are that you>shouldn't be writing modules anyway. Modules written in XML ->that's impossible. XML is a data format, not a programming>language.>>Secondly, while I agree in principle, we don't need another>link module. What we need instead is an understanding how to>link into FS natively - ie like the gauges do. With a whole>lot of extra info, we could write some very powerful modules.>There are some problems though. No one in the team will have>enough time to write some decent documentation (and pruning>the include files and macros they'd have to provide). Then,>there are only a handful of people who probably could make>good use out of all that info. On top of that MS wouldn't want>to open the program so much that anyone could do what they>want (ie replace the renderer), although I don't think this>would be a huge problem as even if FS would be complete>open-source no-one would ever come up with something that is>heavily modified and better (lack of resources). On the other>hand, personally I would really like to be able to make use of>some FS internals apart from gauges. I'm planning to write an>article about the amazing possibilities we would have (eg>adding GIS capability). Maybe the FS team could make a special>'FS internals' SDK for registered/selected developers.>>3) gmax / 3dsmax is good enough>>5) couldn't agree more. The problem again here is that we'll>need a good set of documentation. There's probably only a>handful of people (well, maybe two or three handful) who>understand flight dynamics well enough to produce decent air>files.>>Cheers,>Christian>Hi Christian,Thank you (and the others) for contributing to this discussion.I am not sure to what degree you are intimately familiar with .NET, but it is more than just VB.NET. C#, as a language, is very close to C. Further, .NET just targets common libraries, which, as you allude to, do reach back and call *some* of the original Win32 and other OS stuff. But .NET is more than that. Seeing as how it is the future of windows development, I think my request is fairly reasonable. As someone who has done Win32, MFC and now .NET programming, I'll take the CLR/C#/.NET any day of the week.I mention XML because the scripting within XML tags is the "easier" alternative to C gauge programming as it is likely a shortcut system for the in-house gauge developer(s). So, I very much realize that XML is a textual markup/metadata system for internetworked communication, it used as a "language" to a degree for the panels SDK.GIS: Yeah, I am certain that they are making heavy use of GIS.GMax: The future of this product is clearly uncertain. I do not know what modeling tool they use on the MSFS development team, but staying in line with it would be good.AIR FILES: I am willing to bet that the .AIR file system has been the least fundamentally modified/overhauled of all the MSFS systems. I realize that I'd need acute aerodynamics expertise to make a serious go at it, but I can only reflect on XPlane, which has provided the ability for fine-tuned aerodynamics modeling. My only point is that the present system is very mysterious, very black box and feels somewhat arcane. Now, I could be speaking out of ignorance, but this is how it feels.Thanks for the discussion (please others join in).J-