The patch restores the original baseinstrument.js

[MrFuzzy 2,118]

I don't know if you realized it already, but as per subject after the patch you will have to add the cockpit instruments update limiter strings again in the JS file.

More info here: 

 

[kt069 569]

Yes. It is better for you to put the related file into Community Folder to keep it as it is.

[Kopteeni 819]

So now everyone who's installed this hack without knowing what they're doing are going to report MASSIVE stutters and loss in fps after the latest patch while blaming Asobo for it. And this forum is starting to look more and more like xplane.org.

[MrFuzzy 2,118]

1 hour ago, kt069 said:

Yes. It is better for you to put the related file into Community Folder to keep it as it is.

This is a possible solution, but in this way in the eventuality that they fix the fps issue in the future, you would keep the low framerate gauges with no benefit.

(I know, maybe I have too much faith in them 🙂 )

[Colonel X 1,428]

The final version of the tweak is just a drop in:

https://forums.flightsimulator.com/t/small-js-config-file-mod-to-gain-10-15-fps-in-airliners-and-glass-cockpit-planes/221308

[MrFuzzy 2,118]

51 minutes ago, Colonel X said:

The final version of the tweak is just a drop in:

https://forums.flightsimulator.com/t/small-js-config-file-mod-to-gain-10-15-fps-in-airliners-and-glass-cockpit-planes/221308

In the 2nd picture, how can the instruments work at 48 Hz if the framerate is 54.7? 

54 / 3 = 18 which he defines "choppy" later. However, choppy or not, it's what we have now... I would always keep it on 3 (minimum on 2).

if ((this.frameCount % 3) != 0) (instruments working at 48Hz, very usable):

[Colonel X 1,428]

I think 15Hz is more than sufficient on the airliners. I wouldn't even notice the change unless I look very closely.

[onurair 24]

Hmm what bothers me more is that the update didn't reset the baseinstrument file...

I still have 2 in there after the update.

[Colonel X 1,428]

25 minutes ago, onurair said:

Hmm what bothers me more is that the update didn't reset the baseinstrument file...

I still have 2 in there after the update.

When you get the package in the above link, there's a backup of the original file included. Just overwrite and never deal with that folder again.

[onurair 24]

8 minutes ago, Colonel X said:

When you get the package in the above link, there's a backup of the original file included. Just overwrite and never deal with that folder again.

Yes will do so. Thank you 🙂

[kt069 569]

3 hours ago, MrFuzzy said:

This is a possible solution, but in this way in the eventuality that they fix the fps issue in the future, you would keep the low framerate gauges with no benefit.

(I know, maybe I have too much faith in them 🙂 )

You can delete the fix and check the original files performance. If it is not okey, you can again use the fix in the community folder. I did this after the patch.

Edited September 3, 2020 by kt069

[smoothchat 99]

3 hours ago, Colonel X said:

The final version of the tweak is just a drop in:

https://forums.flightsimulator.com/t/small-js-config-file-mod-to-gain-10-15-fps-in-airliners-and-glass-cockpit-planes/221308

In the manifest.json, that patch refers to asobo-vcockpits-core

It should refer to asobo-vcockpits-instruments

I'm surprised that it works.

Also, the 1.7.14 version of BaseInstrument.js has changed, so it is wise not to use the patch as it will reverse the changes the devs added since 1.7.12.

Edited September 3, 2020 by smoothchat

[kaosfere 3,115]

15 minutes ago, smoothchat said:

In the manifest.json, that patch refers to asobo-vcockpits-core

It should refer to asobo-vcockpits-instruments

I'm surprised that it works.

Also, the 1.7.14 version of BaseInstrument.js has changed, so it is wise not to use the patch as it will reverse the changes the devs added since 1.7.12.

That section in the manifest is just a list of requirements.  It's probably not technically correct as it is, but it's not going to stop the mod from working as long as what it actually needs is there.

And the update did not change BaseInstrument.js.   I took an md5 checksum of every file in my LocalCache folder both before and after the update and the _only_ things that changed in it were the manifest.json and layout.json of each package.  The manifest.json increased the package version number, and the layout.json had new timestamps.  That's it.

The changes in this release seem to have only been contained within the "core" part of the sim, and not any content.

Edited September 3, 2020 by kaosfere

[smoothchat 99]

Thanks kaosfere,

I was under the impression that the dependencies specified which top level folder to look in for the BaseInstrument.js file.

It certainly seems to make a difference with liveries as all the textures are effectively named the same and there has to be some way of pointing to the right directory tree.

I stand to be corrected.

Edited September 3, 2020 by smoothchat

[kaosfere 3,115]

The way is works (and this is one of the few things that's actually documented) is that when the game starts it builds a virtual filesystem containing all its content.  First it loads everything in the Official directory, then it loads everything in Community   The stuff in Community is read in alphabetical order and every package overlays the one before it.  It basically "stacks" everything in Community.

If you look at the actual content of the packages, it all starts at the same top level, for example each of the plane packages in the livery pack will have its own unique SimObjects directory at the top of the zip file.  These don't actually overlap in terms of  what the actual files are so there's no conflict there.

Since the sim doesn't seem to "care" at this point about the details in layout.json, but it did correct folks BaseInstruments.js when they made the change there, my best guess is to how it works is the updater reads every packages layout file and the scans the content in to make sure the size of every file listed in it match what's in the layout.  If not, the file gets updated.  It doesn't seem to care about the time at all, unless it's looking at ctime, rather than mtime.  That would take a little experimentation to determine.

(The packages I build have a properly created layout.json with file with accurate sizes and timestamps.  Even if it's not technically necessary, might as well do it the right way when you can.  There's no way of knowing when it *will* matter.)

Edited September 3, 2020 by kaosfere