Ovewrite/patching Options

[aigleborgne]

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.

This post has been edited by aigleborgne: Dec 22 2005, 02:09 PM

[The Bigg]

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.)

[cujo]

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.

[Baronius]

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.

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:

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

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.

Are you suggesting there are things you can do with overwriting which you can't with patching?

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.

[NiGHTMARE]

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:

CODE

COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~
READ_BYTE  0x1f "useoneb"
READ_BYTE  0x20 "useonec"
PATCH_IF ("%useonec%" BAND 0b01000000) = 0x01000000) BEGIN // if usable by thieves
  WRITE_BYTE 0x1f ("%useoneb%" BAND 0b11111101) // make usable by cleric/thieves
END
BUT_ONLY_IF_IT_CHANGES

This post has been edited by NiGHTMARE: Dec 22 2005, 11:49 PM

[Baronius]

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.

[CamDawg]

It seems that you didn't understand my point.

I understood. I disagreed.

[Baronius]

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?

[Ascension64]

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.

[CamDawg]

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?

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.

Advice (to all modders): compatibility is important (only) as long as your mod's real purpose stays completed. 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.

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.

If your mod is a good mod, players will prefer it to certain other mods if it collides with some other mods.

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.

To sum up, don't let your main concept modified just for compatibility reasons.

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.

This post has been edited by CamDawg: Dec 23 2005, 11:43 AM