Just now, Bobsk8 said:

Well bully for you. Maybe you are lying or a troll....

Some of you guys are crazy. My fps goes down for a couple minutes then come back. Never to the point of unresponsive menus. Ya'll need to stop jacking up the rendering scale 

6 minutes ago, devgrp said:

Some of you guys are crazy. My fps goes down for a couple minutes then come back. Never to the point of unresponsive menus. Ya'll need to stop jacking up the rendering scale 

I agree, I get my FPS dropping from my normal high 40's/low 50s back down to under 20 FPS and I also get micro stutters that make it look more like 10 FPS I but never lose control it is just really annoying.  Then again I am only running 2K at 90% render and 90% LODs (as i have a sort of mid range PC by MSFS standards)  so that might be making a difference.

Edited March 25, 20215 yr by Glenn Fitzpatrick

28 minutes ago, devgrp said:

 I've had the low fps too but never to the point of me not being able to click on anything, and never in the menus

Absence of evidence is not evidence of absence.

Edited March 25, 20215 yr by Christopher Low

On 3/23/2021 at 1:56 PM, omarsmak30 said:

Nope the core is FSX, you can easily see that through Simconnect and its support for legacy simvars 

That's not really the core of a game, the core of a game is the game engine itself since that is what handles all the heavy stuff. The other stuff is just a side show. It's based on Forzatech engine by Turn 10 (MS Subsidiary) and has nothing in common with the old ways FSX used to work. Sure there is a lot of virtual file structures and backward compatibility, but 80% of that is parsing, there is virtually nothing in the rendering engine from the original code since it's a completely different engine.

Edited March 25, 20215 yr by Alpine Scenery

4 hours ago, mrueedi said:

So the goal must be reach maybe something like 90%-95% common code. And that could easily mean, that loading 3rd party DLLs is still not supportable.

To me, apart from the possibility the Xbox ecosystem might contractually restrict published games from being able to loading 3rd party code, the only technical reason not supporting DLLs and sandboxing add-ons is only to protect the market place DRM from hacks.

Actually the game Flight Simulator.exe is loading DLLs, and I've found a direct loophole in their implementation which would allow 3rd parties DLL at runtime (this is not a system wide hook trick but a real architectural flaw), and there is otherwise another level to attack this problem with another kind of hack. I won't disclose this publicly for now either.

 

 

29 minutes ago, devgrp said:

Thats because most of are idiots and can't reason. Like I said before as soon as pmdg releases its first plane, suddenly msfs will be the best most realistic simulator lol

If Asobo continues releasing updates that causes more issues than they solve it really might take a very long time. If ever.....

All of the major “sims” at the end of the day are video games too. They are marketed towards entertainment (well maybe not P3D but that’s a whole different topic that skirts the tos) for the masses with some exclusions in certified trainers for P3D/Xplane. You can buy Xplane on Steam right next to the VR strip club and whatever fancy new shooter comes out.

We are all elitists when it comes to our preferred flight sim video game of choice. All have bugs.

Some of us moan and complain more than we actually fly in the sims/games we own. Might be time to put the game down and go outside, smoke a stogie, have a cocktail, give a word not allowed etc. Then come back after a few days, fly your favorite plane in your favorite sim on your favorite route and reclaim what you lost in all your bitter hatred toward whatever platform you were upset about to begin with.

It’s pixel planes on a screen/headset at the end of the day. Fake is fake.

Edited March 25, 20215 yr by CaptainNick

19 minutes ago, GSalden said:

If Asobo continues releasing updates that causes more issues than they solve it really might take a very long time. If ever.....

I don't really have any issues with the sim. I have my bad performance here and there but it's not a show stopper because it doesn't happen everywhere. Last night I did a nice 3+ hr flight in the crj flight from Memphis to reno. Everything went great and the lowest my fps went was about 22 with my gpu running at about 55% then it went back up. 

2 hours ago, Alpine Scenery said:

It's based on Forzatech engine by Turn 10 (MS Subsidiary) and has nothing in common with the old ways FSX used to work.

There is a striking difference between FSX launch and FS2020 launch to me.

Games are certainly not promoted the same between 2007 and 2020 and direct communication with the community is paramount nowadays and this is an important step forward which we are certainly all agreeing to and welcoming warmly. Please note though with FSX, Microsoft has invited nearly all the 3rd party developers in a pre-launch event which gave the occasion to not only discovering the upcoming simulator and planning ahead future developments but also to socialize and get contacts with ACE Studio developers. With FS2020 Microsoft has invited influencers and bloggers in a pre-launch event.

I’m not drawing any particular conclusion about this because these are not the same products and certainly not the same go to market strategy, but on one hand they are telling they are cognizant of the simmers community involvement in helping them making FS2020 a very good product, but only a select few 3rd party developers seem to have access to Asobo developers (per their saying and the 3rd parties saying so in their forums). There are more than a couple few 3rd party vendors more than willing to help Asobo building a better SDK though.

Otherwise I believe a sizeable part of the core game simulation has everything in common with FSX (1)* including its structural flaws. Here is one visible example illustrating this lack of knowledge of the FSX flaws and how this is impacting FS2020 today:

https://forums.flightsimulator.com/t/heading-increment-bug-10-degree-instead-of-1-explained/290173/2?u=cptlucky8

I believe this is a problem in itself. There are FSX SDK implementation bugs which might have been ported over into FS2020 and I’ll give you a practical example (2):

• The SDK is notifying gauges when to update: gauges do their calculations upon such notification usually (PANEL_SERVICE_PRE_UPDATE)
• The SDK is notifying gauges when to render: gauges are supposed to draw themselves upon such notification (PANEL_SERVICE_PRE_DRAW) (3)*
• Make a basic gauge, jump in the aircraft in the 2D panel (remember this is from FSX), switch to virtual cockpit, then jump back to 2D panel:
  ... your gauge will now be receiving some of these notifications twice instead of once…

Which begs some questions:

• How many 3rd party devs know about this and why the SDK is doing this? (there is a valid reason if you put your shoes in the SDK side).
• How many gauges are developed in such a way they won’t do the same calculation or rendering twice, so that they won’t take unnecessary processing and unnecessary FPS?
• Is Asobo aware of this problem so that they don’t let this happen again and/or they document it clearly?
• Is Asobo aware of how some 3rd party developers are still falling in this SDK trap even today?

 

And here is another example of how much FSX is rooted in FS2020. A few months back, someone was wondering:

"The aircraft looks to be using the AP_ALT_VAR_SET_ENGLISH event when incrementing/decrementing the AP altitude. However, these updates are not reflected in the AUTOPILOT ALTITUDE LOCK VAR simulator variable until the AP Alt is set. This should be updated dynamically, as is done in the Boeing 747, although that is using the AP_ALT_VAR_DEC and AP_ALT_VAR_INC events."

In my opinion this is representative of a fundamental flaw in the SDK, due to adding layers atop FSX SDK. Fast forward a few years and you’ll say in French: “on se traine ce truc de m… comme un boulet”. These events were added over the course of 20+ years of FS development in order to make it possible to animate and interact with the default aircraft shipping with the product first and foremost, not in a broader SDK strategy and vision for 3rd party developers. INC and DEC events were needed at a time there was no way to script interactive controllers either, or only when there was a need to just quickly put a button for these events on a panel. These legacy SDK concepts are a problem because they are not only technological debt carried over to FS2020 but they also are limiting extensibility by their strong internal coupling.

For panel and gauges development specifically, I believe such approach is impeding creativity for FS2020 because we still only have the limited set of vars and events which were only thought not to help us, but to help developing the stock aircraft included in the product, even more so because we can no longer hack, workaround or detour internal code at runtime in order to augment Flight Simulator where it is lacking.

 

And what about the FS2020 autopilot system? Yes what about it?

This is a good question! FlyByWire, CJ4 mod and Aerosoft are saying they have to build their own autopilot:

• Is this a problem of implementing these aircraft autopilot specific features (FLC mode working this way, ALT HOLD working this way) because there is no direct equivalent in the “functions” the SDK is providing?
• Is it because the underlying implementation of the autopilot system is not capable to work as expected, that is you can’t tune the autopilot PID as expected because FS2020 is not implementing them properly?

And this is illustrating how in getting a narrow vendor view you won’t make a better SDK. In effect Aerosoft autopilot should in the end be like every other airliner autopilot: it should have 4 controllers which are roll, pitch, yaw, thrust. Whatever the user interface to these (FLC in Boeings, Managed Descent in Airbus etc…) in the end, there is a piece of logic sending the error term for each of these respective controllers which are trying their best to correct the error term via the PID parameters.

FS2020 is already having the very same autopilot controllers implemented and working fine at its heart, but the problem is rooted in again, the SDK implemented to develop the stock aircraft first and foremost, not for helping 3rd party developpers doing their add-ons. The SDK is simply not giving direct access to the internal autopilot controllers, unlike X-Plane SDK.

I believe as long as the FS2020 developers are approaching the SDK needs and implementation from a consumer point of view, you’ll never get a satisfactory implementation for all. Rather, in approaching this as a producer point of view, you’re developing the elementary bricks 3rd party will dispose of as it is appropriate for their specific aircraft.

For illustration purposes, you can look at this part of the XP11 autopilot documentation. You have direct control to the modes you want to individually arm:
http://www.xsquawkbox.net/xpsdk/mediawiki/Sim/cockpit/autopilot/autopilot_state

NB: the autopilot modes from FS9 to P3D5 are internally implemented and working exactly like the XP11 autopilot system. There are 4 controllers each with a ARM/ENGAGE bit internally (I know I had to reverse engineer their implementation for the Reality XP GTN and GNS V2). But there is no direct access to the low level arm/engage fine control because the FS SDK is shielding the developper away from it, because it is presenting a “view” which is not directly matching the internal “model”.

To sum up, as long as Asobo is perpetuating the FSX approach to the SDK which consists in shielding the 3rd party developer from the internals and using “simplified” views representing an “ideal and generic” aircraft, it will never match the needs of 3rd party developers, and therefore makes me wondering in what working nearly exclusively with a few aircraft vendor focussing on their single aircraft development needs is really benefitting Asobo getting the true picture of the 3rd party developers needs, especially if Asobo is so i.g.n.orant of what developing an add-on aircraft consists of, like Mathijs is so much saying on his forums.

 

* (1) actually I believe it might everything in common with FSW instead. I'm re-installing it right now to look closer into this. (2) This bug is dating back to FS9 at least and is still present in P3D5 (although partly depending on some conditions). (3) in a buffer which the simulator will later display on screen

Edited March 25, 20215 yr by RXP

When MSFS 2020 is available on iPhone and Android, then we are in real trouble. 

I guess you never heard of XPlane for mobile devices....

Just now, Ricardo41 said:

I guess you never heard of XPlane for mobile devices....

Yes I did , still can't believe it. 

23 minutes ago, RXP said:

In my opinion this is representative of a fundamental flaw in the SDK, due to adding layers atop FSX SDK. Fast forward a few years and you’ll say in French: “on se traine ce truc de m… comme un boulet”. These events were added over the course of 20+ years of FS development in order to make it possible to animate and interact with the default aircraft shipping with the product first and foremost, not in a broader SDK strategy and vision for 3rd party developers. INC and DEC events were needed at a time there was no way to script interactive controllers either, or only when there was a need to just quickly put a button for these events on a panel. These legacy SDK concepts are a problem because they are not only technological debt carried over to FS2020 but they also are limiting extensibility by their strong internal coupling.

I agree they made some mistakes in how they implemented the SDK, both for developing aircraft and airports. The real mistake was they didn't hire enough 3PD developers to help them develop out the SDK issues and tackle that in advance. I don't know all the answers to the specific issues you point out, other than there are workarounds for some of them. As far as rebuilding the SDK code from scratch completely and not using any of the old code as a reference, that would have been too much work, I think it would have probably delayed the game a year or more.

Anyhow, the real problem is they are prioritizing adding new features way too far ahead of bug fixes and SDK issues in the priority list. Part of the issue is people are so demanding, they just had to have VR right away, etc... etc... They have a monumental task trying to please everyone, but yes there are issues in their development cycle, but in their defense this is a complex piece of software.

If I were managing the project, I would have put a lot of stuff on hold and focused on 4 things: performance, sdk, bug fixes, and landing physics. Those are the biggest issues in the game right now IMO. 

They can replace some of that SDK code fairly simply, I think they are just scared to given the bugs introduced in the other SDK editor recently. Remember, the person that ultimately decides which features to focus on isn't going to be one of the programmers.

Edited March 25, 20215 yr by Alpine Scenery

@Alpine Scenery

Honestly, they could have decided to build something anew, but the reason they didn't is their own and I won't judge. However from the look of it, and from Jorg's comment, I have little doubts the story is as simple as:

https://www.avsim.com/forums/topic/597380-jörg-neumann-regarding-world-update-data-and-the-playerbase/?tab=comments#comment-4498373

Quote

This was the starting point: a good looking simulation of a world region. He is an avid fan of the franchise too and there is the idea: what if extrapolating the Asobo Machu Picchu idea using Bing for the entire planet? And the 2 most important flight simulator requests, according to him, are AAA game engine visuals, and world wide VFR.  So 1+1=2: take Asobo game engine for AAA graphics, take Bing data for building a VFR world, and plug this into the FSX code base for the rest.

 

 

 

15 minutes ago, Alpine Scenery said:

The real mistake was they didn't hire enough 3PD developers to help them develop out the SDK issues and tackle that in advance. I don't know all the answers to the specific issues you point out, other than there are workarounds for some of them. As far as rebuilding the SDK code from scratch completely and not using any of the old code as a reference, that would have been too much work, I think it would have probably delayed the game a year or more.

Something to consider:

Live Dev Q&A: Guided Question - Community / General Discussion - Microsoft Flight Simulator Forums

Quote

I’m willing to bet there would be a great deal of existing renown and experienced 3rd party developers who would be trading some of their time contributing to the FS code base provided they’ll get a chance to enhance its core which would benefit their add-ons development first, and as a consequence any add-on development.

It would also take less people to hire, for managing this process, than hiring people doing the coding itself, while at the same time, I believe it would clearly prove to the community Microsoft and Asobo are really building a simulator for simmers meant to stay for a long time span, while recognizing without a shadow of a doubt 3rd party vendors are essential to the franchise and they wouldn’t compete with any of them directly.

Jorg is saying this himself: it is not like any other game or franchise, because people working in this industry are way more knowledgeable than he thought, way more engaging and passionate too, and he came to the realization FS2020 is a platform.

I believe the best way to turn this new vision into acts, is in forgoing the concept of closed source code and control, because the real value of such franchise comes from its ecosystem first and foremost, and this ecosystem might be Xbox crowd during a time, but most likely simmers only for the next decade, and simmers are expecting at least one thing regarding 3rd party vendors, which is flying their add-ons on simulators capable of running them, not the reverse.

The general idea could be a 3 tier/layer approach for example:

• lower level core simulation IP (physics, weather, network, rendering engine, etc…): closed source.
• higher level simulation environment (UI, gameplay, interfaces, presentation, etc…): closed source.
• middle level implementation: shared source with 3rd party vendors.

The middle tier is about building higher level functionality using the lower tier “blocks” in order to serve the higher tier. This is also where the SDK is plugged into with a certain number of I/O interfaces. In addition, the needs and implementations done by 3rd party vendors at this level would be influential to Asobo building additional lower level blocks and/or enhancing the existing ones.

What pertains to the simulator as a whole remains Microsoft/Asobo IP, and what pertains to the 3rd party vendor ecosystem is shared. In some ways it is not dissimilar as how it is today, except the simulator would benefit from much more developer resources, who would be contributing to enhancing the interfaces between the simulator and the 3rd parties, because these would be based on both their actual needs and the general guiding principles where Microsoft/Asobo want to lead the franchise to. In addition it would give a much better long term picture and vision to 3rd parties about where this is going for their own business, let alone the priceless engagement of 3rd parties ending up working mostly with FS2020 instead of another simulator platform.

There are certainly others ways, but it is a simple win-win idea.

 

1 hour ago, RXP said:

To me, apart from the possibility the Xbox ecosystem might contractually restrict published games from being able to loading 3rd party code, the only technical reason not supporting DLLs and sandboxing add-ons is only to protect the market place DRM from hacks.

Actually the game Flight Simulator.exe is loading DLLs, and I've found a direct loophole in their implementation which would allow 3rd parties DLL at runtime (this is not a system wide hook trick but a real architectural flaw), and there is otherwise another level to attack this problem with another kind of hack. I won't disclose this publicly for now either.

 

 

Oh, I thought I was the only one who noticed this. I have been experimenting on it for a few days. Is it possible for us to discuss it privately?