6 réponses à ce sujet

[Mengtzu]

So I'm able to extend my standalone module with add-in modules, that's easy and great.  I can override conversations etc. in the base module easily enough by including the appropriate file in the add-in's override directoy, yay.

Keeping it straight in the toolset seems to be the problem, I think I'm doing it the wrong way.  When I edit a conversation with the add-in module open, it changes the one in the base module and exports it there.   I can't just live with the changed file because I need to support the original module.   What I've done is copy the edited exported file into the add-in's override directory, and then change it back to the way it was (I guess I could also restore from a backup or what have you). 

While that works, it limits me to doing extremely modest overriding, since after a couple of add-ins it'd be a horrid unmaintainable mess.  Hence I'm sure I'm doing it wrong and overlooking an easy way to concurrently have original and overriden versions in the toolset.  Can anyone point me at that easy way?

[anakin5]

what are the properties of you standalone module and of your addin module ?

What are the properties of your standalones files and addin files ?



I mean, "Module", "Owner module", "Extend Module", "Content Module" and "Hierrachy"

[Mengtzu]

Base Module: No extended or content module, Core in hierarchy



Add-in: Extends Base Module, no content module, Core and Base Module in hierarchy



The relevant files (that is the ones from Base Module that I'm trying to override) both have Base Module as their Module and Owner Module. Changing those settings doesn't allow me to create a duplicate with the same name



Cheers!

[Proleric]

In general, I'm puzzled by the toolset constraint that a resource name must be unique across the entire database.

If I've understood correctly, if module A has an add-in B, it should be possible to have two versions of conversation X (A.X and B.X). In game, if B is enabled, B.X takes priority, otherwise A.X is used.

Problem is, as noted here, the toolset objects to creating B.X on the grounds that X is a duplicate resource name.

Does anyone have a better understanding?

[ChewyGumball]

Is it that the overriden files don't get overridden for editing in the toolset, or that when you edit the override file, the changes are saved in the base file? If its the former, theres probably something wrong with how you are overriding. If its the latter, which I think it is from your description, there are a number of possible causes. The most nasty would be that the programmers didn't forsee this use of the toolset (kind of short sighted ) and made it only save files to the base folder and not the override one. Otherwise there might be a path that needs to be changed in the module properties that is pointing to the wrong place, or even a toolset setting that can change where things are exported too.

[Mengtzu]

It's the latter. I can get it to work just fine from a user's point of view (ie the module changes the way I'd expect it to depending on whether the add-in is enabled or not), but on my end it's a potential horror show

[Proleric]

Of course, the toolset is working with its own data base, which is independent of the export folders.



I guess what's happening in the toolset is that you only have conversation A.X (using my previous notation). When you're working on add-in B, you can still edit A.X, because B inherits resources from A. Exporting module B will include the modified X, so this will work from the players' perspective. However, the toolset now has a modified X, even when you open module A.



If that's correct, then the question remains - how do we make different versions of resource X in two different modules A and B?