34 réponses à ce sujet

[Rolenka]

Deleting it from the addins folder sure seems to work... does DAUpdater leave some sort of data behind elsewhere?

[fluffyamoeba]

Depends on the mod. But usually there's data in [my docs dragon age folder]/packages/core and also if done using the DAUpdater, there's an entry for it in Addins.xml that needs removing. Not sure it still qualifies as difficult, but you do have to look in 3 places.

[Hammer Fang]

Just deleting the mod from your addin folder orphans any resources you made in the data base for that mod. So to correctly delete a mod, you need to delete each resource, then delete the addin folder, or so I've read in the wikki.



gg

[Rolenka]

Hammer Fang wrote...

Just deleting the mod from your addin folder orphans any resources you made in the data base for that mod. So to correctly delete a mod, you need to delete each resource, then delete the addin folder, or so I've read in the wikki.

gg

Interesting, I can't find this page on the wiki. Not the builder wiki, the official game wiki or the unofficial game wiki. Got a link?

[thebigMuh]

The database thing is only true for the builder, not for the end user.



If you keep your mods nice and clean, the only things an end user should have to remove are the AddIns\\<youraddinname> folder, and the entry from the AddIns.xml.



Deleting a mod from the toolset is more involved, however. Check here: http://social.biowar...leting_a_module



Ciao, muh!

[Rolenka]

Right, I meant for end users. Thanks.

[Rolenka]

Hmm, I'm going to have to disagree and say addins.xml fixes itself if you just delete the mod from the Addins folder. I've done this with mods in the past, and looking at my addins.xml, their entries are gone.

Modifié par Rolenka, 24 janvier 2010 - 05:57 .

[Hammer Fang]

thebigMuh wrote...

The database thing is only true for the builder, not for the end user.

If you keep your mods nice and clean, the only things an end user should have to remove are the AddIns\\\\ folder, and the entry from the AddIns.xml.

Deleting a mod from the toolset is more involved, however. Check here: http://social.biowar...leting_a_module

Ciao, muh!

unless you do a builder to builder load, in which case, the module is loaded into your data base. Which means you will need to delete each resource you loaded.

gg

[Proleric]

End users never need to do builder-to-builder loads.

The toolset puts files in [my docs dragon age folder]/packages/core unnecessarily, so it's good practice for the builder to delete them before making the dazip for the player. That way, the player has nothing to delete except the add-in.

There might be some exceptions to that rule-of-thumb, but I haven't found one yet.

Modifié par Proleric1, 25 janvier 2010 - 08:56 .

[fluffyamoeba]

1. If it's a character creation resource you want to have available in the standalone character creator (it doesn't read from the addins folder)
2. If sharing resources over multiple addins (though you may as well duplicate them rather than put them in here unless they are large files such as art resources).

edit: (now with added caffeine ) a better option for #2 is to make an addin that contains the shared resources and have each of the others inherit from it.

Modifié par fluffyamoeba, 25 janvier 2010 - 09:24 .

[Mordaedil]

My experience has it that just deleting stuff may force you to do a reinstall of the game, the toolset and delete most of your Bioware/Dragon Age resources.

[Proleric]

Mordaedil wrote...

My experience has it that just deleting stuff may force you to do a reinstall of the game, the toolset and delete most of your Bioware/Dragon Age resources.

Are you saying that a player who deletes an add-in folder from Documents (as discussed here) could have this problem? Or simply that deleting random files from the game installation can cause problems (which nobody can deny)?

[Mordaedil]

The former.

[Proleric]

That's really strange. What symptom forced the reinstall?

[Adaram]

I use DAModder, personally. It deletes the files, and the addins.xml entries, and makes backups of everything before it does anything. If you haven't seen it before, check it out Here

[fluffyamoeba]

Yet everyone seems to use it to dump random things in the override...

[Mordaedil]

Proleric1 wrote...

That's really strange. What symptom forced the reinstall?

I was making what I thought was my own stuff in the toolset, so I figured "if I delete this stuff, from my AddIn folder, it won't have any consequence for the game."

What I didn't expect, was that the database didn't know stuff had happened and decided to pull a "lulz-wut?" on my main game when I tried to load it.

[Eshme]

Is the database from the toolset connected to the game? I didnt think so. And i would like to have seen the games reaction lol

[Mordaedil]

Eshme wrote...

Is the database from the toolset connected to the game? I didnt think so. And i would like to have seen the games reaction lol

It is. The reaction was that all text and icons vanish.

[Rolenka]

Mordaedil wrote...

Eshme wrote...

Is the database from the toolset connected to the game? I didnt think so. And i would like to have seen the games reaction lol

It is. The reaction was that all text and icons vanish.

I've heard that can happen if you fail to delete the core talk table from toolsetexport that's generated whenever you export a custom talk table.

[Proleric]

So it seems that Mordaedil's issue, while interesting, is slightly off-topic, as it's about removing a module from the toolset.

Regarding players, in summary, the actions for responsible builders seem to be

1.  Delete unnecessary files from [my docs dragon age folder]/packages/core before making the dazip

2.  Provide uninstall instructions (normally, delete addins folder + xml entry)

So far, the known exception to (1) is a character creation resource you want to have available in the standalone character creator (it doesn't read from the addins folder).

DAModder might be one way of doing (2) but some builders have reservations about it.

Modifié par Proleric1, 26 janvier 2010 - 05:44 .

[FollowTheGourd]

Proleric1 wrote...

2.  Provide uninstall instructions (normally, delete addins folder + xml entry)

So far, the known exception to (1) is a character creation resource you want to have available in the standalone character creator (it doesn't read from the addins folder).

DAModder might be one way of doing (2) but some builders have reservations about it.

Seems to me that having a user edit AddIns.xml themselves might do more harm than good in the general case. I suppose it doesn't hurt to mention it somewhere, but I don't think we should be pushing it over just disabling the mod in the DLC panel for now; any malformed XML, and it'll look like all their DLC just vanished.

Players are going take their choice of using DAModder whether or not builders approve of it, but it seems better to me than having to walk somebody through editing an XML file.

Modifié par FollowTheGourd, 26 janvier 2010 - 06:36 .

[Proleric]

FollowTheGourd wrote...

Seems to me that having a user edit AddIns.xml themselves might do more harm than good in the general case. I suppose it doesn't hurt to mention it somewhere, but I don't think we should be pushing it over just disabling the mod in the DLC panel for now.

Good point... maybe we should promote disabling, but mention the xml edit option (since some players have been asking "how do I...?").

I understand that disabling an add-in switches off the resources in the add-in folder only. So, for example, [my docs dragon age folder]/packages/core is unaffected - all the more reason for cleaning it out.

[FollowTheGourd]

Proleric1 wrote...
I understand that disabling an add-in switches off the resources in the add-in folder only. So, for example, [my docs dragon age folder]/packages/core is unaffected - all the more reason for cleaning it out.

That's my understanding as well. I've been thinking it might be useful if we had some sort of "mod lint" checking tool that users or builders could run to look for common potential issues like that - and if it gets fancy, check for things like overridden core scripts, 2DAs that overwrite the base sheet instead of extending it as an M2DA (grey areas, but the more info the better).

Modifié par FollowTheGourd, 26 janvier 2010 - 06:45 .