1 hour ago, MattNischan said:

LM moving the platform to 64bit doesn't change

No. That isn't the point I was making. That comment of mine had nothing at all to do with SimConnect. I was talking by then about the business sense of Microsoft not having to reinvent the 64 bit wheel by starting again where they left off with FSX, but what sense it would make to take business advantage of all the development that LM have done in that direction (and DTG to some extent). It all seems (to me) to add up to concluding that a LM  partnership in this project is not something to be unexpected and it would not surprise me one iota if I were to see it announced just a couple of months before Flight Simulator is finally released. That's all.

3 minutes ago, Theboot100 said:

No inheritance has nothing to do with different versions of sim connec

I think you'll find it does. If the first declarative statement of any new SimConnect Class is not something like:

: Inherits SimConnectxxxx… I'd be extremely surprised.

1 minute ago, sjt said:

No. That isn't the point I was making. That comment of mine had nothing at all to do with SimConnect. I was talking by then about the business sense of Microsoft not having to reinvent the 64 bit wheel by starting again where they left off with FSX, but what sense it would make to take business advantage of all the development that LM have done in that direction (and DTG to some extent). It all seems (to me) to add up to concluding that a LM  partnership in this project is not something to be unexpected and it would not surprise me one iota if I were to see it announced just a couple of months before Flight Simulator is finally released. That's all.

I understand where you're coming from there now, apologies for misconstruing.

I think, by the way Asobo has talked, it sounds like the FSX code was in some ways mostly referenced as opposed to directly used, and that the simulator is by a large a new codebase from the ground up. So, my inclination is to lean in the direction that LM has been entirely out of the loop on this. I could certainly be wrong about that, but given what I see, it would not surprise me. Lots of what they have would be very difficult to just refactor into existence from the FSX code base, guessing from having seen my fair share of late 90s to 2000s era C and C++ game code. LM is a much smaller, and to be honest, far less resourced team at a company where game development is but a tiny little department in the corner. The best devs in the industry are not lining up at LM's door to get game dev jobs from them.

Things that every modern game engine has had for almost a decade, like 64bit support, being so hard to do for LM really highlights those last two points, in my mind. It's an old codebase and a small team. And the benefit from inheriting their work is not terribly large, given the huge scale changes that one would need to apply to it anyway to get what MSFS seems to be.

-Matt

12 minutes ago, MattNischan said:

LM is a much smaller, and to be honest, far less resourced team at a company where game development is but a tiny little department in the corner. The best devs in the industry are not lining up at LM's door to get game dev jobs from them.

Exactly. It's interesting that precisely because of that I am tending to conclude that there is no point in LM continuing to develop P3D software. They've done sterling work, and hats off to that. But it's really not LM's specialism. They are little fish in that particular big pond, and are simply unable to compete (should it ever come to that) with the giant of Microsoft. So unlike you, I draw the opposite supposition by thinking that LM has been very much in the loop, and it will be just a matter of time when they will step out of the game again. I see LM's long-term involvement/partnership as being that of a military/jet manufacturer, not as a software developer.

 

100% speculative. Just drawing from all the circumstantial evidence I see. 

Edited December 10, 20196 yr by sjt

Just now, Rob_Ainscough said:

Are you fishing?

Lol. Not in the slightest. I haven't got a clue how many there are at LM. I'm sure you know since you are so closely involved with them. I am simply drawing my own conclusions from what I see. If I'm wrong, I really don't care, because it doesn't actually matter. The only thing I'm interested in as far as MSFS is concerned is - is it any good? If the answer to that is "yes" then I'm looking forward to flying it. I don't actually care how they get there!

35 minutes ago, sjt said:

I think you'll find it does. If the first declarative statement of any new SimConnect Class is not something like:

: Inherits SimConnectxxxx… I'd be extremely surprised.

Inheritance has got nothing to do with cross compatibility of different versions of Sim Connect.  If it was written using functional programming the exact same would be achieved.  Thats the point im trying to make.

Specifically saying, because of inheritance we can have cross compatibility of different versions of software is just wrong.

Probably unpopular opinion:

I wish MS would have dumped all backwards compatibility. Wiped the slate clean. It's 2019, we don't need FSUIPC, SimConnect or legacy "fly on rails" mode.

Just give us a well designed, well documented, future facing SDK that allows add-on development in C++ & C#.

I'd rather wait longer for utilities and aircraft to appear and them be really high quality rather than low effort ports.

2 hours ago, David Mills said:

For those of you following this thread who may not be professional programmers, a "high level language" is generally not as efficient or fast as a "low level language."

Interesting stuff! Thanks for the explanation. So, is there such an interface available that "converts" high level code into low level code? Probably not huh...

Edited December 11, 20196 yr by KERNEL32

52 minutes ago, KERNEL32 said:

Interesting stuff! Thanks for the explanation. So, is there such an interface available that "converts" high level code into low level code? Probably not huh...

Yes. High-level languages such as Python or BASIC are interpreted or "converted" on the fly by interpreters in real time, though there are BASIC compilers which translate the code in advance for improved performance. These are the easiest languages to learn and use. Other languages, such as the C languages, are compiled into machine-executable code in advance and therefore run much faster than interpreted languages. The C languages are a little more difficult to learn and use than Python or BASIC.

Back in the 1980s, before many of you were born, I bought a Radio Shack Color Computer III. It sold for about $120 I think. This was an 8-bit machine with a Motorola 6809 processor. You hooked it up to your TV. The machine came with Microsoft BASIC built into the system hardware. On this machine, I learned two languages: MS BASIC and Assembly language. Anything written in BASIC had to be interpreted by the operation system and ran slowly. Anything written in Assembly language was executed directly by the microprocessor and literally ran thousands of times faster than BASIC. Assembly code also permitted you to do things you simply couldn't do in BASIC, like de-arc graphics in a video game.

Do any of you remember the old Radio Shack Color Computer II or III? My best-known programs back then were "Shuttle Launch Control & Data Base" and a graphics viewing utility called "View Master" (named for the popular children's slide viewer). I very foolishly sold the little machine years ago. Compared to today, the graphics were primitive, like looking at a very early 1980's version of Flight Sim. But it was a lot of fun.

One great thing about writing programs for the Color Computer -- something that today's programmer's would envy -- is that all the machines were absolutely identical. If your program worked on one machine, it worked identically on all of them (assuming there was sufficient memory). Today, no two computers are exactly the same, resulting in tech-support hell for vendors.

 

 

 

Edited December 11, 20196 yr by David Mills

1 hour ago, nickhod said:

Probably unpopular opinion:

I wish MS would have dumped all backwards compatibility. Wiped the slate clean. It's 2019, we don't need FSUIPC, SimConnect or legacy "fly on rails" mode.

Just give us a well designed, well documented, future facing SDK that allows add-on development in C++ & C#.

I'd rather wait longer for utilities and aircraft to appear and them be really high quality rather than low effort ports.

Yes please

9 hours ago, sjt said:

Exactly. It's interesting that precisely because of that I am tending to conclude that there is no point in LM continuing to develop P3D software

There has always been a bit of a misconception here about what P3D actually is. Most people seem to think of it more like FSX and a half. It was made quite clear when it was released that it is a military training aid, the EULA even says, quite explicitly, it's not for entertainment purposes. Yet people insist on comparing it with FSX and it's peers.

LM probably haven't helped this by having better things to do with their time than viciously clamping down on the EULA violators and have instead been very accommodating of the "entertainment sim community" (that's us). Obviously this is great for them, I imagine we find lots of bugs and some of our 3rd Party Developers have increased realism/improved the sim in ways that has probably enhanced the product and made more attractive to their primary market... the military.

9 hours ago, Rob_Ainscough said:

And then there's P3D multi-channel which apparently works best with 10GbE (or higher) and genlock GPUs and a server sync card for frame/display sync (at least per documentation anyway, no actual experience my side yet).

P3D also supports DIS (Distributed Interactive Simulation) protocol version 6 (older IEEE 1278.1a-1998) ... zero experience here.

And then CIGI (Common Image Generator Interface) ... again no experience here.

As Rob posted above, there's 3 technologies I've never heard of, indeed, I'm not sure I even know what they do but LM wouldn't have put them in for fun. They will have been requested by their primary market as prerequisites for their training simulation software.

To suggest LM should stop developing their approved, integrated, military standard flight simulator because Microsoft is coming out with a new flying game (I know, hard hat on!) is laughable. LM may well buy some of the technology from MS, or even partner with them or possibly buy the engine (similar to what they did with FSX, i.e. ESP) for their own development but to think they'll stop because of it... fundamentally misunderstands the whole point of P3D.

To answer the question from your thread title, Microsoft Flight Sim and Prepar3D are separate, similar, sometimes compatible but always on their own path, maybe converging, maybe diverging but always adding to the rich and complex ecosystem that makes up computer flight simulation...

Just my thoughts,

P.S.

9 hours ago, Theboot100 said:

Inheritance has got nothing to do with cross compatibility of different versions of Sim Connect

👍👍👍

On 12/10/2019 at 2:52 PM, sjt said:

SimConnect uses a fundamental principle of object oriented programming (OOP) called inheritance, or derivation. Every time a new version of SimConnect is released, the new version inherits all of the characteristics of the previous versions. So any new characteristics (properties, methods etc) just get added to what was in the previous version, meaning what’s already known does not need to be rewritten.

The server is the controlling influence. Because of inheritance, any client application that uses an old version of SimConnect  can be used to communicate with a newer server that inherited from it, but it doesn’t work the other way round. If the latest version of SimConnect attempts to communicate with a server written for an earlier version, they will not understand each other

 

 

The last version of SimConnect that was written for FSX was 10.0.62615.0 (I believe). There might be a latter version than that. If there is, I’m not aware of it and in the context of this post, it doesn’t matter anyway. 

Please do not quote long posts. 

I am still wondering who taught you this crazy idea of inheritance. If that's how you code your programs where every update is a new class inheriting the old class then you have no idea on OOP and program design.

I suggest studying the four fundamentals of OOP.  Encapsulation, abstraction, inheritance and polymorphism.

There is one area where direct, low level access in C++ is critical and that is where any form of integration is involved, whether an external flight model, or even more critical, a true inertial navigation system simulation. If you try to do the integration in an asynchronous callback, it absolutely will diverge in a very big and bad way from the simulator, which makes it very difficult to do genuine physics based systems rather than fudgery.

4 hours ago, Theboot100 said:

I am still wondering who taught you this crazy idea of inheritance. If that's how you code your programs where every update is a new class inheriting the old class then you have no idea on OOP and program design.

I don't think that kind of tone is really necessary.

While it is true that I would never design code extending the previous version's classes with the new version's (versioning is a responsibility that is well outside of class structure), nor have encountered such a practice in all my programming travels (almost 20 years now), there are ways of presenting that information in better formats. And, it has been said a number of times already in this thread.

For all the young or new devs out there, I would not recommend appending version numbers to your classes, such as:

public class SomeClassV1 { }

public class SomeClassV2 extends SomeClassV1 { }

This is an extremely brittle practice that wreaks absolute havoc on large codebases when you would like to start using the newly added methods or functions, as it requires sweeping type changes for every spot that used the previous versioned type. As long as the API is maintaining backwards compatibility by keeping the same method and/or function signatures for existing methods and/or functions, then there is no need at all to alter the type signature, simply add the new APIs to the existing type.

The fact that an library API has binary incompatible changes should be communicated via incrementing the major version number of the library itself (not altering the type signatures), a la versioning schemes like Semantic Versioning (or SemVer, as it is more colloquially known). That way, the amount of refactoring necessary to consume the breaking changes is kept to a minimum.

This is a major aside to the point of this thread, so I don't want to belabor it any further here. If anyone has questions, please feel free to contact me and I can give some more examples.

2 hours ago, JB3DG said:

There is one area where direct, low level access in C++ is critical and that is where any form of integration is involved, whether an external flight model, or even more critical, a true inertial navigation system simulation. If you try to do the integration in an asynchronous callback, it absolutely will diverge in a very big and bad way from the simulator, which makes it very difficult to do genuine physics based systems rather than fudgery.

It truly depends on the type of asynchrony and the API design. If by asynchronous we mean "it won't block the main simulator thread if my program doesn't respond", then there are still ways of guaranteeing program flow there that mean that your response is still received in the simulation tick in which it was requested. Asynchronous doesn't have to mean non-guaranteed delivery timing relative to the program flow, it can simply mean non-blocking relative to other work during that game frame.

However, if the API _also_ returns the current frame time/delta time/sim tick time along with the actual requested values, then you can calculate your integration using those times as if you were in the main game loop itself. At that point, things like guaranteeing delivery within the game frame basically don't matter at all.

-Matt

8 hours ago, Theboot100 said:

…. you have no idea on OOP and program design.

I suggest studying the four fundamentals of OOP.  Encapsulation, abstraction, inheritance and polymorphism.

There was a time when I thought comments like that were both unnecessary and hurtful to the recipient. Now I just feel sorry for the person who wrote them.