Jump to content

Sign in to follow this  
JB3DG

What developers want

Recommended Posts

A small thing, but actually very important for scenery development as well as spotting bugs in the scenery: SLEW

Flight did not have slew and it was a problem. I'm hoping we'll have this. 

Share this post


Link to post
Share on other sites
11 minutes ago, rhumbaflappy said:

A small thing, but actually very important for scenery development as well as spotting bugs in the scenery: SLEW

Flight did not have slew and it was a problem. I'm hoping we'll have this. 

+1 to this. In fact, I'd love to see a built-in camera system similar to X-Plane's and ChasePlane, this helps a huge amount with scenery development and taking nice screenshots

  • Like 1

Share this post


Link to post
Share on other sites

 

Quote

C++ will be faster as there is no CLR overhead, but agree, I would like to see any .NET language support also as that will bring in more developers.  There is still a demand for C++ developers especially in the entertainment industry, but C# .NET dominates.

I personally don't care (P3D PDK is very fast as it's C++ based), it's just syntax ... but whatever Microsoft decide on, please provide sufficient and complete and accurate documentation, WORKING samples from start to finish (not partial samples), and not a CHM file.

I'd like all the files to be encrypted binary on deployment ... or at least have a choice to deploy that way so as to protect our work.

Cheers, Rob.


C++ is essential to high level simulations for a whole multitude of reasons though, so hope that doesn't get removed for other languages.

Edited by JB3DG
  • Upvote 1

Jonathan "FRAG" Bleeker

Formerly known here as "Narutokun"

 

If I speak for my company without permission the boss will nail me down. So unless otherwise specified...Im just a regular simmer who expresses his personal opinion

Share this post


Link to post
Share on other sites
On 9/28/2019 at 5:05 PM, Rob_Ainscough said:

Yes they eluded to an SDK.

Cheers, Rob.

alluded to 

 

Share this post


Link to post
Share on other sites

@moderators, any reason this is unstickied?

  • Upvote 1

Jonathan "FRAG" Bleeker

Formerly known here as "Narutokun"

 

If I speak for my company without permission the boss will nail me down. So unless otherwise specified...Im just a regular simmer who expresses his personal opinion

Share this post


Link to post
Share on other sites

Freeware scenery developer (XPlane):

 

1. A large library of HQ stock objects so that we can make convincing lego-brick airports. If the XPlane Gateway model is then adopted, lego-brick airports could be submitted to mods and approved/rejected. These could then be shipped with the latest update without the need for users to download additional libraries. This also ensures that default airports are HQ and up to date (with ground markings/taxiway changes...). It would be a shame if such a beautiful sim were to be ruined by poor vanilla airports.

2. The ability to get information about the terrain mesh in the scenery development programme used to create overlays. In XPlane, it is frustrating to make a custom building, only for it to sink into the ground because you have no information on local elevation fluctuations whilst in the scenery tool.

 

  • Like 1

Share this post


Link to post
Share on other sites

Regarding SDK: it will be released soon.  This is also in the “what we know” thread.

Listen starting @ 25:00.

https://www.flightsim.com/images/features/msfdev/FlightSim.com-Microsoft_Flight_Simulator_Interview_AUDIO.m4a



Specs: I9-9900K. Nvidia 1080 ti, 32bg ram, I7-6700K, Nvidia 1080 | Headsets: Hp Reverb, Samsung Odyssey OG, Oculus Rift, Oculus Quest and Oculus Go
Flight Simulators: Prepar3d, FSX, X-plane 11, Aerofly FS 2, DCS, FSW

Share this post


Link to post
Share on other sites

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. 


Michael Cependa

Developer Aerosoft DC-8

Share this post


Link to post
Share on other sites
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 by fs1

Federico Sucari

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

  • Like 1

Share this post


Link to post
Share on other sites
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 by fs1

Federico Sucari

Share this post


Link to post
Share on other sites

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 by JB3DG
  • Upvote 1

Jonathan "FRAG" Bleeker

Formerly known here as "Narutokun"

 

If I speak for my company without permission the boss will nail me down. So unless otherwise specified...Im just a regular simmer who expresses his personal opinion

Share this post


Link to post
Share on other sites
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 by b737800

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    30%
    $7,720.00 of $25,000.00 Donate Now
×
×
  • Create New...