...and I ran into a few questions.
So, here's the wiki entry that mentions the override hierarchy - http://social.biowar...tory_priorities
Here are a couple of Bryan's quotes on the override aspect...
BryanDerksen wrote...
From http://social.biowar...362481/2#380259
I think having standalones appear under the Downloadable Content tab is how it's intended to work. Standalones can include changes to core contents that affect other modules, so it's important to be able to disable them.
I'm not sure how the system is supposed to interact with savegames. Check the "Extended Module" property of your module to ensure that it's set to "(None)", but it could be that standalones are supposed to be considered required like this on account of how their core resources could potentially impact other nominally independant modules. For example, you could have a standalone module that adds new core spells to the mage class and your OC mage would be able to add those spells without an explicit dependancy existing between the two.
BryanDerksen wrote...
From http://social.biowar...222534/1#246035
Actually, stuff in the addin's
override directory doesn't get loaded into memory by the game at all
unless that addin is explicitly part of the currently active module
hierarchy. For example if you had two stand-alone campaigns, they could
in theory have overlapping 2DA IDs without fuss since only one of them
would be loaded into memory at a time. So coordinating IDs may not be
quite as pressing a need as it first seems. Still a good idea, though,
since there are potential gotchas (stuff in an addin's _core_ override
directory gets loaded into memory regardless of whether the addin is in
the heirarchy or not, for example. These various override directories
make my head hurt sometimes).
Now, questions -
1) If I create a stand-alone module that overrides a couple of core scripts or even a couple of core events or adds a couple of core spells (like mentioned in the quote above), why would those changes be available in the OC? Shouldn't those be available only when my module is being played? Isn't that like the whole purpose of having add-in vs module?
2) If I release a module and later on, release an add-in to that module with some core overrides, it would appear that those overrides would get loaded into memory always (based on 2nd quote)! Why is that so? Shouldn't they be used only when playing the module that add-in is designed for?
3) What would happen if multiple modules are all overriding the same core script? What is the order of loading then?
4) I understand we can enable/disable installed content but the problem is anytime we do an export from the toolset, the module is automatically enabled in the list. If that module we export from toolset is overriding core scripts, any other module we load will require that module. So, is there a way we can prevent exported modules from being automatically enabled?
5) Will we be able to create anything other than 'Add-In' type in the future? The wiki mentions a 'Module' type but I don't even see that field available to edit.
Any clarification on this would be welcome. I searched and couldn't find anything...
I've also linked the original threads where Bryan posted these...in the off chance that I am taking those comments out-of-context.
Retour en haut
