[BUG] Airplane Registration stroke color and font

[MSFS 2020] Questions & Community Discussions Aircraft
1

Dear Asobo, With AAU1 release we just noticed the registration numbers using
strokes fonts have stopped working. We just noticed it today, it is unclear if
this stopped working on SU11 or AAU1. However we are 100% certain this was
working in SU10. Here is a Picture on SU10:

1234×694 877 KB
Here is a Picture on AAU1:
1234×694 1020 KB
Note the missing white outline
on the registration. The code to use stroke fonts is used like this in
panel.cfg:

[VPainting01]
size_mm                = 2048,512
texture                = $Registration
location             = exterior


painting00=Registration/Registration.html?font_color=black& **stroke_size=50 &** **stroke_color** **=white** , 256, 100, 1536, 384

Would it be possible to fix this feature? was working absolutely fine before.
Kind Regards, Raul

2

Very nice – I had not considered using “font stroke”, so I tried it,

1542×143 5.98 KB
and for me it does seems to
work, running on the latest beta ( with all the WT features enabled, which I
assume is the ref to AAU1 ?)
1884×888 630 KB
However, the registration on the
under surface of the wing, while also “maybe” gaining a Stoke, seems to have
the incorrect stroke color.
1466×928 233 KB
Needs a little more
investigating & testing …

3

You calling registration172x.html, where I am using registration.html
different parts of the base code. Clearly the registration.html stopped
working at some point. We need it fixed. Thanks for testing and contributing.
Regards, Raul

4

Dear All, Further testing has revealed a vanilla install of MSFS allows the
registration.html and it’s components to works as required, therefore we
started debugging why is it that our users are reporting this issue. The
investigations has revealed 3rd party developers are copying the Asobo base
registration.html, registration.css, registration.js, modifying it and
shipping it with their products, causing the issue on this post. Below a
sample of this behaviour:

1440×238 174 KB

1440×228 170 KB

1440×226 156 KB
So it seems Carenado (on
official folders), FBW and potentially many others are doing this without
understanding the concecuences. The result of the practice above is that the
VFS system will override the default Asobo registration livery code in favour
of one of the ones above (the last to load), and if the javacript, css or
.html has been modified with the intention to suit a 3rd party developer own
needs, it will force everyone else (including asobo default airplanes) to use
it. This creates bugs now that cannot be repaired by Asobo given the extend of
the damage, leaving not only my customers with an issue but many others
developers also with issues. This is not the first time we have problems with
developers performing this practice, it happens far too often now, it has
happened with model behaviours, causing very nasty bugs and it happens all the
time as well with base files coherent JavaScript code, causing avionics to go
all wrong, leaving customers very upset, leaving bad reviews and rating not
understanding that a 3rd party content using bad developing practices is the
cause. I think it is important now to start bringing more awareness of this
situation, it would be helpful if perhaps the SDK can explains that overriding
system base files this way is not recommended, why and what concecuenses it
can bring. It would be also useful to have some sort of alert to end users
when base files are being overridden like this, so they can pin point any 3rd
party content causing issues since every time we get reports of avionics not
working, users are left to remove their entire list of addons and spend hours
and hours trying to find out what is causing the issue. Ultimately it would be
better if MSFS could prevent certain files from being overriden by the VFS, I
understand this might not be posible, but please consider the chaos this is
causing as the number of addo-ons continue to grow everyday. Lastly, guys,
PLEASE STOP DOING THIS…if you want to edit a base file, copy it, rename it
and reference it properly in your project so it doesn’t affect any other 3rd
party developer. As a result of this issue I have now no other option than
copying the original Asobo registration code (which works as it should), fork
it, rename it properly inside my own company folders as we all should do,
reference this new code it all over my liveries, ship it as part of my
package, submit to Marketplace, wait for weeks for them to release it and then
update lots and lots of freeware mods with liveries all over the place over
the internet… All this so a registration can work as intented. It shows the
effort and time I have now to put in place due to 3rd party developers not
understanding the consequences of their actions for the rest of the community.
This is a situation that keeps repeating itself over and over again, and it is
increasing, we need to stop this madness some how… Best Regards, Raul

5

Lastly, guys, PLEASE STOP DOING THIS…if you want to edit a base file, copy
it, rename it and reference it properly in your project so it doesn’t affect
any other 3rd party developer. 100% agree, (which is why there was no issues
when we (WB-SIM),made our own edited/renamed version of the registration code
) But as demonstrated by Simbol, there are Devs whose products are modifying
the base sim, thus upsetting other Dev’s objects. (seems to be mainly Carenado
overwritting Asobo official files :frowning: ) Fortunately, now this issue is
identified, its easy enough to check one’s MSFS install, and detect this,
either manually (for a particular file), or better still, with an automatic
tool, that will check for all cases of base sim modification / potential
overwrite. Ideally, such a tool might be considered for inclusion in the SDK ?

6

Looks like there really needs to be a more formalized naming system, where the
original file is renamed to a unique new name that contains BOTH the Devs name
and the Unique Plane. ie Everyone renaming registration.js to
oemregistration.js does not help Better universal convention / rule might be
registration_[dev name]_[plane model].js ie registration_Carenado_Pa44.js

7

The FlyByWire and Fenix ones are not conflicting. The paths in the VFS are
html_ui\Pages\VLivery\Liveries\ A32NX_Registration \Registration.html, and
html_ui\Pages\VLivery\Liveries\ FNX320 \Registration.html, as you can see
in your screenshot.

8

Even better, always put your stuff in a subdirectory named for your
company/group and product, like the FBW and Fenix examples above. Then you can
have whatever filename you like and it won’t conflict.

9

Agreed. Company name is not enough for a VFS root directory, it has to be
CompanyName_&_Product. First of all, a lot of developers just use the default
names that the dev mode editors add, like “mycompany”. So now there’s a ton of
packages out there with “mycompany” as the root vfs directory. But let’s say
that a developer avoids this mistake, but uses the same “NewCompanyName” for
all of their packages, and then creates a bunch of packages with
“NewCompanyName/scenery/modellib.bgl” files across their packages for example
(like MSFScenery does all the time), then, once again, boom, if those
modellib.bgl files are different, only one of their packages will work, and
customers risk CTD’s as well. This whole subject is a HUGE problem. I
understand the benefits of the virtual files system and the ability to
overwrite files, but those benefits are overriden everywhere by lack of
knowledge and the incomplete nature of the SDK. I understand how hard it is to
write documentation, how much effort it takes, and it is literally impossible
to write all the details about anything, but, somehow this issue needs to be
addressed. It seems to me an emergency update of Carenado (and other?)
products is required. Certainly this is something that could be caught by the
Marketplace review process before release, i.e. that any files found to
overwrite official files like this could be caught and then reviewed if those
changes will cause unintended consequences, and make sure those files are put
in unique VFS paths? It would also be a good idea to catalogue all of the
devmode editor suggested names (like “mycompany” and “modellib.bgl”) be
searched for and submissions rejected until they properly VFS name and path
files to avoid issues like this. I too am trying to develop liveries and every
time I try to do anything I’m stymied by one problem like this or another.

10

Searching manually for such core file overwrites, is very time consuming &
hit-and-miss. But this is something computers can do very well. Could a tool
be included in the Dev Console to warn if a plane being developed, is
overwriting core files. Even better, also an exteranl tool that checks the
whole of MSFS, and all installed content, to identify such “unintentional”
overwrites. Such a tool would also make a great addition to “MSFS Addon-
Linker”

11

I think this would be good as a stand alone suggestion, so we can vote on it
and Asobo can track it.

12

Since @Simbol was the original poster, and exposed the issue, maybe he would
like to be the one to submit it as a WISH / Suggestion to Asobo

13

Well, its August 2024 and after buying the Carenado 182 I hit the same problem stroke outline disappeared on another aircraft - sure enough registration/registration.html was in the package.

Having a 3rd party screw up my install is infuriating enough, but having it happen when obtaining the product through the official store is inexcusable.