Are the changes made in this mod file direct copy overwrites, or are they done by patching?

Changes are made by overwritting.

I have difficulties to program my changes with weidu code.

Spells : my spells come from different sources:
- BG2 (because tutu use BG1 spells, and it's not corrected by anything)
- BG2 Fixpack
- BG2 mod : Atraits and Detactable spells
- My own mod, including some fixing in previous spells

So it's easier to overwrite them instead of patching.

NPC & monsters : there are so many changes it would be a nightmare to make a patch!

Stores : patching is possible and will be done later when I have time

Items : only minor changes in some items. patching is possible

IDS : patching

So, to resume:
it's possible to patch stores, items, and ids.
But for creatures and spells, it would be a tedious work.

I have already a lot of work involved into the modding part. I won't make all these patching stuff (only for stores, items, and ids), but if someone is insteresting in doing it, contact me

You should probably include a warning about the .cre overwriting in the readme, since it'll mean Enhanced Creatures will need to be installed before other WeiDU mods (otherwise there's a good chance EC will cause them to not work properly).

BTW once you get the knack of it, patching .cre's is pretty easy, plus you can write the code in almost the same time it would take to alter the .cre in a utility .

NiGHTMARE,

thanks for the tip!
We won't miss adding this in the readme file once we make a Beta launch...

Patching cre is not easy.

You probably think this mod only make things a little better by correcting "easy" things like Thac0, AC (set to 10), saving throw (according to level & class)...
But in fact, most of the .Cre have been reviewed with lots of attention. Same thing for monsters.

The changes are quite unique and depends on many factors. Of course, it should be possible to write a patch for each cre. But I would take a long time to do so.

The best thing is to install this mod just after tutufix or tututweak. Then, install other mods.

aigleborgne,

there won't be any problem because this Mod will be installed if this Mod will be installed just after TuTufix...

In the future, if everything goes like it should we should have something like this:

Installation Order:

Tales of the Sword Coast
Official patch
BG1 Fixpack (from Idobek/G3)

Throne of Bhaal
Official patch
BG2 Fixpack (G3)
TuTu 6 (Final)
(TuTu Fixpack)
Enchanced Creatures
ALL OTHER WeiDU Mods (appending)

What I think though is that TuTu Tweaks should be installed by the end of the list so Enhanced Creatures and TuTu Tweaks will sit distant from each other...

It's easy once you've left the learning stage, and have figured out what can and can't be done, how to do everything you want to do, etc .

I personally have already revamped several BG2 creatures and am working on more (these include all the dragons, the various types of kuo-toa (including a couple of new ones), and Drizzt & co.), and my changes are pretty extensive too: altering, replacing, adding and removing spells, innate abilities and items; altered weapon damage; and even complete script rewrites.

Assuming I would do this with a script and because changes would require a different script for each cre (adaptation of a modele), this would require about 700 scripts.

It's doable, but requires a lot of work.
Just to be comfortable with weidu programming, it would require some days.

The most important thing is the mod by itself.
It's already in WEIDU package, with patching for the most important thing.

Few mods actually modify creatures (except specifically mods like mine, but those shouldn't be installed together anyway). So it's not a real problem.

It's more something better to have (patching), and I fully agree. But i'm not ready to redo all thing I have already done in patching scripts.

Later... one day... maybe

True, but then again at the moment it requires about 700 .cre files .


Don't forget that a change made to an existing creature by another mod could be something as simple as giving them a new item. If this item is a key, obviously overwriting the creature would mean it no longer has said key, which would in turn mean the door or container it unlocks could no longer be opened.

Alternatively, the new item could be part of a dialogue condition, meaning f.ex you could never retrieve the item a quest giver asks you to bring him.

Or it could just be some cool new armor or weapon someone made .

But yeah, as long as other mods are installed after Enchanced Creatures, there shouldn't be a problem . Off the top of my head, the BG1NPC Project probably makes at least a few creature changes, and I suspect the forthcoming BG1 Quest Pack probably will too.

Advice (to all modders): compatibility is important (only) as long as your mod's real purpose remains intact. If the price of compatibility (patching) is the risk that the mod's main point might be harmed in certain cases, stay with traditional overwriting. If your mod is a good mod, players will prefer it to certain other mods if it collides with some other mods. To sum up, don't let your main concept modified just for compatibility reasons.

I'm speaking generally, and not about Enhanced Creatures. I'm sure aigleborne pays enough attention to the importance of what I've written above.

I couldn't disagree more. Start learning new and better ways to do things, and don't stop. Especially when those skills lead directly to better mods--from a maintainability standpoint, from a seamlessness standpoint, and (most importantly) from a player's convenience and experience standpoint.

Especially given that thousands of lines of well-commented code for patching are available in the G3 Dev Wiki. There are over 4000 lines of creature patching code in just the Fixpack that cover every way you could possibly want to modify a creature.

Overwrites will save you time for the first release, but you'll waste so much more in updates.

Are you suggesting there are things you can do with overwriting which you can't with patching? I'm certainly not aware of any . In fact, if you have enough patience, you can even use WeiDU to create new items, creatures, spells, etc from scratch .

If your modification does something bad like crash the game, then byte-patching has another advantage: your tp2 tells you exactly what you changed, so you know where to begin looking.

I have found the potential for error creeps in quite often if I try file overwrites-perhaps I changed some value and forgot about it, or accidentally edited something I didn't mean to, and either didn't spot my error or forgot what the original was. Byte patching avoids these issues.

Ok, I will try to make to mod a cre with patching tomorrow.
I will then see if it worths it or not.

I'm pretty sure it would be quicker by patching but I think I will take time to learn how to handle this.
It isn't the language by itself (I'm a programmer), it's more the format of cre, understand the offset of each value, and many little things.


About spells, patching would be more difficult since BG1 and BG2 spells are very different. Any ideas here?

The number one resource for such things is IESDP, particularly the Infinity Engine File Formats section. Near Infinity is a great tool for checking offsets.

BG1 and BG2 both use the same .spl file format (in fact, I believe IWD2 is the only IE game which uses a different .spl format), it's only some of the effects and properties which have been changed; the order and number of fields remain unchanged. BG2 does introduce many new effects, but since Enhanced Creatures is for Tutu, that means you have full access to BG2's additions .

PM'ed aigleborgne. Since everyone else seems to be too busy with their mods, real life, and whatever to help out, I am putting up my hand to assist in the task, despite all my mods, real life, and whatever.

Near Infinity is really good for offsets. And remember WeiDU has constants for some of them so you don't have to remember the offsets: check http://www.weidu.org/WeiDU/README-WeiDU.html#htoc38 for the list. Useful if you want to change scripts, or whatnot.

I thank you all guys for your help (especially Ascension64 for offering direct help in the matter) and I am sure that aigleborgne will work to make his Mod append and no longer overwrite if possible, as we would not want any compatibility issues.

I have a question though...I know nothing about modding so perhaps it sounds stupid. If I understood well, appending makes so that the new modifications brought will coexist with the older ones to preserve former changes done to a specific file.

But what happens if both mods change the same parameter ? Thanks!

If both mod change the same parameter, the last installed mod will overwrite the parameter. pretty obvious no?

Well, hopefully the 'source parameter' and the 'overwriting parameter', isn't, say, adding a spell, and changing an item name, respectively. If the 'overwriting parameter' does not read offsets and byte-patches the item, then it will clearly miss (due to changed offsets by adding a spell) and corrupt the item file.

For example, if I decide to add the spell 'Globe of Invulnerability' to a creature, than another mod decides to change that creature's 'Staffspear+3' to a normal 'Staff', then the second mod must ensure that they don't just WRITE_ASCII 0x3f0 ~STAF01~ #8. Not that that will ever happen, I hope.

I didn't understand your example.

I know it would overwrite the staff+3 by a normal staff. But I don't see the point with the globe.

Why would the item be corrupted? (and I think you meant the cre)

Currently, in my tp2, I have line like:
// Sorcerous sundries store
COPY_EXISTING ~_sto0703.sto~ ~override/_sto0703.sto~
ADD_STORE_ITEM + ~_wand10~ #5 #0 #0 ~IDENTIFIED~ #1 // wand of summoning
ADD_STORE_ITEM ~scrlar~ #1 #0 #0 ~IDENTIFIED~ #3 // new scroll : sunfire


// items
COPY_EXISTING ~_RAMAZI.cre~ ~override~
PATCH_IF (SOURCE_SIZE > 0x2d3) THEN BEGIN // protects against invalid files
ADD_CRE_ITEM ~rin95~ #0 #0 #0 ~undroppable~ ~LRING~
ADD_CRE_ITEM ~BOOT_09~ #0 #0 #0 ~undroppable~ ~BOOTS~
ADD_CRE_ITEM ~ap#ele~ #0 #0 #0 ~undroppable~ ~RRING~
END
BUT_ONLY_IF_IT_CHANGES

Is that not correct?
I know they will overwrite old ring or boot, but it is intended.

Meta-code like ADD_CRE_ITEM makes sure to do all necessary steps for you, so you needen't care much about offset or anything; Ascension's worry was about when you get down to direct hex-editing (WRITE/READ_BYTE/whatever, INSERT/DELETE, etc.)

Maybe this is easier to understand:

Two people want to make changes to an existing essay. Nobody remembers who wrote the existing essay. The essay is already 10 pages long. The first person inserts 3 pages between 4 and 5, and page 5 of the old essay becomes page 8. The second person comes along and rips out page 9 and puts a new page 9 in the essay. Because the second person didn't consider the changes the first person made he would replace the wrong page in the essay making it unreadable.

This is what would happen with Ascension64's example. Someone gives a creature a new spell. This means that the items are now stored further back in the file. If a second modder changes an item without checking first where in the file the items start the second change would overwrite something completely different making the cre file unreadable.

As The Bigg pointed out WeiDU already has built-in functionality to make sure these things won't happen. Unless you rather do all the work yourself.

It seems that you didn't understand my point.
If it is possible to provide compatiblity and to ensure that the mod will always work in the way you intend in any circumstances, then I do support patching.
For example if I make a mod which changes certain scripts of creatures and I don't want other mods to interfere, I will include a warning to the installation notes that the mod might not work properly if other mods are installed which modify the same attributes. And thus, it is not compatible with certain other mods. It will work with other mods, but it will not provide what it promises.
Aigleborgne mentions a very important danger:


To sum up my opinion: ensure compatibility if possible. If it required you to change on your mod, always consider if you want the sacrifice in exchange for the compatibility.


As I've written, I was speaking generally. I suppose there are, perhaps not in the case of this mod.

By the way, I'm more than happy to see that aigleborgne was offered help. Compatibility and patching is nice, but it requires much time to make the necessary code.

In certain circumstances, coding is a heck of a lot faster than using an editor; the most obvious time this applies is if you want to make the same change to a large number of files. For example, if you wanted to let cleric/thieves use any item a single class thief can use, you would have to either manually edit >90% of the .itm files, or simply use this code:

These are not the only two possibilities obviously. As far as I'm concerned, I certainly wouldn't edit hundreds of files, I would either use a WeiDU code (i.e. I would ask someone to give me one, as I don't have time to learn advanced WeiDU) or I would write an own program to process those ITM files.
WeiDU code is useful because it can be uninstalled, while own code is not so flexible even if I make an uninstaller for it.

I understood. I disagreed.

In that case, you say that even an important part of a mod's main concept should be sacrificed just to make it compatible with other mods?

I just hope that, speaking generally and slightly aside, the plot of the mod is not sacrificed for such an ideal.

That's not what I'm saying at all. Overwriting and patching are different methodologies--modifying files for your mod--that are applied to accomplish the concept of your mod. The end result is the same.



This is never true. If two mods wish to alter, say, Haer'Dalis' fire resistance they'll never be compatible. That's a trivial and obvious argument. However, if they change other aspects of Haer'Dalis (one changes his fire resistance, another his spells) they'll be compatible if they patch rather than overwrite. Overwriting introduces incompatbilities where none need exist.



Absolutely true. However, given the ease and benefits of patching there's really no reason to overwrite files any more. This reduces incompatibilities to real ones instead of incompatbilities due to modder laziness. We have modern tools and no longer need to distribute dialog.tlk with mods nowadays.



Again, the methodology of whether you patch or overwrite has no bearing on this. There are no modifications made by overwriting that can not be made on the fly with patching.