Patches, mods, ect. What order do they go in? Which are needed?

Remove all ads!

I'm sorry for repeating this, but I did not want to open a separate thread for something related to this one anyway. Does anyone know of a program that safely uninstalls mod components and can repair damaged files? Also, is there a way to re-translate BG I Tutu (which is itself a BG II translation of BG I) back to "pure" BG II? I am afraid that one of the files that deals with spell lists/icons has become corrupted, as any time I click on a spell without an icon (and sometimes even on spells that do have an icon) in a character spellbook my game crashes.

To sum it up: help!

 

WeiDU mods can be uninstalled by double-clicking on the installer, called something like setup-modname.exe. You will be presented with choices to install/reinstall, remove or leave alone each component. If the mod in question is not WeiDU, however, you may be out of luck. This is one advantage of WeiDU mods.

As for Tutu, it depends on which version you are using. EasyTutu creates a new installation of the game, so your original BG2 is still there in the original directory. Normal Tutu v4 and v6 have a restoration program (called bgtutu_restore or something similar) which you double-click on to remove files and restore the game to BG2. That's somewhere in your Tutu directory. You should uninstall other mods before running the restoration program, though.

I am not sure what could cause the issues you are describing: icons are separate files, assigned individually in spell files. If they're missing or corrupt, perhaps one of the .BIFs is to blame, which might be the case if your CDs were scratched.

 

First of all, "much time" is relative, and while many people know how to make various smaller mods, they can't afford that their limited free time is filled with something they don't prefer, instead of the modding itself which they enjoy.
Second, WeiDU makes only certain mod developments faster. Mods with many CHAIN-type dialogues, and of course NPC and Kit mods which are strongly supported in TP2 language level. Also fixpacks, tweak and other such stuff, where weidu's file manipulation routines can be greatly used. (In the latter case, obviously because the mod development's main phase is basically the TP2's creation itself.)
So it's several mod types, but not all. TP2-based development of item, spell, store etc. packs, and big quest mods, is not a recommended method. For example, the typical recommended methodology for a big or medium quest mod is top-down, where you make your changes directly on the game and mod files (and meanwhile document them), which is faster and can be tested better as if you made the TP2 in the beginning, and then installed it as many times as you add some new mod elements. (This or something similar is what jcompton advised once, and I disagreed.) Why is this discouraged by me? Because the implementation is not separated from the specification, design and architectural work. In other words, the modder can't concentrate on the actual work (story, atmosphere, so the whole in-game stuff) if he has to deal with low-level technical realization such as WRITE_BYTE, COPY, offsets etc. meanwhile.
So the development of many types of complex mods can be supported by weidu (compiling and creating dialogues, for instance), but the development itself is not Weidu-driven. And since mod creation and packaging is separated, it's possible to make the mod without weidu, and the creation of the distribution package is only the last step. (Unlike in bottom-up methology.)

It's obvious that WeiDU, more or less, offers basically everything that modders normally need. (It's another question how; i.e. that certain parts could be differently solved, but I won't detail this here.) Some modders would prefer a GUI, but then it would be much more complicated to make it available for more platforms.
Some modders, primarily beginners, think of WeiDU as a god, which does something special, something different than other modding tools (such as DLTCEP). Actually, the creation of such a tool had to happen sooner or later. (It's logical that since we can alter determined parts of files, why to overwrite whole files when not needed?)
Weimer did it, and he did a really great job, offering much much more than just game and mod file manipulation. (To my knowledge, Weimer started the project because he was unsatisfied with the dialogue manipulation offered by the already existing tools; mod distribution support was added later.)
Limiting our discussion to its distribution support and related functions (file manipulation), a similar tool could be made at any time, even with a GUI, but the "problem" would be that WeiDU offers compatibility with... itself. Mods installed by weidu are stored in a stack-type structure, and thus if another distribution tool installs a mod, problems might appear if full compatibility with WeiDU's "mod stack" is not properly provided. The other option would be replace all weidu installers with the new one, but this is really a bad idea, considering how wide-spread WeiDU is, and its many additional services. (I.e. no need to invent the wheel again.)
I don't recommend making a new distribution tool at all. However, I've certain ideas how to increase the user-friendliness of Weidu package creation (I.e. the wheel can be improved.)

 

I'll go ahead and spare the separate thread.

The weapon animation tweaks does not account for one-handed staves, mainly because (until Underrep) I didn't realize the QS animation worked for one-handed items. It assigned them an animation sequence that exists for two-handed staves but was non-existent for one-handed ones, hence the crashes. I have this fixed in v3 of Tweaks, which should be released shortly. The rest of the problems are symptomatic of having an editor running while trying to un/re/install mods.

 

Having worked on content both with (UB, BG1UB, QP) and without (TDD, DLTC) WeiDU, this certainly isn't the recommendation I'd make. It's actually vastly easier in my experience to organize resources and concentrate on content if the changes you make are written down in your TP2 rather than scattered throughout the override. On top of that, converting to WeiDU as a final step greatly increases the amount of work you're doing, which more than negates any benefit gained from quicker testing.

(Anecdotally, while working on DLTC, I actually employed the opposite approach to the one you suggest: I developed using WeiDU because I found it more convenient, and then delivered the resources I'd modified in override form to Max.)

 

Not if you've correctly documented the changes. If it was just scattering them to the Override, you would be right. However, in my previous post, notice the comment in brackets: "and meanwhile document them". Based on what you say, you used the TP2 itself to follow the changes you've made, which is not a bad idea. This is why you felt that it was relatively fast, and that if you had created them at the end, it would have taken longer. (In the reality, if everything has been properly documented, the overall time isn't higher than in your methology.) The key part of my arguing was the following:

So while it's self-documenting (TP2), your method may also distract developing concentration, and requires unnecessary plus time because you have to open the TP2 each time you add something, then reinstall the whole mod with WeiDU and check the changes in the game. Instead, it's enough if you just take a note of the important additions/changes (such as a newly created CRE file), so the file won't be "lost" in the override. (Assuming a progressive development here so you add new stuff dynamically instead of fixing most elements in the planning phase). I've a tool for this (i.e. making certain block types of the TP2 in the last step), which makes many things even faster. (It will be released in the near future.) On the other hand, my recommendation certainly doesn't exclude the use of WeiDU for partial tasks, such as compiling .d and .baf files. (And as I've said, kit and npc mods are another category, because these are supported in language level by WeiDU.)
Finally, my recommendation completes the generally true paradigm of creating large systems: separating implementation from other phases (such as specification and architectural work) results in less errors and better development efficiency. (If properly organized and coordinated!)

 

I'm not sure I can add anything to my last post. "You'll have to take my word for it"?

 

Baronius mentioned a very good point in one of his posts. I can restate it in this form:

SP is a different and unique forum. It is primarily a gaming forum rather than a modding one. The majority of people who post here are players (rather than mod-makers) and this is perhaps why I like this forum very much and can explain why SP is the only forum I browse in addition to BWL (which is my most favorite modding site and forum).

In SP, a modder such as me can receive direct feedbacks from players about the 'content' of his/her/my mod (rather than comments from other modders who have never tried his/her/my mod in practice and are only worried about compatibility issues with their own mods, or are sometimes just envious).

Therefore, I heartily second Baronius's comment about keeping this great forum clean of senseless modding wars.