Hello, I’m maintening for free three plane mods based on the c172. In order to
have the mods compatible with the classic 172, I have to provide an xml for
the panel. My current versions are out of sync which cause bad system
behaviors. I request access to the three flavors (wheel,ski,floats) panel.xml
files from c172sp_classic. Considering the 3D model and the cfg files stay
encrypted, the plane is still protected from copy. I hope you’ll agree with
this, it would help a lot (me and other modders) Thanks !
I would go a step further, and repeat what most users is saying Please
remove ALL .cfg files from encryption (at least for ASOBO Planes – If 3rd
party devs specifically request their .cfg files be encrypted, that’s should
be their call, as is the choice of players to purchase such .cfg encrypted
planes) Considering the 3D model stay encrypted, the plane is still
protected from copy, which is the primary reason for the encryption.
Fully agree. Had the configuration files to A320 been encrypted like on many
other airplanes, we would’ve never had the FlyByWire version of it.
+1, this woul help us with ptecting AI Models as well, many developers are
currently waiting for their release cause they do not want to release fully
open and can not release fully encrypted.
@EPellissier Your input on this?
we’d like to know 
@EPellissier is off this week but be sure we’ll ask him as soon as he gets
back!
@FlyingRaccoon can you try to get the answer ? This would really help
I’m imagining perhaps you’d like to edit the panel.xml files? Is so, this
won’t help. If not, somebody else showed me how to include the default
panel.xml so I could modify the panel.cfg to defeat the registration # decals
on liveries I create In the panel.xml file, I include the following line
of course replacing the container directory with the proper directory. Then I
don’t have to worry about keeping up with changes to the panel.xml file.
This is what I’ve used but the other files are required too (systems.cfg,
flightmodel.cfg…)
I think we can take this as a big NO
The title said panel.xml, so that’s what my answer was for. As I know you
know, they’ve said they’re not going to release the encrypted files. The only
choice is to design new ones if you want to mod a plane. Certainly, it would
be helpful to have somewhere to start, but, heck, they were wrong in the first
place. Might as well start fresh 
Maybe one possible way to allow an encrypted .cfg to be “modified”, would be
the introduction of a mod.cfg file, that could override any .cfg file
parameter, in any of the standard .cfg files.
As you are no doubt aware, this was briefly brought up again in yesterdays
Q&A;, but yet again in a vague way, without making clear that it is ONLY the
.cfg files that the community is looking to be excluded from the encryption
process. (Models etc stay encrypted) Again, vague responses that this may be
possible, with an emphasis on Licensing, and DRM, that one would assume were
adequately covered by keeping the other files (Models etc) in the planes
encrypted. It is not clear who makes the call or decisions on this, since in
the Q&A; it was Asobo that said it may be possible, now it has been brought to
their attention (in the Q&A;). So is there any possibility that some action
can be taken to comply to this request. Once again, nobody is looking to
remove the DRM on these aircraft, or make them able to be pirated or shared.
The community would just like the ability to be able to MOD the .cfg files,
and “optimize” a number of the parameters, as was done successfully with other
non- encrypted planes.
@FlyingRaccoon Give a big thanks to all at Asobo for the access to the cfg
files. That will help a lot modding ! <3 Is it planed :
- to unlock the xml files too ?
- to unlock files on your other planes : for example, there’s a lot of interest in patching the JU52 as it is not maintained anymore
Hi @bagolu, There is no plan to provide unencrypted XMLs or to provide clear
CFGs for other planes at the moment. Best regards, Eric / Asobo
SUGGESTION: How about fixing some of the now known and easily fixed issues
with these Premium Planes, and while you are doing so, re-export them with
the Identity Bit set. While this would not meet the request for open cfg or
xml files, those file CAN be rewritten from scratch by a competent 3rd
Party developer, Re-Exporting with the Identity Bit set would allow Sub-
Models, and a way to greatly enhance these planes., adding an interacting sub-
modes to the basic model. ie like a Tablet. I n fact, the recent SDK
indicates that the default export configuration is to have this Identity Bit
set – but none of the Asobo, or MarketPlace Devs have adopted this… or even
taken advantages of its powerful consequences. (Either when using 3D Max
or Blender )
**
Asobo re-exporting the Models with the Identity Bit set, it then becomes
possible to ADD sub-models to the existing encrypted Model., without
destroying the DRM protection. So NO LOSS DRM protection… all remains
encrypted as decided by Asobo/MS, but the existing plane is then opened up for
modification and improvement, but only for those that already legitimately
have purchased the original plane. It seems clear that after 2 years, MS &
ASOBO have little interest in either fixing or improving these planes, ( for
whatever reasons ) which now, by today’s standard of MSFS Planes, are very
basic and lacking.
- Then, to tactfully address the “ELEPHANT IN THE ROOM” – most Devs know that the marketplace DRM recently got cracked, and all the Premium Deluxe planes, and many other plane that were on the marketplace (ie Carenado) are out on numerous Pirate sites, with their cfg, XML and Models fully decrypted -- so if not used directly, they do provide examples of what would be needed to be created from scratch… Not that any respected 3rd party developer would take that route. !
Allowing a Legal & Legitimate ways for 3rd Party Devs to enhance these planes,
would seem to be of benefit to both MS/ASOBO and the Community. Already,
significant numbers have upgraded from Basic to Premium, because these Premium
planes have started to be enhanced by 3rd party Dev, making that extra expense
of the Premium /Deluxe packages far more cost acceptable. -- GOOD for
MS/ASOBO – good for 3rd party Devs, most importantly , good for the MSFS
Community – a win-win-win situation.