33 replies to this topic

[Miloch]

Well, this is you: "Sigh. Won't be the first time I've had to revise a mod due to some sort of *Revisions muckery. What did they mess up this time?" ...before discovering it's you own fault.

Eh... how is that a "campaign"? I didn't investigate the posting at the time, which is why I asked for more information on why SR would cause an incompatibility. Part of that statement's true anyway... the last time was when I had to revise PnP Free Action due to a glitch in the Remove Paralysis spell SR was overwriting (which you later fixed). Obviously I wouldn't bother with that if I wasn't concerned with compatibility - I'd just overwrite "my version" of things and have done with it. But I'm willing to make my mods as compatible with yours as can be, under the circumstances.

Also, I'm not the one who reported this was an "incompability between SR and Thrown Hammers." Though technically I suppose by definition, any mod that wants to tweak spells is incompatible with Spell Revisions and any mod that wants to tweak items is incompatible with Item Revisions. Because they're both monolithic mods that say "This Is How Things Must Be" and "Thou Shalt Not Install Other Item Or Spell Mods" (and if you do and find a bug, obviously it's the other mod's fault).

And if you think that's the start of a "campaign," heh... you asked for it . But enough of this idle chitchat - I've got a mod or two to revise so they patch more optimally. Hmm, don't you have a mod or two to revise so they patch... er, so they patch at all? Indeed, didn't you say that was one of your goals some time ago, or did you give up on that?

[Mike1072]

Did you see this? (And maybe it's relevant.)

Thrown Hammers is moved before Item Revisions again where it had been with BWP v9.2.

Link.

Though it does bug me that a patching mod gets installed before an overwriting one, Item Revisions doesn't appear to modify the spiritual hammers, but Spell Revisions does.

Item Revisions has 1 main component that overwrites items (on purpose) and more than 10 components that patch items. These global components need to be installed after mods like Thrown Hammers that add new items. The main component is installed separately much earlier on.

[GeN1e]

Hopefully, people are installing Spell Revisions before patching mods like Thrown Hammers at least. Otherwise, it's rather pointless to install other mods before it. A bit like Improved Anvil .

Hmm, don't you have a mod or two to revise so they patch... er, so they patch at all? Indeed, didn't you say that was one of your goals some time ago, or did you give up on that?

The Revisions family tries to enhance globally one or another aspect of the game, so it is logical to overwrite prior things and manually check for specific compatibility issues, rather then do a half-crazy patchnig that will probably fail even more often.

Edited by GeN1e, 19 October 2010 - 01:41 PM.

[Dakk]

I was just reporting, second hand, on incompability. Surely didn't mean to unleash all this hostility...

For the benefit of my limited understanding though, wouldn't *R be conceptually impossible if they DIDN'T overwrite?

[Miloch]

I was just reporting, second hand, on incompability. Surely didn't mean to unleash all this hostility...

What hostility? Just some good-natured ribbing here . I wasn't blaming you either, or even the original poster (at least you reported it in the right thread).

For the benefit of my limited understanding though, wouldn't *R be conceptually impossible if they DIDN'T overwrite?

Why? You mean wouldn't it be a lot of work? Perhaps so, but I'm not sure it'd be much more than modding every spell and item manually then overwriting them, except that's what's already been done.

As for compatibility, there's no reason a patch couldn't account for prior mod compatibility. The only thing it can't do is account for subsequent mod compatibility, but neither can overwriting. There's no reason for patching to fail either, unless it's poorly-written (it's cases like this where there isn't an install failure that are trickier).

I suppose if the idea is to remake every spell/item/whatever in the game, then the notion of "why not overwrite everything?" might seem valid. But let's take a scenario where an earlier, legacy mod (one like Tactics or whatever that was invented before practical patching was possible) doesn't necessarily change the way a spell *works*, but just adds an effect or something to a spell to enable some extra quest content or something. Now another overwriting mod like SR comes along and wipes that out because it's not aware of it, and in any case, it doesn't appear to be a crucial feature to the consideration of functionality. This isn't going to make either mod fail - it will just effectively hide the quest content from Mod A. In fact, no one may ever know the content's even being blocked necessarily. Not saying this is happening necessarily, but it's possible, and I do know there are spells or items of this nature in older "legacy" mods (ones that are only slightly different without certainty as to the purpose of the difference). But I guess all that is a bit off topic .

[Wisp]

For the benefit of my limited understanding though, wouldn't *R be conceptually impossible if they DIDN'T overwrite?

No. You can manipulate files however you wish with patching and you could certainly write a mod that affected every item or spell in the game without overwriting files. The "install before other mods" versus "install after other mods" thing is much more of an issue than overwrite versus patch. And if you require that your mod be installed before other mods it's fairly academic whether it patches or overwrites.
Edit: But at Miloch gets at, overwrite versus patch matters a lot in compatibility. E.g. what if you want to install two overwriting mods? Uh-oh.

But it is also a matter of how you prefer to work. E.g. I find working with GUI-driven systems (e.g. DLTCEP or MS Office) to be tedious and requiring too much upkeep and prefer working with instructions-driven systems (e.g. patchy TP2 or LaTeX). But I imagine it is possible to have a analogous preference for GUI-driven systems.

Edited by Wisp, 19 October 2010 - 04:21 PM.

[Demivrgvs]

For the benefit of my limited understanding though, wouldn't *R be conceptually impossible if they DIDN'T overwrite?

Why? You mean wouldn't it be a lot of work? Perhaps so, but I'm not sure it'd be much more than modding every spell and item manually then overwriting them, except that's what's already been done.

As for compatibility, there's no reason a patch couldn't account for prior mod compatibility.

Is it conceptually possible? Probably yes. Would the end result be better? Probably not. Is it worth the efforts? Certainly not.

To patch an item or spell I'd need to exactly know what I'm patching, and adjust the patching code consequentely. Let's say we have two mods (A and B) which alter the same file IR or SR want to revise:
- if mod A is installed IR/SR code needs to do X
- if mod B is installed IR/SR code needs to do Y
- if mod A and B are installed IR/SR code needs to do Z
- the end result of X, Y and Z should be more or less the same, because more often than not we don't want to keep features of A and B, or we simply can't keep them for technical/compatibility reasons; but we'd have to add manual checks for each instance because there may be times where we want to keep A, or B, or both of them, or part of them
- do this for each and every item/spell in the game (500+ files), with more than a couple of mods installed before IR/SR
- then add to all this the worst thing, PATCHING DESCRIPTIONS...good luck with that, especially when we're not talking about small changes to standard lines (like "Damage: 1D6")


A patching code is great when it can do the same thing over tons of files (and like Mike says this is done for most of IR/SR's components, like Weapons Global Changes, Revised Shields, all the various global tweaks on armors, etc.), but for the main component we would have hundreds of different files that need very different codes, with tons of manual checks. IR's main component doesn't add small and standard changes here and there, we re-make almost everything, adding hundreds of different custom .spl files, EFF files, etc., what's the point of patching in an entirely new concept?!

Tweaks are better handled via patching codes, but "complete revisions" are not.

Edited by Demivrgvs, 19 October 2010 - 05:15 PM.

[Miloch]

To patch an item or spell I'd need to exactly know what I'm patching, and adjust the patching code consequentely.

Not necessarily, and that's the great advantage about patching: you needn't concern yourself with existing attributes that aren't consequential to your mod, though they may be to another mod. And if you do, you can mass-delete, add or change effects with one fell function.

Let's say we have two mods (A and B) which alter the same file IR or SR want to revise:
- if mod A is installed IR/SR code needs to do X
- if mod B is installed IR/SR code needs to do Y
- if mod A and B are installed IR/SR code needs to do Z
- the end result of X, Y and Z should be more or less the same, because more often than not we don't want to keep features of A and B, or we simply can't keep them for technical/compatibility reasons; but we'd have to add manual checks for each instance because there may be times where we want to keep A, or B, or both of them, or part of them

So the solution is to wipe out any prior modded features via mass overwrite? Not only is that ill-considered, but you seem to be missing the larger point which Wisp reiterated. What happens with two overwriting mods that mod the same resources? One inevitably wipes out the other, and players and modders alike probably don't even know about it. Because that is exactly what happens on the BWP "expert" install, where the default (and recent) install order has SpellPackB5's Spiritual Hammer, and no doubt quite a few other spells have overwritten yours. Apparently, Galactygon has revised his mod (which, unpacked, is roughly twice as large as yours) to be completely patching, so there's no real reason you couldn't. Because if Galactygon *wasn't* doing that, either most BWP players (which seems to be most players nowadays) would be missing your content, *or* you'd end up in a futile install-order struggle.

IR's main component doesn't add small and standard changes here and there, we re-make almost everything, adding hundreds of different custom .spl files, EFF files, etc., what's the point of patching in an entirely new concept?!

See above, but what's with *hundreds* of new spells when I thought your purpose was just to tweak existing vanilla spells and items?

Tweaks are better handled via patching codes, but "complete revisions" are not.

What some might call a distinction without a difference, but I don't even think there's a distinction. Your "revision" is not much more expansive than other tweaks (such as BG2 Tweaks) and indeed, the subcomponents you mention address more files (namely mod-added as well as vanilla ones) - they just do it by patching instead of overwriting.

But anyway, this should really be in the Modding Discussion forum or perhaps the SR/IR forums. Whatever you do, don't let people translate your mod into 6 different languages because updating your mod will make individually patching 500+ files look like child's play .

Edit: translation info split to original topic

Edited by Miloch, 20 October 2010 - 10:54 AM.

[Mike1072]

To patch an item or spell I'd need to exactly know what I'm patching, and adjust the patching code consequentely.

Not necessarily, and that's the great advantage about patching: you needn't concern yourself with existing attributes that aren't consequential to your mod, though they may be to another mod. And if you do, you can mass-delete, add or change effects with one fell function.

Let's say we have two mods (A and B) which alter the same file IR or SR want to revise:
- if mod A is installed IR/SR code needs to do X
- if mod B is installed IR/SR code needs to do Y
- if mod A and B are installed IR/SR code needs to do Z
- the end result of X, Y and Z should be more or less the same, because more often than not we don't want to keep features of A and B, or we simply can't keep them for technical/compatibility reasons; but we'd have to add manual checks for each instance because there may be times where we want to keep A, or B, or both of them, or part of them

So the solution is to wipe out any prior modded features via mass overwrite?

No, the solution is to replace vanilla files with our versions, and leave tweaks to be installed later. We are trying to change the concepts of items and spells from their vanilla incarnations (to differing degrees), so we overwrite the files early in the install, before other mods add any features. The only benefit to patching the changes with this install order would be to preserve new Fixpack additions, but we take responsibility for fixing bugs in our items and spells.

Not only is that ill-considered, but you seem to be missing the larger point which Wisp reiterated. What happens with two overwriting mods that mod the same resources? One inevitably wipes out the other, and players and modders alike probably don't even know about it.

There's no problem with mods that are conceptually incompatible remaining technically incompatible - they shouldn't be installed together anyway.

Most changes that are conceptually compatible with SR/IR are relatively straightforward to write as patches, so it's easier to alter the overwriting sections in other mods than alter the ones in SR or IR. You may have noticed that the description-overwriting components of the BG2 Tweak Pack have disappeared in recent versions, or that Divine Remix is getting an overhaul.

If we wanted to rewrite the changes made by SR/IR as patches so they could be installed after overwriting mods, we'd be forced to account for all current changes made by other mods as Demi mentioned and continually update to account for future changes. This is an enormous amount of work. Unless you volunteer for the job, SR and IR won't ever stop overwriting, since the same benefits can be achieved more easily by updating the other overwriting mods. Since the practice of incorporating tweaks by overwriting has largely stopped, there's only a finite amount of code that needs to be updated.

But anyway, this should really be in the Modding Discussion forum or perhaps the SR/IR forums.

Feel free to start a thread over at G3 if you'd rather talk about the matter there.

[Demivrgvs]

IR's main component doesn't add small and standard changes here and there, we re-make almost everything, adding hundreds of different custom .spl files, EFF files, etc., what's the point of patching in an entirely new concept?!

See above, but what's with *hundreds* of new spells when I thought your purpose was just to tweak existing vanilla spells and items?

I get you don't even know what you're talking about then. Just to give a simple example take the first magical weapon you find in BG2, the Sword of Chaos. In V3 it's apparently going to have the very same simple Vampiric effect it had in vanilla, but:
a) the whole drain on hit effect is done via custom .spl file (this allows to do a lot of things that would take too much time to discuss)
b) custom EFF files are used to make sure you can't drain life from non-living targets like golems, undead or illusionary creatures
c) drain effect doesn't cause 'magic damage' anymore, it more appropriately lowers target's hp

You see, the item seems almost unchanged at first sight, but it really isn't. You want to do that via patching code? Sure, it can be done, but such code would have been forced to cancel almost everything done to the item before anyway, because the item now works in a completely different way (e.g. there are no effects in the melee header other than a single "cast spell on hit"). So, you could do that via patch but you'd have zero benefits from it, instead you'd have much more problems and compatibility issues to account for.

Tweaks are better handled via patching codes, but "complete revisions" are not.

What some might call a distinction without a difference, but I don't even think there's a distinction. Your "revision" is not much more expansive than other tweaks...

Feel free to think so, but the example above is only the tip of the iceberg, because then there are tons of items with completely overhauled backgrounds/concepts and new effects/animations, which really cannot be defined as "tweaked".

But anyway, this should really be in the Modding Discussion forum or perhaps the SR/IR forums.

You're right, feel free to move it.

Whatever you do, don't let people translate your mod into 6 different languages because updating your mod will make individually patching 500+ files look like child's play .

Believe it or not there are translations worked on despite the absurd amount of work they require, for example we have a ready to go German translation for SR.

Edited by Demivrgvs, 20 October 2010 - 02:30 AM.

[Wisp]

Let's say we have two mods (A and B) which alter the same file IR or SR want to revise:
- if mod A is installed IR/SR code needs to do X
- if mod B is installed IR/SR code needs to do Y
- if mod A and B are installed IR/SR code needs to do Z
- the end result of X, Y and Z should be more or less the same, because more often than not we don't want to keep features of A and B, or we simply can't keep them for technical/compatibility reasons; but we'd have to add manual checks for each instance because there may be times where we want to keep A, or B, or both of them, or part of them

So the solution is to wipe out any prior modded features via mass overwrite?

No, the solution is to replace vanilla files with our versions, and leave tweaks to be installed later.

But that's not what Demivrgvs' example is about. If your mod is installed on a vanilla or near-vanilla installation there are no mods A and B to throw wrenches into your machinery. Consequently the astronomical workload outlined by the example is reduced to something manageable, or disappears entirely.
But we can infer from the example that if mod A and B are installed before your mod you achieve a "solution" to the ensuing compatibility woes by overwriting mod A and B. Or have I misunderstood?

[GeN1e]

Not necessarily, and that's the great advantage about patching: you needn't concern yourself with existing attributes that aren't consequential to your mod, though they may be to another mod. And if you do, you can mass-delete, add or change effects with one fell function.

The point of doing so? Mind you, that's exactly how stores are proceeded in IR v3 - all vanilla content is deleted, then new selection is built. Mod-added items are left untouched. You know what that means? You end up with megamods' +12 Hackmasters in spellstores. Compatible - yes, immersion-breaking - yes. This is roughly equivalent to deleting items' vanilla equipped effects and patching in new ones, but things only get worse when you work on ability headers.

And is it just me or you've conveniently missed this statement because you have no argument to counter with?

- then add to all this the worst thing, PATCHING DESCRIPTIONS...good luck with that, especially when we're not talking about small changes to standard lines (like "Damage: 1D6")

[Miloch]

Not necessarily, and that's the great advantage about patching: you needn't concern yourself with existing attributes that aren't consequential to your mod, though they may be to another mod. And if you do, you can mass-delete, add or change effects with one fell function.

The point of doing so?

I thought I answered that already above, but I guess I have to repeat it:

But let's take a scenario where an earlier, legacy mod (one like Tactics or whatever that was invented before practical patching was possible) doesn't necessarily change the way a spell *works*, but just adds an effect or something to a spell to enable some extra quest content or something. Now another overwriting mod like SR comes along and wipes that out because it's not aware of it, and in any case, it doesn't appear to be a crucial feature to the consideration of functionality. This isn't going to make either mod fail - it will just effectively hide the quest content from Mod A. In fact, no one may ever know the content's even being blocked necessarily. Not saying this is happening necessarily, but it's possible, and I do know there are spells or items of this nature in older "legacy" mods (ones that are only slightly different without certainty as to the purpose of the difference).

...

Mind you, that's exactly how stores are proceeded in IR v3 - all vanilla content is deleted, then new selection is built. Mod-added items are left untouched. You know what that means? You end up with megamods' +12 Hackmasters in spellstores. Compatible - yes, immersion-breaking - yes.

So what's *your* point? And what's wrong with that approach? Surely, you're not talking about *overwriting* stores, because that would be the height of folly. And if you wanted to patch out Hackmasters +12 as long as you're patching other things, go ahead, I'm sure some players would welcome that (as an optional component no doubt).

And is it just me or you've conveniently missed this statement because you have no argument to counter with?

- then add to all this the worst thing, PATCHING DESCRIPTIONS...good luck with that, especially when we're not talking about small changes to standard lines (like "Damage: 1D6")

I don't care to counter it, because I'm not talking about changing descriptions. You can patch or not patch descriptions - there are advantages and disadvantages to either approach, just as there are to patching vs. overwriting .itm and .spl files. *However*, one is very unlikely to break a mod or even limit its content by overwriting a description, unlike overwriting a .spl or .itm (unless it's something like a description that concerns a crucial piece of quest information but I doubt we're talking about that here). It can still lead to conflict though, as when two mods try to patch in different versions of "their" descriptions (we've seen this with SR and PnP Free Action).

Feel free to think so, but the example above is only the tip of the iceberg, because then there are tons of items with completely overhauled backgrounds/concepts and new effects/animations, which really cannot be defined as "tweaked".

I define a tweak as anything that changes vanilla content, unless it's clearly a fix. Indeed, "revision" and "tweak" are fairly synonymous. Putting in completely new content would not be a tweak. Speaking of which, if you're *completely* overhauling spells and items, so that in some cases they may even lack resemblance to the originals, then why not just put in *new* spells and items?

[GeN1e]

But let's take a scenario where an earlier, legacy mod (one like Tactics or whatever that was invented before practical patching was possible) doesn't necessarily change the way a spell *works*, but just adds an effect or something to a spell to enable some extra quest content or something. Now another overwriting mod like SR comes along and wipes that out because it's not aware of it, and in any case, it doesn't appear to be a crucial feature to the consideration of functionality. This isn't going to make either mod fail - it will just effectively hide the quest content from Mod A. In fact, no one may ever know the content's even being blocked necessarily. Not saying this is happening necessarily, but it's possible, and I do know there are spells or items of this nature in older "legacy" mods (ones that are only slightly different without certainty as to the purpose of the difference).

Truthfully, I've never heard of a mod adding an extra effect to and itm/spl with otherwise a rather straightforward purpose. There's Ascension and it's very outdated DS, but people are encouraged to use BP's version anyway. What else could be out there?
Some mods like to introduce their own tweaks to existing things as well, that's true. But between a small change of one item and global overhaul of them all, I think it's quite clear whom priority should belong to. Ensuring technical compatibility in the wild while neglecting conceptual one is hardly an improvement here. And if players/mod authors are interested in mutual compatibility then once again it requires manual work that you can't trust to non-sentient patching code.

So what's *your* point? And what's wrong with that approach? Surely, you're not talking about *overwriting* stores, because that would be the height of folly. And if you wanted to patch out Hackmasters +12 as long as you're patching other things, go ahead, I'm sure some players would welcome that (as an optional component no doubt).

Nothing wrong... from the technical POV. And as I've said, it's merely an idle store - extended headers can be much more complicated to afford this kind of approach. Like external SPL/EFF shells, some of them with rather arcane targeting.

I don't care to counter it, because I'm not talking about changing descriptions. You can patch or not patch descriptions - there are advantages and disadvantages to either approach, just as there are to patching vs. overwriting .itm and .spl files. *However*, one is very unlikely to break a mod or even limit its content by overwriting a description, unlike overwriting a .spl or .itm (unless it's something like a description that concerns a crucial piece of quest information but I doubt we're talking about that here). It can still lead to conflict though, as when two mods try to patch in different versions of "their" descriptions (we've seen this with SR and PnP Free Action).

The chance is at least equal, because even if you only adjust some radical effect like instakilling, it already may pose a serious problem. And chance of a mod making an arcane use of exsiting item for their quest imo is far lower (do you actually know of one?).

Speaking of which, if you're *completely* overhauling spells and items, so that in some cases they may even lack resemblance to the originals, then why not just put in *new* spells and items?

Because it wouldn't get us rid of vanilla 'garbage'. The point is to remove the garbage cathegory, not to keep suffering it. A solution could be to replace old item resource with new one, but how is it different from overwriting?

Edited by GeN1e, 20 October 2010 - 12:16 PM.

[Mike1072]

Let's say we have two mods (A and B) which alter the same file IR or SR want to revise:
- if mod A is installed IR/SR code needs to do X
- if mod B is installed IR/SR code needs to do Y
- if mod A and B are installed IR/SR code needs to do Z
- the end result of X, Y and Z should be more or less the same, because more often than not we don't want to keep features of A and B, or we simply can't keep them for technical/compatibility reasons; but we'd have to add manual checks for each instance because there may be times where we want to keep A, or B, or both of them, or part of them

So the solution is to wipe out any prior modded features via mass overwrite?

No, the solution is to replace vanilla files with our versions, and leave tweaks to be installed later.

But that's not what Demivrgvs' example is about. If your mod is installed on a vanilla or near-vanilla installation there are no mods A and B to throw wrenches into your machinery. Consequently the astronomical workload outlined by the example is reduced to something manageable, or disappears entirely.
But we can infer from the example that if mod A and B are installed before your mod you achieve a "solution" to the ensuing compatibility woes by overwriting mod A and B. Or have I misunderstood?

When installed on a near-vanilla installation with no mods making prior changes to the files, there's no need to patch - it doesn't offer any benefits.

The only reason we'd have to make it patch is if we wanted to install it after mods A and B, in which case we'd be forced to deal with those hassles.

And is it just me or you've conveniently missed this statement because you have no argument to counter with?

- then add to all this the worst thing, PATCHING DESCRIPTIONS...good luck with that, especially when we're not talking about small changes to standard lines (like "Damage: 1D6")

I don't care to counter it, because I'm not talking about changing descriptions. You can patch or not patch descriptions - there are advantages and disadvantages to either approach, just as there are to patching vs. overwriting .itm and .spl files. *However*, one is very unlikely to break a mod or even limit its content by overwriting a description, unlike overwriting a .spl or .itm (unless it's something like a description that concerns a crucial piece of quest information but I doubt we're talking about that here).

An item or spell not behaving the way it says it does is a bug by anyone's definition and the work required to fix that bug should not be overlooked. The description changes made by SR and IR's main components could not be automated - they'd have to individually account for alterations made by previous mods, the same way the .itm and .spl patches would.

Miloch, would you care to respond to my post? I can't see any compelling reason to update IR/SR to patch resources given the amount of work it would require. Conflicts with other overwriting mods are more easily handled in the other mods. Is there some significant benefit I've overlooked?

[Wisp]

When installed on a near-vanilla installation with no mods making prior changes to the files, there's no need to patch - it doesn't offer any benefits.

I said something to the same effect (though I wouldn't say it doesn't offer any benefits).

But I was mainly pointing out that resisting patching by claiming it'd be too much work taking earlier mods into account and defending overwriting by saying it doesn't hurt to overwrite because there are no earlier mods isn't precisely iron-clad logic.

Conflicts with other overwriting mods are more easily handled in the other mods.

However, in doing so you are effectively unloading the burden of compatibility on the other mod. Any compatibility-related problems will be the other mod's fault and it will be up to the other mod to accommodate your mod.
I have a similar complaint about the Worldmap mod. It shifts the burden of compatibility onto the other mod by mandating that it provide the Worldmap mod the info the Worldmap mod needs to get it right, [1] in the form or area and link tables. And woe onto the mod that doesn't obey, as the Worldmap mod starts its installation routine by deleting the then-existing worldmap.

It's not very nice.

[1] That's apparently only if you install it with original travel times and area visibility. If you use the revised option it relies entirely on data enclosed within the Worldmap mod itself.

[Mike1072]

When installed on a near-vanilla installation with no mods making prior changes to the files, there's no need to patch - it doesn't offer any benefits.

I said something to the same effect (though I wouldn't say it doesn't offer any benefits).

Well, Demi is responsible for maintaining the main component, and he finds it easier to modify files with NI than via .tp2. Perhaps I should have said it doesn't offer any compatibility benefits (other than w/ Fixpack).

But I was mainly pointing out that resisting patching by claiming it'd be too much work taking earlier mods into account and defending overwriting by saying it doesn't hurt to overwrite because there are no earlier mods isn't precisely iron-clad logic.

Ah, but it is! Maybe it just takes some work to get there.

Leaving the install order as-is and rewriting the mod to patch would:
1) require a decent amount of work
2) provide no compatibility benefits

Changing the install order and rewriting the mod to patch would:
1) require an enormous amount of work
2) provide compatibility benefits

So, there's no point in changing to patch without changing the install order, and patching with a changed install order requires a lot of work.

Conflicts with other overwriting mods are more easily handled in the other mods.

However, in doing so you are effectively unloading the burden of compatibility on the other mod. Any compatibility-related problems will be the other mod's fault and it will be up to the other mod to accommodate your mod.

Since most of the older mods are no longer actively maintained, I'll probably end up doing the updating unless someone beats me to it, so I'd prefer to stick with the easier task. Compatibility helps all mods, and I'm doing as much as I can to make SR and IR compatible with other mods.

If and when our mods stop being updated, new mods should be able to take responsibility for maintaining compatibility with our old ones.

[Miloch]

An item or spell not behaving the way it says it does is a bug by anyone's definition and the work required to fix that bug should not be overlooked. The description changes made by SR and IR's main components could not be automated - they'd have to individually account for alterations made by previous mods, the same way the .itm and .spl patches would.

Miloch, would you care to respond to my post? I can't see any compelling reason to update IR/SR to patch resources given the amount of work it would require. Conflicts with other overwriting mods are more easily handled in the other mods. Is there some significant benefit I've overlooked?

Um, which post? If I haven't responded to something, it's because I see essentially the same arguments repeated - I feel I've already made my viewpoint clear, so I see no need to keep repeating it. Moreover, you overwriting proponents haven't really responded convincingly to my objections (not to me anyway). I doubt we'll come to any sort of agreement - there are essentially two schools of thought here, like there are on a number of topics.

If what you're talking about is the quoted assertion that you're ok as long as your overwriting mods are installed first... how many mods are going to claim that? Already there are older mods that have to be installed before even the Fixpack for compatibility reasons, big mods that overwrite spells, items, even creatures. Are you saying you're ok being installed even before them *and* the Fixpack? I don't think that's the current BWP recommended order. If not, you'll still have to account for what I've described, or ignore it and say "who cares" - the latter being a rather cavalier approach, to put it kindly (as Wisp says even kindlier, "It's not very nice"). For those older mods that aren't being maintained, there's not much to be done unless someone steps up to do it (not an easy task). You have a choice as a "modern" mod being actively maintained with easy patching methods at your disposal (compared to these mods that came out years ago).

And chance of a mod making an arcane use of exsiting item for their quest imo is far lower (do you actually know of one?).

Are there mods that use vanilla items for quests? *Of course* there are, probably too many to name. Aurora alone uses gemstones and other common objects as quest components, though if truth be told, we implement a lot of our own gems. But few mods do that.

[GeN1e]

Are there mods that use vanilla items for quests? *Of course* there are, probably too many to name. Aurora alone uses gemstones and other common objects as quest components, though if truth be told, we implement a lot of our own gems. But few mods do that.

Aurora doesn't add new effects to gems, therefore even if Revisions does change them, it'll have no impact on compatibility. I'll say it again, unless there's a living example of a mod that, in order for it's plot to proceed, requires a certain change to be made to spl/itm, the whole point is moot. It probably may affect combat difficulty introduced by said mod, but it will happen regardless of coding approach. If they simply need Item A in inventory, how on earth would it matter if A was changed?

Yes, here we might run into using diferent names. One of ideas actually had been recently discarded, partly because Item Upgrade asks for certain item names. But names have nothing to do with patching either.

PS Overwriting technical patches (like DS) still applies, but such mods clearly state in their readmes to be installed as last as possible, which surely makes it after Revisions.

Edited by GeN1e, 20 October 2010 - 05:25 PM.

[Wisp]

But I was mainly pointing out that resisting patching by claiming it'd be too much work taking earlier mods into account and defending overwriting by saying it doesn't hurt to overwrite because there are no earlier mods isn't precisely iron-clad logic.

Ah, but it is! Maybe it just takes some work to get there.

Leaving the install order as-is and rewriting the mod to patch would:
1) require a decent amount of work
2) provide no compatibility benefits

Changing the install order and rewriting the mod to patch would:
1) require an enormous amount of work
2) provide compatibility benefits

So, there's no point in changing to patch without changing the install order, and patching with a changed install order requires a lot of work.

That's for revising the mod to patch, yes. But the original exchange between Miloch and Demivrgvs was about writing the mod in the first place (as least that's how I understood it).
I'm not suggesting that the mod be rewritten. Obviously it'd be a lot or work. I'm arguing against the notion that overwriting is somehow necessary or the only way to to it (or the best way to do it).