Mike1072

I'm the author and can try to explain. It creates an inlined file with contents: OUTER_SPRINT string @1234 Then, it INCLUDEs the inlined file, which executes that code. Its purpose is to fetch the text for either a TRA ref (@1234) or a strref (#1234). You must include the @ or # symbol as part of the ref variable. WeiDU does have built-in tools that deal with fetching only TRA refs (AT) and only strrefs (GET_STRREF). Here are examples of their usage. In these cases, the ref variable should contain just a number, no symbol. SPRINT string (AT ref) GET_STRREF ref string The home for my function (named FETCH_STRING) is here. There is a companion function named RESOLVE_REF in the same file, which is what Item Revisions actually uses. It behaves similarly, taking either a TRA ref or strref, but instead of returning the associated string, it returns the associated strref. In the case of a TRA reference, this involves adding the string to dialog.tlk. This would be more useful for a situation where the .tra file contains complicated entries that need to be preserved, like associated sound effects or male & female lines for the same reference. That extra information is normally lost when putting the string into a WeiDU variable.

Those last 2 columns should be strrefs according to IESDP.

I wouldn't have anything against you using the current icon, if you cleared it with @bob_veng.

I've moved those posts into this topic to help de-confusify.

You want the FnP & SR variants to co-exist? The old icon is no longer being used in SR. You could ask the original artist for permission - @DreamSlaveOne.

Sounds like the discussion has run its course.

For vanilla BG1 scrolls, the store in High Hedge has most of them up to level 3 and Sorcerous Sundries has most of them up to level 5 (with the selection diminishing for the higher levels). Each scroll can also usually be found in a couple of containers in the world and in the inventory of a single unique enemy mage. The level 1 through level 3 scrolls (and some level 4 ones) are present in RNDSCROL.2DA, which is referenced by the other random treasure tables and so may appear randomly as loot. The spells introduced in BG2 are rarer, with their scrolls showing up in perhaps just one or two locations in BG:EE.

I'm simply maintaining SR. kreso may be more open to implementing new content, but including spells from other mods is not one of SR's goals. Firstly, SR is intended mainly as a rework of the existing spells in the game. It adds some spells where necessary to fill gaps (e.g. differentiating druids from clerics, filling out specialist spellbooks), but arbitrarily adding new spells is not the focus. Secondly, if the spells exist in working form in another mod, you can use that mod together with SR; there's nothing gained by duplicating the content within SR. If it's a matter of wanting to rebalance spells added by other mods, that won't be addressed in SR. Your best bet for that is to address it at the source, or if that proves impossible, to create a separate mod specifically for rebalancing mod content.

Off-hand THAC0 bonuses and penalties have no effect unless you are dual-wielding, so it is indeed harmless to have on a two-handed weapon. It wouldn't be hard to add a two-handed check to the item patch, though.

Here's a combination of my understanding of your steps 3 through 5 mixed with some suggestions. I have no experience with using these opcodes, just operating based on the descriptions in the IESDP. To add the appropriate spells, you have 7 different 326 effects, each comparing a different bit of the stat and casting a spell that adds all spells the appropriate number of times: if bit 0 of stat is set, cast spell "add1x" if bit 1 of stat is set, cast spell "add2x" if bit 2 of stat is set, cast spell "add4x" if bit 3 of stat is set, cast spell "add8x" if bit 4 of stat is set, cast spell "add16x" if bit 5 of stat is set, cast spell "add32x" if bit 6 of stat is set, cast spell "add64x" Then those spells cast subspells for each level. "add1x" casts: "addlvl1" "addlvl2" "addlvl3" "addlvl4" "addlvl5" "addlvl6" "addlvl7" "addlvl8" "addlvl9" "add2x" casts "add1x" twice "add4x" casts "add1x" four times "add8x" casts "add1x" eight times "add16x" casts "add1x" sixteen times "add32x" casts "add1x" thirty-two times "add64x" casts "add1x" sixty-four times When the player has 1 spell point remaining, you want "addlvl1" to be applied and none of the other "addlvlX" subspells, so you're trying to apply an immunity to "addlvl2", etc. It sounds like you're using the correct relation, so I don't know why that isn't working. Instead of applying immunity to those subspells, you could try changing "add1x" so it conditionally casts the subspells, using opcode 318 to only cast when the stat is greater or equal (relation 4) to the spell level. New "add1x": if stat >= 1, cast spell "addlvl1" if stat >= 2, cast spell "addlvl2" if stat >= 3, cast spell "addlvl3" if stat >= 4, cast spell "addlvl4" if stat >= 5, cast spell "addlvl5" if stat >= 6, cast spell "addlvl6" if stat >= 7, cast spell "addlvl7" if stat >= 8, cast spell "addlvl8" if stat >= 9, cast spell "addlvl9"

Yes, you won't be able to push directly to a G3 repo unless you are the maintainer of the mod. Our standard practice is for contributors to create a fork of the G3 repo, push their changes to the fork, then submit them to the G3 repo via pull request. After you create your fork, you can adjust the remotes in your local repo with these commands (using the appropriate URL for your fork in the second). git remote rename origin upstream git remote add origin https://github.com/yourusername/SpellRevisions.git With these remotes, you'll be able to push to origin (your fork) and pull from upstream (the G3 repo).

I'm encountering an error when trying to install iesh. I'm using Python 2.7.17 and running python ./setup.py install in the repo folder. I receive a message about a syntax error on this line. The full output is below.

I commented on Faerie Fire in your original thread. This is a bug that I can fix.

You should definitely apply your changes to the resource files inside the mod folder instead of the ones installed in the game. There is little chance that SR patches will override what you do, because SR doesn't really use patches that way. The patches that exist in SR mostly do things that can only be done at install-time. If you're comfortable creating separate branches for each feature as you suggest, that's absolutely the best way, because it lets us add further commits on that branch if necessary and then squash when merging. Many modders are newcomers to git, so this is not a requirement.

It doesn't seem to be hardcoded. Instead it uses 8 sequential strings starting with the strref specified in parameter 3. I've submitted a pull request that adds the strings with sound effects to dialog.tlk using RESOLVE_STR_REF and assigns the first strref to parameter 3 of the .eff file.

STRING_LENGTH string Should be: STRING_LENGTH ~%string%~ If this makes you feel stupid, don't worry. You wouldn't believe how many times I've accidentally done the same when comparing strings. Yes: INNER_PATCH ~%string%~ READ_BYTE 0x00 type READ_BYTE 0x01 flags READ_SHORT 0x02 location // etc. END

Yeah, the other components affect items in the base game as well as items added by mods. With the above install order, items added by Song & Silence or Rogue Rebalancing wouldn't be affected by the "Revised Shield Bonuses" or "Kensai Can Wear Bracers" components.

The v2 readme is accurate for v2, which is the last official release. The readme in v4b10 is not completely up to date, which is to be expected, since it's a beta. (It's perhaps not expected to remain in beta for this long a time.) Part of preparing an official v4 release will involve updating the contents of the readme.

Thanks. This needs to be corrected in both spwi224.spl and sppr114.spl. Any fixes that you can contribute to the GitHub repo would be appreciated.

That's exactly how it was originally implemented. I tried to find the rationale for the change to a percentage-based system, but the best I could find was the following exchange from the Revised Armors thread. I have a recollection that the percentage values chosen were designed to mimic the original penalties (-1 to -3) for a character at 18 DEX. Essentially, the percentage-based system should behave similar to the flat value system regarding bonuses for high dexterity without penalizing low dexterity characters as much.

Thanks for the report. This was a bug in SR that will be corrected in v4b19. Edit: The bug also affects Animal Growth.

@Bartimaeus is responsible for IRR, so your question is best addressed to him. As far as I know, your only options are to use IRR or not use it.

I've moved this discussion out of the SCS thread. I don't think anyone's been deleting your posts. It looks like the forum might have mangled the one that's 2 posts up. If you register for an account, you'll be able to edit your posts. Jarno excels at derailing threads. Sometimes it's best to ignore.

I've moved the off-topic discussion here.

Fixed for the next version. The icons are similar but not identical. I'm not sure how I'd feel about making a minor change like a flip, since both icons are from the vanilla game and the issue hasn't come up before. Dispelling Screen uses the icon for Spell Immunity, the spell it replaces. If we were to make a change, I'd prefer a redesign that makes one of the icons more distinctive. The per-level improvements of spells (e.g. increased duration) are capped at level 20, like in vanilla. Dispel Magic's effectiveness depends on both your caster level and the enemy's caster level. I don't think it has a cap. However, you'll be as successful dispelling 10th-level magic when you are level 10 as you will be dispelling 25th-level magic when you are level 25. No, it does not. Mirror Image Fix: This component fixes mirror images so they no longer protect from AoE spells such as Fireball. Dispel Magic Fix: This component prevents innate weapons (like claws provided by Polymorph and Shapeshift spells) from being dispelled by Dispel Magic. I believe both of these bugs were fixed in the EE games, but if you're installing SR's main component, you'll need to install these components to affect the resources added by SR. I'll probably move the fixes into the main component in the future. Spell Revisions does not change items. If an item has on-equip effects or activated abilities that do not match specific spells, there will be no change in how they function. However, if an item has an activated ability to cast a particular spell, then that spell will most likely be the SR version. If you install the main component of Item Revisions, it will update the item effects in a manner consistent with SR. The mods were designed to be used in tandem. Thanks for the nice words about the mod. All praise should go to @Demivrgvs and the other contributors. Regarding SCS, I expect it will require an update to achieve compatibility with SRv4b17+. I believe @DavidW is aware of what may need to be changed as we discussed the SR changes here.