Magus

It would be delta if you only downloaded the diffs (not repo or tag or release source) and then apply the diff to the local. But I think it's too much to take on. What you describe is, I don't know, git update, or incremental update? Well, it doesn't matter much, just the question of terminolgy.

The second part is quite simple - somewhere midgame I happily update some mods and suddenly hell breaks loose - some of them fail to install. Or install and cause crashes. Or screw up tkl refs. Or else.

I want to be sure that at any point I can revert to the original state and continue playing the savegames I have. Preferably, with one button click.

(Well, theoretically, since PI is windows-only and I don't have windows).

"Delta" usually refers to bin files, I think the name is misleading.

Anyway, I don't feel enthusiastic about this. I think that any bugs coming up in a existing installation are better handled by CLUAConsole. There's just too much that can go wrong with a mid-game update.

But if you do actually implement this in one form or another, the first must have features are backup and rollback.

Re: stuttering, I just use Pack Mule mod and don't take the holding bags anymore.

@jastey OK, but do you think that most users will see your advice before installing? Because the usuall workflow as I see it: fire up PI, install whatever seems good, get bugs, come complaining.

1. There is no bug in my mod or your mod per se. They are perfectly good. It only manifests in a combination.
2. Therefore, for the time being, those users that did see your advice have to choose between our mods.
3. If there's another reason mods can't be installed together, it's a conflict, and that's discussed in the other topic. This example is specifically about install order because that's the topic here.
4. As for community - well, how come a global list doesn't get fixed by community, but mods do?

@AL|EN and then we of course get the opposite situation when I finally update my mod (changing the order some more) and jastey disappears. The history repeats.

Not that I have any intention of disappearing, or expect other people to. But I would like to have a better plan than just hope for the best.

Anyway, if a global override feature I suggested in the conflict topic is confirmed as an eventual possibility, then I wholeheartedly agree that Dynamic is better.

@jastey situation:

1. Users complain about a bug in your mod.
2. You spend time debugging, and track it down to my mod being installed after yours (because I've specified that in my ini file)
3. For whatever techical reason, you can't resolve this on your side.
4. You go to github, open an issue, let's say even dig into my code and see that actually I made a typo and meant to install my mod before yours. You even submit a pull request with correction.
5. I'm unresponsive.

Your actions? Day 1, day 7, 30, 365, etc.

You're right, individual components conflicts with their numbers will certainly fail to be maintained in a centralized fashion.

• It's possible to have a centralized list for global conflicts, while keeping the local ones in metadata, but that's likely to get even more confusing.
• It could be possible to automate stuff with github actions, parsing and maybe even committing the updates into global list, but duplicating data is never a good idea and will also incure extra burden on the modders.

So, I agree that the distributed way is more likely to succeed, even with the issues I listed.

And it's not that I like the centralized way too much. Quite contrary, in fact. It's just that I didn't see an alternative way to deal with code rot.

But coming to think of it, I do have one more idea: a central override list. Which would be used as a last resort option, when there are documented problems caused by prolonged lack of updates by missing modders. A manager could compare the timestamps of the last release vs update time of the override file, and use whichever is newer. Normally, the override repo would be completely empty (and hopefully it stays so). And even if an old override file gets forgotten, it wouldn't matter. This could be the best of both worlds. Finally, there's even no need to implement this until such an issue arises. If it ever does, then you could add this functionality - I think wouldn't be too hard? (This applies to both conflicts and Dynamic Order).

2 hours ago, AL|EN said:

I'm a fan of modern file format. I've consider using JSON/yaml, even offered support for it for metadata. There was no single question regarding those. This is reality which I have to accept.

Well, you have one now. All those who think that ini is better than yml in this use case - raise hands!

Is it still supported now? I'd convert to yml.

I'm saying that

1) The efforts that were before and the effort discussed here are not equivalent.

2) If you believe that a new centralized list will fail, then Dynamic Order (as it's implemented right now) will eventually fail even harder.

I responded there. And irrespective of that, please consider using yml instead of ini, however this and that works out.

3 hours ago, AL|EN said:

Plus, the conflict definitions would have to be done via old, flawed BWS-DESIGNATED-way where one mod update would cause domino of errors and incorrect conflicts. I don't want to repeat this.

Not at all. A centralized list doesn't mean scopes can't be used. If anything, it's even easier to introduce them.

Following the mention in Mod Conflicts, I'd like to make some points. Might be too late, considering that Dynamic Order has already began rolling out, but anyway.

On 8/19/2019 at 12:52 AM, jastey said:

What I do not like (but I don't have a better solution, either): it looks like the component numbers need to be inserted by hand with the numbers they have internally upon installation. For some of my mods, I do not know the exact numbers (e.g. bg1re with a lot of optional components) of each component (without spening time to count them etc.)

1) As it's been pointed out, in most cases component numbers are not necessary.

2)

On 1/15/2020 at 4:32 AM, jastey said:

I can only talk for myself: as much as I am interested in help players to have correct install orders, I can only correctly list my own mods - and not in relation to all others since I do not know all other mods. I would like to pass on any install order requirements or restrictions for my mods that I know of, though.

No one knows all the mods. You are not required to do more. The relationships to mods by other authors can be defined as they become known.

  3)

On 1/15/2020 at 2:27 PM, jastey said:

Whether this information could be automated completely I am not sure, especially since what you described @Leeux sounded very much like what BWS was providing which was the reason people burnt out while maintaining it, at least if such mod install order informations would need to be updated when new mods come out - or maybe I'm missing something.

It can be automated.

3b) BWS took on much larger task - encompassing all exising mods. AFAIK PI only takes relatively small amount for now, which are relatively well-maintained: the ones in GH organizations. More importantly, BWS list was mostly maintained by the people who were not the authors. In a centralized list of mods supported by PI, you would only be responsible for you own mods.

  4)

On 1/16/2020 at 10:53 AM, jastey said:

Yes and no. Putting it into the mod's ini is done on the by while updating the mod. Having to edit the list is two/three extra steps - and such needed modder collaborations never worked in the past... I am thinking long scale here: doing it once is no problem. Doing it every update because something changed, for example will eventually cease, and info in that list will become outdated. Plus: i know it sounds silly, but sometimes this happens because people forget about it after making changes to their mods. For example I wasn't aware of the BWPFixpack every time I made updates to my own mods, although I was very interested in incorporating its fixes.

...

Definitely true, and that is why one list makes much sense, not only for players. But info might be outdated at some point, that is my fear, so we should check whether e.g. creation of such list from mod.ini info might be possible or even feasible thing. Probably not, as not every mod can list all others it should be installed after / before...

What happens when your mods become outdated? Say, you're away for half a year, or busy, or wating for external updates (translations, etc). With order information available only in your mod, it's up to you to make the update (well, and maybe a few other people if you gave them access to the repo). With a centralized list, it's up to you and everyone else. The order in your personal ini in mod folder has more chance to become outdated.

5) I think that having absolute order and/or a single list of files is hard to maintain and is indeed off-putting for modders to work on. A better option would be to allow each mod to have its own file, in which dynamic rules are defined.

6) INI format itself is not great for structured data. I would rather prefer something like yml.

 7)

2 hours ago, AL|EN said:

Regarding 'online list for collaboration', I'm sure that you understand why the last thing that I think of. There was attempt to do it for install order and it didn't fly.

I fully understand the reluctance. Still, I think that centralized option has a better chance of working.

I don't fully understand what do you mean by "didn't fly", though. Was it ever live? Was the list actually used? I was not aware of it, nor did I have commit access.

My suggestion (which, again, I know, a little late):

Say, taking UA as an example

# rules/ua.yml

policy: bottom # optional, means that generally it should be installed as late as possible
before:
  - stratagems
  - ir # item randomiser
after:
  - bg2fixpack
  - rr
  - tactics
conflict:
  - item_rev # just because

In the whole list repo, I would be responsible for this one file. The manager would then evaluate the files and construct the correct order. Specific before/after rules would obviously override the policy, and mods sharing the same policy and having no specific rules regarding each other, can be sorted however, say, alphabetically.

Now, if there was such a repo, and it was actually in use by a manager, and I had access to it, then I would commit such a file. Otherwise, why'd I bother? Even the new dynamic rules for install order that are in BGforge mods were submitted via pulls, I didn't write them myself. It would've been exactly the same in case of a central list.

Lastly, I think the reason centralized dbs have somewhat bad rep is because it seems like a gargantuan task, and that's because people want to have the ultimate list from get-go. There's no need for that. Let the list build itself naturally. If it gets stale it would be because literally no one cares. Which means there's no problem to begin with.

So, while late, I propose to reconsider this one more time, for both install order and conflicts.

I'm 99% sure it is, as it's already on the creature.

There's 3 options:

1. A pre-defined set of scopes.
2. 1 + custom scopes.
3. A set of rules for scope naming.

I believe the only one that will possibly be useful is 1). The other two will likely lead to a number of scopes greater than the number of actual conflicts, and increase maintenance burden rather than reducing it.

On the other hand, I'd like to retract my previous point to some degree. It not necessary to markup the whole mod in one go. In fact, probably not possible except for the simplest mods. Conflicts can be added as they are discovered. However, that requires collaboration from both authors.

And that brings us to the next issue, where the system fails hard: it takes two to tango. Until both mods are updated, the manager doesn't know about the conflict, and is displaying wrong data to the users. And one of the mods may never be updated. What are you going to do? Exclude the mod from the manager altogether? That's a bit heavy handed. Allow one-sided conflict rules based on LABELs or DESIGNATED or whatever? But what if such a rule was added, and then the author went AWOL, but the conflict was resolved by the other mod's update?

You can easily reverse this, too: A/B/C all conflict and marked as such, B and C resolve their conflict, A is stale, now you're displaying a non-existent conflict.

Some more puzzles:

1. Take the 3-mod edge case and make it 4. Now instead of 3 relationships you got 6.
2. Mod A is compatible with both B and C. But it's not compatible with their combination.

To summarize:

1. I agree that the scope system could be useful some cases.
2. However, there's no way it'll cover every possible confict without becoming unmanageable.
3. For a complex enough mod, it's cost prohibitive to mark it up in its entirety from the beginning. So the updates will be incremental.
4. Still, warning about some conflicts is better than nothing.
5. But over the years, discrepancies will pile up. Unfortunately, the only possible solution I see for the stale code is a centralized database.

And I know, of course, that centralized dbs didn't do great so far. However, consider this:

• Scope system: it takes two certain people to mark a conflict: authors of mods A and B.
• Centralized system: it takes literally anyone to submit a pull, and anyone else with access to the list (which should include the said authors) to accept it.

The second has a better chance of happening, simply because there's many more people who can make it happen.

Well, I don't know the answer to all this madness. But it seems to me that a combination of scoping with a central db for finer control could possibly work.

Depeding on the flow, you don't necessarily need to rebase.

Most of the time, just

git pull upstream master

will work (pull = fetch+merge).

There will be no problems if you look up the offsets correctly.

It is common etiquette to post the solution to the problem if you found it, so that others may benefit from it later.

As for your last question, better try R_B_B.

2 hours ago, AL|EN said:

@qwerty1234567 

1) The case A is different from B because you can install B just fine without error during installation and there are no game bugs, while A would produce error which prevents installation or even if it is successful, it causes game bugs.

2) I don't see why having long list of scopes is harmful of makes this solution worse. Mods doesn't need to use all of them to covet the 'popular game scopes which are covered by many mods". Can you elaborate?

An example for the 'WildMage' Misc spell changes component: https://github.com/BGforgeNet/bg2-wildmage#misc-spell-changes

This component changes two spells: Magic Missiles and Dimension Door. So the conflict scope would be:

METADATA "SPELLS\MagicMissiles ; SPELLS\Dimension Door"

so all mods which modify those spells, like for eg "Spell Revisions" could account and warn players about possible outcome change.

1) sorry, I meant to say b) and c)

2) so let's say there's one mod that changes MM range, and another one changes their damage. They don't conflict. But they could conflict with others, so we need to extend the scope to "SPELLS\MagicMissiles\Damage; SPELLS\MagicMissiles\Range".

Cool. So what, I'm supposed to detail every change in the mod in this format? Well, I'm simply not doing that.

Worse still, two mods may conflict only when in presense of some 3rd mod.

11 hours ago, Sam. said:

Not that my opinion counts for anything, but in general I prefer NI's jargon over the language used in the IESDP, especially the names of Effects.  I'm sure both are technically correct, but NI uses language I find more natural.  I acknowledge this is purely a personal preference.

Me personally, I wouldn't care much which specific word is used in this or that case (would've probably some kind of combination of both), as long as terminolgy is consistent.

1.  I've submitted smallest pulls correcting typos in IESDP and they were accepted. That is not a problem.
2. I also submitted large ones, with a lot of discussion and back-and-forth.
3. You can easily maintain your own fork and work in it (which is what I do, incidentally).
4. The real reason IESDP is missing stuff is simply because no one cares enough.
5. The way open source works, once you've bugged admins with good pulls one too many times, they'll give commit access to you =).

On 11/24/2020 at 3:57 AM, Guest Spellcaster said:

To ask why IESDP is lagging behind latest community knowledge on this particular issue where Near Infinity is not: Couldn't both communicate and remain in sync?

This one I find very important. I would love to have the efforts centralized, and the logical place for that is IESDP. Also, various differences in naming between IESDP and NI always throw me off when I get back to modding.

I've done some work on converting the data into machine readable format, which enabled all the nice tooltips in MLS. I think that overall it would be beneficial if NI also used that, but I think @argent77 seems to be sceptical of the idea.

1) a) and b) cases look the same to me.

2) I don't think it'll fly. Mods are changing everything. The number of scopes will either be not enough, or explode exponentially.

On 12/4/2020 at 7:40 AM, subtledoctor said:

Possibly because she leads people to say things like “Roxanne’s Installer Tool,” as if it is hers, when it in fact is an open-sourced tool created by others. She just has her own personal fork of that tool. (Analogous: you can freely create a fork of one of my mods, but I don’t think we would describe your fork of my mod as “your mod.”)

On an off note, it's perfectly acceptable to fork and distribute an open source project (as in, FLOSS - I don't if BWS is). And it's actually beneficial to do so under a different name, so that it's clear to the users which one they are using and where to go for support. Which doesn't negate the requirement for giving due credit to all past and present contributors, of course.

I think chainText doesn't support IF_FILE_EXISTS in first line.

Now would probably be a good time to put in such a request.

https://regex101.com

STATE_WHICH_SAYS #43058, I think

On 8/20/2020 at 9:12 AM, Caedwyr said:

Another way to handle it is to give a stat bonus (+2 str) that the polymorph effect grants, so a druid with 18 STR would have 20 str after shapeshifting into CUSTOM FORM that grants a +2 STR. The druid with threws of ironwood, becomes imbued with the strength of the bear, while the spindly druid is strengthened by the spirit of the bear.

Is there any strong feelings as to which is the best way to handle things?

So a druid with STR 3 would end up being a bear with STR 5?

I wouldn't say I have strong feelings, but it would seem strange to me.

I'm interested in the topic, but I'm not sure what to look at in the last screenshots.

1 hour ago, subtledoctor said:

I don't think something like GET_OFFSET_ARRAY2 is designed for global/equipping effects, so I'm checking the effects manually.

I think GET_OFFSET_ARRAY should work, see ITM_V10_GEN_EFFECTS. Also, there are BIT1-BIT31 constants, to make the code more readable.

When in doubt how things should work, I find it best to consult the source books and my inner DM, and apply some common sense on top.

If I was a DM and a player in my party said "my skill thief dispels all illusions, 100%, no protections", how'd I handle it?

I'd probably say: "ok, maybe your character can see through illusion, but it doesn't mean that all other characters in party do".

And then it depends on how do you treat the ability. If it's a standard action (I think it is, but it's just a feeling), then the skill boils down to applying "see invisible" opcode to the rogue, because a character can't attact of cast or whatever during an action. Maybe add protection from illusionary creatures on top. The result is that the rogue can show the wizard where to throw fireballs, but not much more.

If you treat it like a passive, then it means that the rogue can attack, cast and stuff, but illusionary penalties do not apply to the thief. I.e. he always hits the target, not its mirror image, no penalty for attacking imp.invised creatures, etc. This option would likely be very hard to implement on IE, if at all possible.

Either way, it's a pretty serious nerf, especially so with SCS, and I doubt many people would use it. Athough I think that's how it's "supposed" to work, more or less.