What developers want

[Michael Cependa 17]

Not sure how much is carried over from the old system in terms of coding animations, but one thing always irritated me.  One couldn't use "lag" on animations that complete full circles. For example on a drum type gauge, there was no way to slow the movement of the cylinders.  If you were changing values by whole numbers, the movement would appear as instantaneous. 

[fs1 295]

On 9/26/2019 at 3:31 PM, RamonB said:

I agree with You; C++ execution would be faster, but C# and other .NET languages dominate nowadays.
We also need some type of intrinsic code protection to prevent Reflector et al execution.
Let's hope Microsoft adds that and other languages support.

No complex addons can be supported if C++ code is not included in the SDK.

Other languages are secondary.

PMDG, FSLabs, Majestic, MV core DLLs are all coded in C or C++.

Edited October 28, 2019 by fs1

[b737800 470]

My developer status is probably something other than Freeware or Commercial as my products to date have been for internal use only. Happy to prove my credentials as needed.

1.) Event driven variable updates. Eluded to by Rob in "The repeated "round trips" required to see "change" is extremely time consuming, real time updates with the sim active would be ideal (perhaps a special "debug" mode if performance implications)."

2.) A nice to have on the above would be:
   a.) Minimum time between events (ie. don't update me on this more than every x ms)
   b.) Only update me on this if the value falls inside / outside this range (radar altimeter, for example).

3.) A dedicated managed SDK rather than a wrapper around a native dll. There are times when native code is a must. There are other times when ease of creation / maintenance / debugging outweigh the performance benefits. Managed coders would expect to work with managed classes that derive from standard interfaces (IDisposable for example).

+1 on the need for standard (or at least more open) 3D model formats.

+1 on the need for a better documented and more complete flight dynamics (.air files and their potentially duplicated values in .cfg files).

[b737800 470]

This might be a pipe dream but:

A Microsoft controlled approval / licensing scheme for the use of 3rd party copyright - or at least guidance on what is achievable and what is most definitely not.

It might be legally unworkable and totally unacceptable to the corporations wanting to maintain total control over licensing, but an entry barrier for smaller developers is the safe use of branding such as "Boeing", "A320" etc. As an analogy - if you've ever tried to obtain licensing for music across multiple geographies as a small, independent entity, for example, you will have realised that it's a total minefield and effectively impossible.

[tonywob 4,768]

6 hours ago, fs1 said:

No complex addons can be supported if C++ code is not included in the SDK.

Other languages are secondary.

PMDG, FSLabs, Majestic, MV core DLLs are all coded in C or C++.

This is just not true. It's not the language that's important but rather what API they expose

[fs1 295]

7 hours ago, tonywob said:

This is just not true. It's not the language that's important but rather what API they expose

Well, I meant C++/C as the main legacy programming language of all former SDKs. But could be Delphi or any other low level progarmming language.

As someone mentioned earlier in this thread, C/C++ should not be removed from the SDK.

Coding complex addons/systems with languages such as C# or scripting languages is not possible.

Edited October 28, 2019 by fs1

[JB3DG 225]

Actually it is. For one, complex addons often use their own threads for loading FMS data or terrain databases for custom display purposes, and their own file systems for said data. Secondly, where external flight and physics models are in use, native compiled code (python, C++, asm if you like) becomes critical due to the speed requirements. Interpreted scripting languages like C# are no good. Emulating complex avionics systems is also very much a low level department. Finally, you can forget about using the Garmin GTN/GNS trainers the way we use them in P3D/FSX/X-Plane without a C++ API.

Edited October 28, 2019 by JB3DG

[b737800 470]

18 minutes ago, JB3DG said:

Actually it is. For one, complex addons often use their own threads for loading FMS data or terrain databases for custom display purposes, and their own file systems for said data. Secondly, where external flight and physics models are in use, native compiled code (python, C++, asm if you like) becomes critical due to the speed requirements. Interpreted scripting languages like C# are no good. Finally, you can forget about using the Garmin GTN/GNS trainers the way we use them in P3D/FSX/X-Plane without a C++ API.

I might be getting old or just forgotten more than I know but... C# is compiled "just in time". You could argue that the JIT compiler is interpreting the intermediate code, but what runs is most definitely compiled, although it relies on the CLR and so effectively runs in a VM of sorts. Python is not that dissimilar and many would call it a dynamically interpreted language. C++ is a totally difference beast from both.

To call C# an interpreted scripted language is doing it a huge disservice. It is fully object oriented To dismiss its use just because properly written C++ code should be faster, IMHO, is a mistake unless that speed is the be all and end all. .NET framework is is very different beast than it was just a few years ago, including significant performance increases. Just FYI, most of my desktop based .NET code is very much multi-threaded, where as my most recent C++ project wasn't.

But anyway, we digress. A native SDK/API is an absolute must. A dedicated managed SDK/API would open up opportunities for far more people and can achieve the vast majority of what the former can, and probably faster.

Edited October 28, 2019 by b737800

[fs1 295]

9 minutes ago, b737800 said:

I might be getting old or just forgotten more than I know but... C# is compiled "just in time". You could argue that the JIT compiler is interpreting the intermediate code, but what runs is most definitely compiled, although it relies on the CLR and so effectively runs in a VM of sorts. Python is not that dissimilar and many would call it a dynamically interpreted language. C++ is a totally difference beast from both.

To call C# an interpreted scripted language is doing it a huge disservice. It is fully object oriented To dismiss its use just because properly written C++ code should be faster, IMHO, is a mistake unless that speed is the be all and end all. .NET framework is is very different beast than it was just a few years ago, including significant performance increases. Just FYI, most of my desktop based .NET code is very much multi-threaded, where as my most recent C++ project wasn't.

But anyway, we digress.

C# is slow as @JB3DG mentioned. Also you can't manipulate memory as fast as you would like to.

 

Edited October 28, 2019 by fs1

[JB3DG 225]

I stand corrected. That said though, having worked with it for configuration managers at Milviz while using C++ for aircraft systems and displays, C++ ranks king in just about every way including ease of use for systems simulation, strange as that may sound. Being able to use pointers allows us to do things with a speed and efficiency and power that C# simply cannot come close to without a lot of extra convoluted bloat being added, which also slows things down.

[b737800 470]

Just now, fs1 said:

C# is slow as @JB3DG mentioned. Also you can't manipulate memory as fast as you would like to.

The point here is, if legacy SDKs included C/C++, MSFS2020 SDK should include C/C++. I think that including C# would be a great plus, but not excluding the main legacy programming language.

 

I was just editing my reply as you added yours. Fun and games with lots of errors on the forum today. I totally agree with the need for the C++ SDK and if there was only one, this is what it should be. C# is not slow, but it is usually slower. Big difference.

[fs1 295]

10 minutes ago, b737800 said:

I was just editing my reply as you added yours. Fun and games with lots of errors on the forum today. I totally agree with the need for the C++ SDK and if there was only one, this is what it should be. C# is not slow, but it is usually slower. Big difference.

All good points. C# is a great addition if they do it.

[MattNischan 3,778]

1 minute ago, fs1 said:

C# is slow as @JB3DG mentioned. Also you can't manipulate memory as fast as you would like to.

The point here is, if legacy SDKs included C/C++, MSFS2020 SDK should include C/C++. I think that including C# would be a great plus, but not excluding the main legacy programming language.

 

Not to start a language flame war, but that is just simply not the case. Well written C# can be as performant as C++. Right now, ASP.Net's Kestrel HTTP server completely saturates a 10GbE link, and is in the top 10 of speed of frameworks, just .01% slower than the top C++ server. https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext

In C#, you can take the language down to bare metal, you can work directly with pointers, manage your own memory, deal directly with structs and not classes, etc. And if you want nearly all of that speed but without fear of buffer overruns and bounds errors, you can use Spans, which are effectively managed pointers. The idea that C# intrinsically cannot be as fast as C++ is, unfortunately, an outdated bit of information, and there are significant advantages.

That's not to say that C++ is a bad language.

-Matt N

[n4gix 4,947]

On ‎10‎/‎9‎/‎2019 at 1:34 PM, Michael Cependa said:

For example on a drum type gauge, there was no way to slow the movement of the cylinders.  If you were changing values by whole numbers, the movement would appear as instantaneous. 

While it is true that <Lag> is not possible for a continuous rotation, it is a trivial matter to slow the rotation of a drum by basing the animation on fractional values rather than whole values. Many of us have been doing so for years now. See discussions at fsdeveloper.com for examples.

[Michael Cependa 17]

Thanks for the tip Bill.  I never could find anything about this at fsdeveloper.  I did ask about it and was given a couple of suggestions (other than the one you just mentioned) that seemed a little complex for the dozens of drums I would have to recode. 

On a completely different point, one thing I'm sure developers would appreciate is a native weather radar that can be adapted by developers to show custom graphics, colours, etc. 

Something else that would be nice: the ability to override what a controller says a flight surface deflection should be. I was able to do this with XMLtools, which allows writing to "A" variables, but my code would end up fighting with what the controller was saying and the part; in question would show some flickering which had to be concealed using elaborate workarounds with the visual model. 

One more thing comes to mind: more flexibility with respect to spoilerons. Default behaviour in FSX is to link their availability to flap deflection, but on the aircraft I was modelling this was linked to the landing gear being down.  Getting it to work required another complex workaround.