Aller au contenu

Photo

Managing your override folder: sub-folders a good idea?


  • Veuillez vous connecter pour répondre
18 réponses à ce sujet

#1
Heals.like.Jesus

Heals.like.Jesus
  • Members
  • 382 messages
Some mods's installation notes say to unpack the folder inside the .rar in the override folder. All's well and good, however that way you have no idea of knowing about conflicting mods right? Since only one type of file can be used by the override, having a "talent_modal.ncs" in  override/folder and another "talent_modal.ncs" in the override means one wont work.

However due to the the lack of  "...already contains a file named talent_modal.ncs...do you wish to overwrite" message you have no idea of knowing about any potential redundancy.

So my question is: Is there any harm in simply plastering all of the mod folder's contents into the override? At least that way you'll be alerted about any conflicts.

Modifié par Heals.like.Jesus, 16 décembre 2009 - 09:59 .


#2
wrinkly1987

wrinkly1987
  • Members
  • 15 messages
bump

#3
Kerad Kralc

Kerad Kralc
  • Members
  • 253 messages
Maybe try the toolset forum. That's where the game modders hang out. They probably have more knowledge about your subject.

#4
slash197

slash197
  • Members
  • 88 messages
Necropost, but, yes, you can use subfolders in your override folder. As long as a file is anywhere in your override fol

#5
Proleric

Proleric
  • Members
  • 2 346 messages
Personally, I'd be wary of content that doesn't use daupdater as the installation method. Manual hack-and-poke can damage the integrity of the game folders, creating problems that might not be apparent until numerous mods and modules have been installed.

#6
Guest_Maviarab_*

Guest_Maviarab_*
  • Guests
Overide folder will use a max of 3 subfolders....



So anything that does not come with a folder, make one yourself to put all the content in...that way it keeps it neat and tidy, and should you need to remove anything (conflict/dont like it etc) its easy to just remove the folder named (whatever texture) etc.



prolec,



The problem with the updater is thus: The DAUpdater will NOT uninstall a mod, only DAModder can do that. So, unless you are very clued up on the file hierarchy and where files are placed, it then becomes difficult to remove a mod you may have installed?



If you manually install your ods (where possible - especially if they just go in the overide dir) then you get to see what files go where in the file structure, and should you need to remove it, you know where to look :)

#7
Proleric

Proleric
  • Members
  • 2 346 messages
With DAUpdater, content once installed can be switched off using the in-game DLC manager. I agree it would be far better if Bioware provided an uninstall facility, too, but it isn't absolutely necessary.

The biggest danger comes with manual changes to folders. With that approach, players will end up with a spaghetti-like mess which can only be resolved by deleting all the custom content they've installed. The reason module builders care is that we spend many hours investigating apparent bugs in our work which turn out to be caused by unprofessional installation of other mods.

#8
J.O.G

J.O.G
  • Members
  • 355 messages
Quite on the contrary, the supposed ease of using DAUpdater just lulls you into a false sense of security.

Daupdater just  installs the zip's structure. When a dazip contains stuff for packages/core/data, the mod can't be fully deactivated without manually deleting those files. Actually, the game may even crash after deactivating, because files that are put in the package structure are still loaded (e.g. if there is an area list or PRCSCR, that refer to data from the Addin folder. Far-fetched? No such mods were already released.)

Never trust a dazip you haven't examined and cleaned up if need be. Having files in the override folder either in a sub folder or in an ERF is much tidier, because you have a clear overview of what you have installed.

In general, users should have a general idea of how mods are working or stay away from them, and modders should clean up their mods before release and provide a proper readme with install and uninstall instructions, and not just a dazip.

Modifié par J.O.G, 03 janvier 2010 - 06:31 .


#9
FollowTheGourd

FollowTheGourd
  • Members
  • 572 messages

J.O.G wrote...

Quite on the contrary, the supposed ease of using DAUpdater just lulls you into a false sense of security.

Daupdater just  installs the zip's structure. When a dazip contains stuff for packages/core/data, the mod can't be fully deactivated without manually deleting those files.


When I was shown the error of my loose, overriding ways, I created a DAZIP for the next release that put some core override stuff into the AddIns/[UID]/core/data (instead of packages, which I think I'd need a custom manifest for anyway). It seems to deactivate just fine in the DLC manager, although you need to reload the game to have certain resources reloaded.

Then again, my changes shouldn't affect the save game and aren't referenced by another addin or override, but if that's not the issue then I'm not sure when it'll matter.

Modifié par FollowTheGourd, 03 janvier 2010 - 06:47 .


#10
J.O.G

J.O.G
  • Members
  • 355 messages

FollowTheGourd wrote...

J.O.G wrote...

Quite on the contrary, the supposed ease of using DAUpdater just lulls you into a false sense of security.

Daupdater just  installs the zip's structure. When a dazip contains stuff for packages/core/data, the mod can't be fully deactivated without manually deleting those files.


When I was shown the error of my loose, overriding ways, I created a DAZIP for the next release that put some core override stuff into the AddIns/[UID]/core/data (instead of packages, which I think I'd need a custom manifest for anyway). It seems to deactivate just fine in the DLC manager, although you need to reload the game to have certain resources reloaded.

Then again, my changes shouldn't affect the save game and aren't referenced by another addin or override, but if that's not the issue then I'm not sure when it'll matter.



J.O.G wrote also...

Actually, the game may even crash after deactivating, because files that are put in the package structure are still loaded (e.g. if there is an area list or PRCSCR, that refer to data from the Addin folder. Far-fetched? No such mods were already released.)


Anything the modder has in his override folder is available for selection when creating the dazip and will be put into an ERF in Packages/Core/Data where it works like a hidden override folder.

I'm not pillorying any mods here, but some of them on the social site have this problem and even warn you that your game will crash if you deactivate them without deleting that erf in packages... Fixing the problem is just a matter of opening the dazip and moving the packages erf to the core folder.

Telling users and modders that folders are evil just encourages new modders to make those mistakes.

Modifié par J.O.G, 03 janvier 2010 - 07:11 .


#11
FollowTheGourd

FollowTheGourd
  • Members
  • 572 messages
Hm, guess I have to look at that again then, but I take it Addins/[UID]/Core/Data shouldn't be a problem as long as any other pitfalls are avoided, since at least it's separated and (assumably disabled) by a UID... I just wouldn't mind avoiding causing problems for others.

Modifié par FollowTheGourd, 03 janvier 2010 - 07:06 .


#12
J.O.G

J.O.G
  • Members
  • 355 messages
No, it's just the files outside the Addin structure, that what appears in the packages folder when you open the dazip (it's just a renamed zip file) When there is just an empty erf, it's fine, you still can delete it though. Otherwise move the erf to UID/core.

Modifié par J.O.G, 03 janvier 2010 - 07:10 .


#13
Proleric

Proleric
  • Members
  • 2 346 messages
If it's possible to create this problem using the toolset legally, I'd say it's a bug which Bioware needs to fix. The professional mindset is about using tools which ensure integrity.

#14
J.O.G

J.O.G
  • Members
  • 355 messages
IMO, the professional mindset should about information. Only a well known and monitored environment can be safe. Things that happen secretly without information are questionable.

DAUpdater and the toolset give you the option to install stuff into the main game, because it is DAUpdater not DAAddinInstaller. Every modder is responsible to know how his mod installs and what effects that will have. But every user is also responsible to keep his system clean. If he doesn't want to he shouldn't use mods.

I'm not saying that people should use the override folders I'm just saying that sermonizing about using dazips without pointing out the things you have to keep in mind if you do so, is much more dangerous to integrity.

Modifié par J.O.G, 04 janvier 2010 - 08:14 .


#15
Proleric

Proleric
  • Members
  • 2 346 messages
Realistically, few players will ever acquire an in-depth knowledge of the exact function of the 40+ folders mentioned in the wiki. It seems to me that it would be respectful to our players and to our fellow builders to use the Bioware delivery system as far as possible, i.e. toolset export, dazip and daupdater, following the standard folder naming convention.

If there are bugs in that approach, I'd suggest the onus is on the builder (not the player) to report the bug to Bioware and work around it temporarily.

Given the complexity of the tools, I haven't been able to perform a comprehensive test of all scenarios, but, judging from this thread, the only known bug is that the toolset export puts some files into Documents > Bioware > Dragon Age > Packages > Core.

I'm not aware of any scenario in which that's a valid outcome (though of course I'm open to correction).

In my own tests, those files are mostly harmless script headers, but I'm also getting a few plot files (e.g. plt_cod_aow_spellcombo9.plo) even though I'm using toolset 1.01. My solution is to delete those files for good order before the Builder-to-Player export. With that workaround, deactivating my add-in in-game switches off all my custom content.

I take it on trust from the above that sometimes files turn up in packages > core which are actually required for gameplay. I'm sure Bioware would like to see examples of this. The workaround of moving them to the addins folder before making the dazip seems good.

Ultimately, if everyone just does their own thing, I can just issue my modules with the advice to delete all other custom content first, but it seems a pity to do that when a little prudence across the community would allow many mods to co-exist.

Modifié par Proleric1, 08 janvier 2010 - 11:21 .


#16
Jhime

Jhime
  • Members
  • 162 messages
Could someone explain to me how packages/ vs addins/ work? I tried moving the ERF files from The_Icons_Project from packages/core/data and packages/core/override to addins/The_Icons_Project/core/data and addins/The_Icons_Project/core/override but then they wouldn't load. Anyone know why that is?

#17
Proleric

Proleric
  • Members
  • 2 346 messages

Jhime wrote...

Could someone explain to me how packages/ vs addins/ work? I tried moving the ERF files from The_Icons_Project from packages/core/data and packages/core/override to addins/The_Icons_Project/core/data and addins/The_Icons_Project/core/override but then they wouldn't load. Anyone know why that is?

The folder hierarchy is documented here, but it doesn't fully explain why there are so many different folders.

#18
Lordofpownage

Lordofpownage
  • Members
  • 1 messages
Ummm..... where exactly is the override folder and the addins folder and stuff? I've looked everywhere and cant seem to find them.  Are they named something else, or could I have accidently deleted them?  I searched my program files \\86 or whatev and the dragonn age folder checking literally every subfolder in every folder and everywhere I could find.  I really have no idea what I'm doing and what I'm supposed to do with these ".rar" files as I can't just drag themm into the DAmodder and click install.  =(

#19
Qutayba

Qutayba
  • Members
  • 1 295 messages
The override folders are actually under your local documents (My Documents/Bioware/Dragon Age) and not in Program Files. This is a good thing, because if you have Vista, changing things in the Program Files requires dealing with multiple annoying pop-up Windows windows (Of course I have permission! I'm the administrator, owner, and sole user! - Sorry, Vista does that to me sometimes :) )
As for .rar files, you need to install a free extractor.  It's an alternative to the .zip format.
download.cnet.com/WinRAR-32-bit/3000-2250_4-10007677.html

Modifié par Qutayba, 13 janvier 2010 - 06:18 .