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. There is no bug in my mod or your mod per se. They are perfectly good. It only manifests in a combination. Therefore, for the time being, those users that did see your advice have to choose between our mods. 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. 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: Users complain about a bug in your mod. You spend time debugging, and track it down to my mod being installed after yours (because I've specified that in my ini file) For whatever techical reason, you can't resolve this on your side. 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. 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). 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. 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. 1) As it's been pointed out, in most cases component numbers are not necessary. 2) 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) 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) 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) 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: A pre-defined set of scopes. 1 + custom scopes. 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: Take the 3-mod edge case and make it 4. Now instead of 3 relationships you got 6. Mod A is compatible with both B and C. But it's not compatible with their combination. To summarize: I agree that the scope system could be useful some cases. However, there's no way it'll cover every possible confict without becoming unmanageable. 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. Still, warning about some conflicts is better than nothing. 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.

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.

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.

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

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.

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.