There is a freeware addon called Heavy-
Division/B78XH
https://github.com/Heavy-Division/B78XH This has over 76K downloads and any
project that uses the template ASOBO_GT_Interaction_NoInteraction will break.
And that is because these developers used the exact template name in their
ModelbeahviorDefs asset for their project. And so if a MSFS customer has this
mod it prefers to read this rewrite template over the default. And I get
thousands of emails why our touchscreen does not work. And we have to explain
to remove this addons. We contacted the new devs that took over this Heavy-
Division/B78XH and they do not
understand coding well and said they would fix it as I showed them how to make
a custom name. They simply need to use Heavy_GT_Interaction_NoInteraction.
@FlyingRaccoon Can we somehow fix this issue
for all future headaches? Let me know if you need more info. Today I created
my own custom template to bypass this bug. But I should not have to do this.
Thanks.
+1 I have two mods over the c172 that also use
ASOBO_GT_Interaction_NoInteraction and I also have a lot of complaints because
of the B78XH. The JPL/WBsim mod over the 152 is known to have the same issue
too. I agree that letting one rewrite the default templates should not be
possible. it’s an highway to obfuscated bugs.
@bagolu pointed out they have an experimental and I
found they did stop using default template names. So this is good. But 76K
downloads of the older version and incompetent devs is annoying and we need to
prevent this in the future.
yes, with all the people that tried the mod at one time and will keep it
outdated, we can consider the Interaction_NoInteraction already dead
Do we know the name of the MODs causing this issue guys? I am going to pin
this on my discord server so people clear it. Best, Raul
It’s fundamentally flawed that a 3rd party dev can overwrite ‘base’ package
content AT ALL and suddenly impact every other package in the sim. People are
doing it just because it seems trivial to do and is frankly the easiest way to
get custom behavior in your own package. E.g. the easiest way to change the
Asobo html map altitude color contours is to overwrite the official
mapconfig.json. There are obvious ‘correct’ methods to more able developers
(in this case call the stock MapInstrument but in your plane point it at your
own local custom mapconfig.json). Packages are evolving ways of sharing
content (like html gauges and model XML and the aircraft.cfg variation
technique) and the need to overwrite stock content is highly questionable. I
should admit that my first approach was to overwrite an official file but I
assumed that substitution would only apply in my package - I was shocked to
notice I’d just impacted every plane in the sim and spent the hour or two
necessary to restructure the code so the official files were left untouched.
But what is even worse is the dev did copy the Asobo template and placed it in
their own ModelBehaviorsDef thinking this would now be ok to alter. You can do
this but the name must change as the sim always looks at community first then
the sim files. And I even told the guy just rename Asobo to Heavy and solved.
And after 10 months they finally fixed it as an experimental and still have
the main file for download. And it’s at 76K downloads. The damage is done and
I had to now point to my own custom template that is basically the default
since now this default can never be trusted again. Solution: Read the sim
first then the addons.
Won’t that solution break many improvement addons that assume community files
will overwrite official ones, like the Duckworks DC-3?
The ‘overwriting stock files’ method is simply too vulnerable. In the early
days of MSFS a variety of people thought they could improve on the flat-panel
nav instruments provided by Asobo and they ALL cheated by modifying stock
files embedded deep in the Asobo solution rather than spending the time to
work out the dependency structures and create a new gauge with similar
dependencies on the stock content. Fortunately this Wild-West era has largely
abated. The quality solution is if you take the example of aircraft, MSFS has
gradually extended it’s support for one package to share the files of another
so you can create a completely new ‘package’ that uses e.g. the model and
textures and html/js instruments of another plane, while inserting your own
content where necessary. I’ve used that to create 15m and 18m wingspan
versions of the same plane - they’re mostly common files (the 15m version
shares a lot of content from the 18m package, but doesn’t overwrite it). This
capability is important but I don’t think even Asobo have fully considered its
implications, and it could certainly be improved with enhancements to e.g.
[VARIATION] in the aircraft.cfg. I don’t know the Duckworks DC-3 but if that
doesn’t give you a “new” aircraft in the sim sharing some unchanged files from
the Aeroplane Heaven DC-3, but rather overwrites files such that if you load
the Aeroplane Heaven DC-3 you see it modified by the Duckworks version, I’d
say they could have structured their mod better. I have no doubt it’s a great
mod though.
OK, that does make sense, you’d have to add [VARIATION] in all the other cfg
files to make it fully customisable, that would seem to be a better way.
Hello everyone. This is how the VFS and Template system works and policing
this is not something we want to put our foot into as there will always be
ways to workaround limitations we implement and we would risk preventing fair
usage of this feature. For example, the Working Title avionics package that
was available on the Marketplace and replacing default avionics was a good use
of this feature that we want to keep. Our best bet is that this was a
misunderstanding and the modder didn’t do it on purpose. We’re going to update
the documentation to make more clear that replacing default files or templates
should be used in very limited case and will impact the behaviour of other
SimObjects and that copying the template is possibly a better option. Regards,
Sylvain
I understand your position on this, and agree there’s not much anyone can do
to fix this except for adding a warning about properly developing for VFS in
bold letters on the front page of the SDK documentation with a link to a page
with all the problems that this flexible design can cause if not used
properly. There is, however, another half of this problem that is likely
solveable: Developers using the default names the SDK tools suggest for items
like “modellib.bgl” and “mycompany”. What happens is, multiple files with the
same name end up in the same VFS path and overwrite each other. I’m sure this
is the cause of many CTD’s customers experience with scenery downloads as
files overwrite each other, and then objects are searched for and memory
overwrites happen, etc… As I said, it’s not perfect, if they keep using the
same “mycompany” name and files when they change it, it’s still going to cause
problems, but, it’s a start. It’s not a perfect solution, but, the tool should
look for these default suggested names and paths and force developers to
change them before it will compile the package. MSFScenery developers do this
all the time. The packages work on their own, but, as soon as another package
is installed also at mycompany\scenery\modellib.bgl and other files, boom. The
solution of course is so simple, make a new path for each package, but, given
how packages are structured, this isn’t obvious to new, and sometimes even
longtime, developers. BTW, for scenery, wouldn’t it be better to suggest
“mycompany_airport” or “mycompany_packagename” or “mycompany_location”? That
would automatically make it a new path and not matter what’s inside for the
most part as long as everything was contained in that.