Dev: Restructuring of directory structure about fspackages HOT 4 CLOSED

I think this is the best approach for our files. It achieves the goal of making sure that if we are in control of init, we are in control of which files get loaded via the html. It is still possible for a later mod to override a core in the original position but if we assume that other mods will use similar methods to be well behaved it should minimise the chance of breakage to a state where one of the mods simply won't work rather than the 2 mixing strangely.

Branching at html\pages_ui means that looking at the HTML will make it very clear when we're loading files we've modified as it's right at the beginning of the URL, though I would not strongly argue that this alone is a compelling reason for that. The main benefit is we never have to worry about creating a WT folder later down the line as that's the html root directory.

As an addendum though, I would like to suggest that for the G1000 html files, we do override the root path because unlike the CJ4 we are modifying multiple planes. We can of course include multiple cfg files but I don't think this is a particularly great approach, especially for anything that uses the G1000 down the line. I can see a good argument still for doing it with the cfg files though, so if anyone feels like there's a particularly compelling argument for one side then it'd be good to hear.

from fspackages.

@knighty Yeah. I would suggest having a separate task for the G1000 mod as your setup is different

from fspackages.

One thing I would suggest, and @knighty and I were talking about this last night, is reconsidering where you add the alternate WorkingTitle reality. In my mind it makes more sense to branch at the location where you are introducing new code. In other words, I'd suggest a system that looks like this (just to mix up some stock, modified, and new files at different depths like we're likely to see):

html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\BaseAS1000.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\WorkingTitle\Engine.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\WorkingTitle\BaseAS1000.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\PFD\WorkingTitle\AS1000_PFD.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\CommonPFD_MFD.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\WorkingTitle\CommonPFD_MFD.js
html_ui\Pages\VCockpit\Instruments\Shared\WorkingTitle\DataStore.js
html_ui\Pages\VCockpit\Instruments\Shared\WorkingTitle\FileHandler.js

Than this:

html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\BaseAS1000.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\Engine.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\BaseAS1000.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\AS1000\PFD\AS1000_PFD.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\CommonPFD_MFD.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\CommonPFD_MFD.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\Shared\DataStore.js
html_ui\WorkingTitle\Pages\VCockpit\Instruments\Shared\FileHandler.js

For my eyes/brain, it both looks cleaner and feels better and faster to start with the leaf node then track backwards until you find either a divergence point or the root, than it does to scan all the way back to the top past everything. But that's just me. 😁

from fspackages.

I finally understand where this disagreement is coming from now from your example files.

html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\CommonPFD_MFD.js
html_ui\Pages\VCockpit\Instruments\NavSystems\AS1000\Shared\WorkingTitle\CommonPFD_MFD.js

This would never exist. The idea was that if we touch a core file, it ends up in our own directory structure so there's no way a later mod can come along and touch it, and we will always be using that file because we have control over the init process. (mods can still replace core files we don't touch but there's no solution there, sans duplicating the entire package directory). If you wanted to subclass an existing class than I would give it a different name, like our WTEngine which I think is a situation where it is fine to have a prefix on the class/file as it is a subclass rather than something new.

I do see where you're coming from though, by doing it your way it means sub classes are a bit cleaner which is maybe the direction you were coming at it from having just come off the back of the WTEngine code

from fspackages.