11 réponses à ce sujet

[Phaenan]

Hey in there.


Preambule :
I tried to look around to see if that information is already available, but I can't seem to find it. So apologies yada yada if I was the only one left in the community being unaware of this.


Probably everybody heard that dazip end-player packages can't be used to distribute core overrides resources. Well, me at the very least, I always thought that to be true.
However, the toolset is actually what's at fault. When building the end-player packages, it pushes all the core/override resources selected in the manifest into one ERF package which ends up in the core/data folder within the DAzip. So, when DAUpdater extracts the dazip, the ERF logically remains in core/data and nothing is - duh - overrided.

I'm sure I'm not the first one coming up with a fix 'cause it's as easy as easy can get. But as I was saying, I don't remember anyone posting something like that over here. Anyway. Dazip being nothing more than zip archives, one can simply :
- Extract the toolset generated dazip
- Go to Contents / packages / core / data
- Replace that package with an empty ERF package (is it necessary ? I only did it 'cause there's always an empty ERF in there)
- Go back to Contents / packages / core
- Create an "override" folder
- Copy your original core override ERF package there. Or simply move the one found in Contents / packages / core / data instead of replacing it
- Go back to the root level (where the manifest file is)
- Repack everything using zip compression

That's it.
If your players drop that modified dazip on their DAUpdater, the core override files are properly extracted :

Everything is - of course - working fine in-game. And we no longer need to say players they have to use DAModder or DAModmanager to install our packages, if they don't want to. 

Modifié par Phaenan, 04 mars 2010 - 02:48 .

[Sunjammer]

Nice catch!

[Adaram]

Nice catch. I vary between DAModder and DAUPdater. The only things left that DAModder does for me are make me a clean backup before I mess with things, and make the updates to my Addins.xml file (on uninstall). But I agree that we are now learning ways to work around the actual and the perceived limitations that we found with DAUpdater.

[fluffyamoeba]

For many things you don't need to put it in packages at all. It seems to show up in any module if you put things in Addins\\AddinName\\core\\override (and enable the addin in game, though they are enabled by default).

[ladydesire]

Interesting; I was always under the impression that Bioware wanted us to use M2DA's, custom event handling scripts, and our own spell and ability scripts...  

[fluffyamoeba]

It means you can do something like the PRC as an addin, which can be enabled and disabled and not as a global always on thing. Which a couple of people might have nagged Bioware about at the builder's events...

[ladydesire]

fluffyamoeba wrote...

It means you can do something like the PRC as an addin,
which can be enabled and disabled and not as a global always
on thing. Which a couple of people might have nagged
Bioware about at the builder's events...

I think we are talking about reaching the same end result; we're just using different methods to achieve that result.

[Proleric]

ladydesire wrote...

fluffyamoeba wrote...

It means you can do something like the PRC as an addin,
which can be enabled and disabled and not as a global always
on thing. Which a couple of people might have nagged
Bioware about at the builder's events...

I think we are talking about reaching the same end result; we're just using different methods to achieve that result.

As I understand it, that's certainly true of using Addins\\AddinName\\core\\override or the alternate techniques you mentioned. Various dev posts have left me thinking that overrides should be avoided if possible, but they do work, so I guess it's a matter of style and maintainability.

The packages\\override route seems to be different, though. IIRC, that's the one you can't turn off by disabling the add-in. I'm not sure why we'd want to do that?

Typically, the toolset exports core resources to Addins\\AddinName\\core\\override. The stuff it sends to packages\\override generally appears to be a bug (though no doubt there might be one or two exceptions). 

Modifié par Proleric1, 06 mars 2010 - 09:10 .

[Phaenan]

Proleric1 wrote...
The packages\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\override route seems to be different, though. IIRC, that's the one you can't turn off by disabling the add-in. I'm not sure why we'd want to do that?

Because some stuff isn't actually overriding the game resources when placed into Addins/ ID / core / override. Tintmaps, for instance, since that's what was into the ERF package forcing me to look for solutions. If I move back that ERF package to the addin own core / override, the tintmaps remain the DA original ones. And therefore I'm guessing the same logically goes for other resources.
Example :

If Addins/ ID / core / override was working properly, sure, the matter would be different and using the packages tree wouldn't be necessary or recommended.

Modifié par Phaenan, 06 mars 2010 - 01:49 .

[Proleric]

Phaenan wrote...

...some stuff isn't actually overriding the game resources when placed into Addins/ ID / core / override. Tintmaps, for instance...

I've added that to the wiki as an exception. Do you have any other examples?

I wonder if this might be because tintmaps are not made with the toolset? The Addins folder works fine for toolset output, 2DA tables etc.

[Phaenan]

Hmm...
If I remember correctly, I had the same problem a few months ago with some item resources overriding OC items. (such as a topaz resource with useable ability)
I had to push those .uti resources into the packages folder because they wouldn't work in Addins / id / core.

Aside from that, nope, nothing else. I usually try not to step on the core resources toes, so I'm falling short of examples here.

Modifié par Phaenan, 06 mars 2010 - 07:08 .

[TimelordDC]

Yes .uti resources don't override OC items when placed in addins core override - we have this problem with Arms and Armor.