Hi folks, After a recent chat with Jorg, I wanted to post here an idea that I
shared with him regarding Sim Updates and the difficulties faced in
understanding the differences between intentional changes within the
simulator’s structure, and bugs. Currently, there is no information released
prior to Sim Updates that outlines what is being done within the simulator by
Asobo, even though those updates are always underway months before public beta
and release. As Asobo airplanes are always updated and work with each Sim
Update without apparent issue, it seems clear that what has been changed
within the simulator is known to the team. I would like this information to be
shared with third-party developers prior to each Sim Update launch, so that
we can refine our own updates and understand where best to direct our efforts.
Reporting non-functional airplanes or other bugs does not produce the
information we need to fix those issues, and does not allow us to know in
advance whether Asobo has made an error or intends the changes made to the sim
that then cause issues with third-party products. A 48 chapter Changelog is
not required - merely a list touching on the changes made with each update. In
the case of Sim Update 9, a line notifying us of fuel pressure changes to
reheat requirements, and any similar adjustments, would have made it far
easier to fix problems with Concorde, instead of many long hours trying to
figure out what had been done to cause the issue. We would also then have
known it was something we definitely needed to adjust, and not a bug with SU9
that Asobo might fix before the release date. Hope this all makes sense. If
developers have a heads’-up of where changes have been made, we’re going to be
much better positioned to know where to make our fixes, get them uploaded to
the Marketplace team on time, and see much smoother transitions to each new
version of the simulator. Cheers, DC 
To add to this idea: Do not just include airplanes, but changes for all other
stuff that is relevant for 3rd party content as well.
Mind blowing that we have to ask for this really
This gets my vote. It would certainly reduce the trepidation associated with
each SU (including the betas)… Not knowing if we are going to have a
productive day of developing because we’re ahead of it all, or a busy day
answering customer queries about a new issue (especially difficult when we
don’t know if it’s down to us or the sim).
There are two main problems with the way the beta is setup 1.Asobo side
testing It seems that the basics are slipping through the cracks. EG it seems
that things are just not being tested properly. When the beta is shipped for
testing it takes us 5 - 10mins to start finding things that are broken. I
would also like to see a proper test script setup. Whether you guys need help
in us set you up an open standard test model/project with an open and
recognized test script so we can both benefit in the communication. This will
help you understand what we do in the 3rd party world and what you do in the
feature development world. 2. Beta testing features locked in mostly By the
time beta testing reaches the developers/public, it seems that fixes are only
loaded into the following release, not the release we are testing. An example
is the vector place tool. I do get that you are running a schedule using agile
methodologies but what it is causing is a long wait for fixes to actually be
implemented. This is fine if it’s not a sim-breaking bug, but when it affects
our 3rd party products and our customers it’s become very long in the tooth,
Let me just say that our customers aren’t in a good mood and there is a lot of
trusts lost. This is now the real effect of these issues. I understand that
some things mean a larger re-write to code outside of your area, but I think
you guys either need longer test and fix times or need to work something else
out because, for the developer community, this isn’t working. I should add,
you guys are really doing an amazing job as a whole and the access we have to
you is amazing. We do actually appreciate all of this a whole lot. If we can
nail a few of these communication and release issues sorted it will be a lot
smoother.
PLEASE, if you change something have the documentation READY for the beta
testing and NOT 6 months later. This is something that we do in my day job,
when releasing an update to the product, the documentation is ready DURING
testing so that our testers fully understand what is going on. In this case
you probably are doing that internally however you have an extra complication
of supporting third party developers and so you MUST share those changes with
us. I understand that MS is probably driving the bus a little bit with the
scheduling, but that means you need to make them aware that this lack of
communication and proper documentation is causing a lot of greif umongst your
supposedly “supported” developers. I’m not normally salty and I try to remain
balanced in my feedback but this is a LONG burning issue.
Hello everyone. I think we have moved forward on this. Do you have any
feedback on how SU10 went in that regard so far? Of course we still need to
improve this, make the flighting doc and SDK download more accessible, etc…
Is there anything you want to add? Features or changes that were not listed,
critical piece of info that was missing? Regards, Sylvain
I’m very happy with the progress you guys have made on this! Very pleased with
the level of access, the openness to having us test multiple builds before
release and the willingness to delay the update for the good of everyone.
Other than a massive cleanup in the non-working legacy code still present in
the documentation, I have nothing to note. Thank you! - Keven
As Keven said… very pleased with the progress on this regard. One thing that
I believe would be useful, is to extent tutorials regarding how to use new
technology being implemented by your team, for example, I tried the model
attachments and I was struggling a bit to understand why my attachment was not
showing, to find out, the attachment LODs are enforced immediately, making the
attachment LOD0 disappear straight away after compiling, this is happening
despite that the LOD enforcement is not enabled on the LOD debug window, most
of the attachments we build, starts with only 1 LOD and as we move forward
with the project all the LODs are created… so this was surprising and took a
while to understand… Also the new SimConnect API for facilities, the example
on the documentation is a bit limited, and I am struggling to understand it
fully. Another example is when you guys move things forward with the flight
modelling, even if we try to see the Cessna Caravan, King Air, etc. it is very
hard to understand what to tweak to get the desired results, for an instance
the prop modern, etc. Regardless of the above, thank you so much for taking
our feedback in consideration and allowing 3rd party developers more time to
catch up, this is really appreciated and I continue to look forward for more
improvements to the platform. Best, Raul
"I tried the model attachments and I was struggling a bit " You are not
the only one. My main issue is my apparent inability to interact with the
attachment. / sub model. If Model attachments / sub models area a work in
progress, then more details in the SDK would help, both as to what is
currently working, and the design goal for how it will eventually work when
completed. ie At the Moment, I can add a “sub Model” tablet, but I cannot
interact with it, or display anything on it. Is this the know current state of
Sub Models, or am I missing something, It seems that the base model may be
need to be exported with the Unique ID bit set , for ist sub models to be
fully functional. So far, I have not seen a single model in MSFS, exported
with that Bit set, implying that no existing Models can have interactive sub
Models ?? If all this is already working, maybe we could have a simple
example, in the SDK ?
My reference above was regarding model attachments and not sub model merging,.
two different technologies, but you post just confirms the point I am raising.
Without more detailed examples all devs are just clueless about how to use
these new features in the SDK, and we ran into the danger zone where nobody
uses them because is too daunting, so they don’t get properly tested and
eventually we end up with new features in the SDK that either nobody uses or
have limitations given the lack of feedback provided by the 3rd party
developing community. R.
I strongly recommend moving documentation to public github repo and generating
documentation HTML from there, like many Microsoft’s products already do, for
example:(https://github.com/MicrosoftDocs/win32/blob/docs/desktop-
src/desktop-programming.md)
<https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/desktop-
programming.md> <https://docs.microsoft.com/en-us/windows/win32/desktop-
programming> This would let us track every small change and submit
corrections/clarifications. I often come across small mistakes, omissions,
undisclosed caveats and things that are unclear and need testing to find out
which interpretation is true.