Mike1072

ADD_SPELL can replace an existing spell if it matches the identifier you're trying to add. This avoids having multiple copies of the same spell in your spellbook, all added by different mods. It's preferable to just have one version of the spell - the one added by the last installed mod. If mods incorporate their mod name into their identifiers, then this matching won't happen. SR_FAERIE_FIRE would be installed alongside TDD_FAERIE_FIRE and all the other versions installed by other mods.

The reason I am against including mod names in SPELL.IDS is because it renders ADD_SPELL useless for merging duplicates.

My preference is for the neutral set of identifiers without the mod name included - e.g. ANIMAL_SUMMONING_I, ANIMAL_SUMMONING_II, ANIMAL_SUMMONING_III.

If you want to give it a go, feel free. The biggest obstacle is accounting for the changed filenames. Everything that's moved over to ADD_SPELL will be assigned a different filename, and there may be references to the original filename in subspells or in other spells (e.g. Glitterdust, Protection from Fire, Globe of Invulnerability).

I opened an issue on GitHub for the stack sizes a while back: https://github.com/Gibberlings3/ItemRevisions/issues/16

With the release of SR V4 Beta 16, I'm closing this discussion. Please leave comments for SRv4b16 in this thread.

With the release of SR V4 Beta 16, I'm closing this discussion. Please leave comments for SRv4b16 in this thread.

V4 Beta 16 is now released. It includes all of kreso's changes from b15 and a variety of bugfixes and compatibility improvements. Thanks go out to kreso for b15, Bartimaeus for extensive bug reports and work in SRR, subtledoctor for coding up fixes, and Mad Mate for organizing everything on GitHub. View on GitHub Download (Windows) Download (OS X) Download (Linux) Changelog:

Okay, I can sort that out. I'll take a look when I get home.

I think it's worth tackling the bit about some AoE spells not being blocked by Spell Deflection, first. If it's not ready for testing, that's fine. If it is, we should release a new beta. We don't want people going to your repo and downloading your master branch. The file is created in the code and then copied over as it is patched. My rough understanding is, creating it in the code involves the assumption of a virtual directory. The "d5/" directory doesn't actually (and need no actually" exist anywhere. That's the extent of my understanding - I parroted this from code in another mod. Yes, this should work fine. Most of the time, we call out those inlined files by naming them ~.../inlined/blahblah~ so when you see something that interacts with it, you can tell that it's not looking for something in the file system.

There are a few things we haven't done yet for v4 - the docs need updating, especially the spell information.

Issue a pull request and we can release it as b16.

If you're creating releases via the Mod Packaging tool, it doesn't have any explicit support for excluding files or folders (and it won't ignore stuff you specify in .gitignore). However, you could go in and modify it to exclude your specific folder. It already excludes some predetermined files depending on whether it is packaging Windows, OS X, or Linux versions (see the -x flags on lines 83, 95, and 106 here).

Hmm, I'm not sure why they wouldn't be working. I don't have a tablet to test on, though. Is your browser up to date? Have you tried another browser?

Holy balls, I must have been really out of it when I responded before. I was thinking about Spell Revisions v4b15. Yes, IRv4b10 is the latest version of Item Revisions. If you grabbed the Windows .exe from the release page, it would have included the setup file. All setup-blahblah.exe files are copies of WeiDU and are essentially interchangeable. The only caveat is that some mods that use newer WeiDU features won't work if you try to install them using an older version of WeiDU. But all the setup files in your game directory should automatically update to whatever the most recent WeiDU version is among them.

Jarno, please keep your posts on topic and to the point. It's very difficult to follow what you are saying. We have few moderation policies here except NO SPAM. Posts that don't contribute to the topic at hand will be removed or relegated to a dark corner of the forums.

No, I don't think that can be done. The "bestow enchantment" effect is a property of the launchers, not the ammo.

A recent pull request from Mercurier has brought to light an issue that I think deserves further discussion. We have the ability (in EE games) to make it so launchers can bestow their enchantment level (in terms of what can be hit) upon ammo that they fire. This is something that Demi requested, though I don't know his whole plan. Without this tweak, to hit a creature that needs +3 weapons to be hit, you would need to use ammo that's +3 or greater enchantment. With this tweak, you could use either ammo that's +3 or greater enchantment or a launcher that's +3 or greater enchantment. In addition to the enchantment change, Mercurier proposed removing the damage and THAC0 bonuses from ammo. Right now, both our launchers and our ammo gain THAC0 and damage bonuses from enchantment level, so it stacks (+1 shortbow with +1 arrows = +2 THAC0 / +2 damage). I don't know if that's best, but I think that completely removing the bonuses from ammo would render plain enchanted ammo almost entirely useless. I'll quote our discussion below. Per PnP launcher and ammo enchantment (and the associated damage/thac0 bonus) should not stack, but the higher one takes precedence. Current EE engine provides limited support for this rule for the enchantment part (determining what the weapon can hit), but not for the damage/thac0 part. IMHO stripping off damage/thac0 from ammo could be a close approximation: players can still hit dragons/liches with +0/+1/+2 launcher plus +3 ammo, but will lost a little bit of damage/thac0, which I guess is not too big deal. A good application is using Strong Arm (+2) and +3 ammo to quickly takeout dragons. Additional note here: In my personal mod I changed Strong Arm to a non-magical short composite bow crafted by its original owner-- an ogre hunter. In player's hand it functions as a composite longbow requiring 19 str (+8 dmg) -- good at wiping off mobs yet requires rare ammo for serious boss fights. This is a good example that an early game equipment gets extended utility during late game. Some players use weimer's item upgrade mod so that their beloved Celestial Fury gets extended utility. I envision this tweak will open the road for more flexible and innovative item designs. Yeah, but the effect of this change is that the majority of the time, +1/+2/+3 ammo would function no differently from unenchanted ammo. Once you got a +2 weapon, +2 ammo would be worthless. I think it might be good to move this discussion to the forums. What do you guys think? Is doubly stacking THAC0/damage a problem? What solutions would ensure that more heavily enchanted ammo remained better than less heavily enchanted ammo? If anyone can find prior discussion of these issues, linking those posts could help.

Are you using IRv3 by chance? It does not support BG2EE. You should grab either IRv4b15 or Bartimaeus' IRR. Delete the weidu.conf file in your game directory. Then, the next time you try to install a mod, it will prompt you to select your game language.

You can revert a commit using git revert. This has the effect of creating a new commit that undoes all the changes of the old commit. git revert commitHash There's a more advanced way to edit and reorganize commits (git rebase) which can rewrite history so that the changes were never committed in the first place, but it's recommended to only use it when you haven't yet pushed your commits somewhere other people can access them.

v3 is essentially out of date v4b14 is Demi's last release v4b15 is kreso's continuation, essentially officially approved SR Revised is Bartimaeus' personalized version, forked off v4b15 Right now, v4b15 is probably what you should be coding around. It has some compatibility issues with non-EE games, which is why it wasn't released on GitHub. However, the changes there are official. There are no plans at this time to incorporate Bartimaeus' changes wholesale. However, Mad Mate and subtledoctor have recently begun incorporating some of the fixes that Bartimaeus reported as well as fixing other issues in v4b15, so a working v4b16 is on the way. I don't think it will have much in the way of conceptual changes, just bugfixes.

Updated.

What do you think of this instead?

Guess I'll have to take your word for it.

Similar to lynx, I don't see how this idea of metdata within mods would solve any problems. 1. You're still going to need to maintain an external list of all the mods, so you know where to pull metadata from. 2. There will always be mods that have no metadata or incorrect / out-of-date metadata. If you discover this, then the only way to fix it is to update the mod (which modders may not do immediately). 3. There's no way to load the metadata without downloading the mods. So in essence, you'd still need an external database to store the mod URLs and cache the metadata (to avoid redownloading all the mods every time). And you'd still have to figure out whether you wanted to do anything special for mods whose metadata is known to be wrong. Those issues aside, there's really no need for the metadata file to match the name of the mod. And if you know there are mods that already store installation settings in that file, you definitely should choose a different filename for storing the metadata.