• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Beware P3Dv4 scenery.cfg encoding changes

=Hollywood=

=Hollywood=

Messages
859
Country
australia
Discovered a little thing to be aware of with Prepar3d v4 today.

The scenery.cfg when installed clean is encoded as ANSI, as per previous versions of the sim. If users add scenery via installers into this it should all work fine.

However...

If you delete the scenery.cfg from P3D v4 and the sim regenerates a new one, it is encoded as UNICODE. Subsequently if you try and install some 3rd party software into it, you'll end up with chinese characters and the scenery.cfg losing all entries. (see attached)

So, if anyone is using Prepar3d v4 be aware of this issue. It is a simple fix to open the scenery.cfg file in notepad.exe and save as scenery.cfg and ensure the file is encoded to ANSI. This will ensure it should all work as before.

As for updating code for how to encode and update the scenery.cfg to UNICODE on the Setup Factory code side.
 

Attachments

  • scenery.cfg.bad.txt
    8 bytes · Views: 823
  • scenery.cfg.good.txt
    11.5 KB · Views: 806
I noticed this behaviour as well, a few weeks ago. Imagine my dismay when I had tested my Scenery Managers on 2 different installations of P34, only to release my product and get various reports of slow performance and weird characters! I had to figure out how to rewrite all my managers to figure out which encoding it was in and read both types. (Luckily it turned out to be not too hard for my coding environment)

Best practice would actually be to save the file in whatever encoding it is presently in.
But as we already know. Not all developers will follow this rule and some make a mess of things all together! (If I had a dollar for everytime I had to have a user email me there files so I could save it back in the proper encoding... :rolleyes:)
 
FWIW, per L-M the defacto standard from now on will be UNICODE. This is being done to better support full localization of native language for users.
 
If one starts a cmd prompt with the /U option, all output will be in unicode. eg:

C:\cmd.exe /u
type q:\TestUni.txt > u.txt
 
Of course, if one used the preferred addon installation process that L-M created, the coding of said file is moot.
 
Yes, I would say that with v4, it's time to embrace what LM have given us. There are two ways you can do this, either using the add-on.xml method, or the command-line method, which called Prepar3d to do the work of adding your entry to the Scenery.cfg. So you can replace all your script with a single command-line call.
 
Oh God,

I just have it, no way to restore it back, lucky I had not to much sceneries installed and I have add them again manually, those where the installation was via the new P3D way was not touched and was back at the scenery.cfg from alone!
 
WarpD said:
Of course, if one used the preferred addon installation process that L-M created, the coding of said file is moot.
Click to expand...
But this does not allow adding areas below the base files which is necessary to correct the hundreds of airfields which are at incorrect elevations.
 
You must log in or register to reply here.
Back
Top