Mike1072

The links remain the same with updates. Demi hasn't updated SR since April 13 (see name of topic). That's 7 months ago.

The changes have already been made, just waiting for Demi to release the next update.

I love that idea. Edit: well, I like it.

I think the original BG1 stone background on spell icons looks great when used with the original BG1 UI (or LadeJarl's version for Tutu). It doesn't blend quite as well with the UIs in BG2, BGEE, BG2EE, and the Dragonspear Preview.

The icons in the enhanced editions are probably from 1PP, which has a component to make BG2 spell icons match the BG1 style. In vanilla BG2, the spells that were carried over from BG1 look distinctly different from the new ones. The spell emblems in BG1 appear painted on a shiny stone, while the ones added in BG2 appear embossed in a stone and have less of a sheen. Compare Vanilla BG2 to 1PP Consistent Spell and Scroll Icons. I prefer the BG1 style, and since we now have 1PP and EE enforcing it as the standard, I think we should follow suit.

As a general guide.... Everything that modifies or duplicates an existing item should be installed after IR's main component. Everything that adds a new item should be installed before IR's global components.

Cool. If I ever get some free time, I was considering making an L1NPCs-lite version from scratch just for the EEs if nobody gets around to updating L1NPCs before my inevitable next playthrough.

Thanks, Ineth. In the next beta releases, IR and SR will be using HANDLE_CHARSETS. They will also have support for EET, thanks to K4thos.

Huh. Still, it should be changed to the American English spelling to match the rest of the game ("armor").

Long ago, some of the global changes were included in the main component, so the .itm files had stuff like "Remove Cleric Weapon Restrictions from Multi-Classed Clerics" pre-installed. When those features were removed from the main component, some of the items may have been missed. The reason nobody noticed until now is probably because most people are installing the separate component to accomplish the same thing, so the items are behaving the way they expect them to.

Thanks, Salk. These bug reports are very helpful.

Awww!

I think it was intentional, but I have no recollection of why.

The answer is that I am lazy and there are actually a lot of updates that haven't made it to the front page.

IR's masterwork weapons can still be installed, but they are disabled by default for v4. To install them, you need to open settings.ini and change the appropriate value before installing the mod. We disabled it for a couple of reasons. It wasn't substantially different from the one in SCS. It was coded pretty stupidly. I never got around to implementing it the way I really wanted: introducing them as separate items with unique icons, instead of replacing +1 weapons. SCS currently assumes that if IR's main component is installed, then masterwork weapons are as well. Masterwork weapons are actually part of the Store Revisions component now and only installed if you follow the procedure above. If you'd rather use fine weapons from SCS, you can delete the following from setup-stratagems.tp2 at line 478 before [re]installing SCS: REQUIRE_PREDICATE !(MOD_IS_INSTALLED ~item_rev/item_rev.tp2~ 0) @3376

You're supposed to get an email when you sign up. Clicking the link in the email validates your account. For a while, though, the forum software has been refusing to send emails to certain email providers. Now, we manually authorize a user once they make a post or two that indicates they're not a spambot.

My understanding is that the mod is compatible with regular BG2 and BG2EE.

I can create an official package and update the download center and announcements. I should be able to get it done tomorrow.

Adding columns will have no effect. The table is used by our components to modify weapon stats. We have no code to add AC to weapons or read from an AC column.

The Readme. I replaced the old list of Weapon Changes with a huge table but it had a few typos (e.g. leania didn't noticed but spears too had incorrect dmg, 2d4 instead of 1d8). Speaking of that table, @those who can read it, do you think it's fine as it (e.g. single dmg column - from x to y) or do you think it would look better with multiple columns similar to Revised Shields table (e.g. Old Dmg column and New Dmg column). I think it needs an update to make it easier to compare old versus new values for all stats (damage, speed, attacks per round, THAC0 bonuses) without getting too wordy. Most of the tables need some work to make them nicer to look at. I think enforcing a max-width on them will help. They're all going to get moved to a separate file or maybe some sort of fancy hide/show button to keep the readme clutter down.

Thanks, Jarno, I did a word. Well, kreso's won't work at all because it does something completely different. Let's break down the regular expression. ^.+[^chalhelm || compon05]\.itm$ The interesting parts here are the .+ and [^chalhelm || compon05]. .+ This will match any characters one or more times. It is greedy and will gobble up as many characters as it can, except for characters required to match the remaining parts of the expression. [^chalhelm || compon05] This is a character set. It will match ONE character only. Character sets normally match any character specified within, but because the first character is a ^, it's an indication to match any character that's not specified within. So, what this actually does is find all .itm files with a name that ends in a character that is not a 0, 5, a, c, e, h, l, m, n, o, p, |, or space. Since chalhelm.itm ends with an m and compon05.itm ends with a 5, they are excluded, so it appears that it accomplishes the goal, while it does something very different. It is actually much harder to use regular expressions to find things that don't match a specific string than it is to find things that do match a specific string. Here's a regular expression that matches all strings except chalhelm and the empty string. To get it to match all items other than chalhelm.itm, you would add \.itm right before the ending $. ^([^c].*|c([^h].*)?|ch([^a].*)?|cha([^l].*)?|chal([^h].*)?|chalh([^e].*)?|chalhe([^l].*)?|chalhel([^m].*)?|chalhelm.+)$ There are 9 alternatives and it matches any of them: string that starts with something other than c string that starts with c and is followed by something other than an h or ends string that starts with ch and is followed by something other than an a or ends string that starts with cha and is followed by something other than an l or ends string that starts with chal and is followed by something other than an h or ends string that starts with chalh and is followed by something other than an e or ends string that starts with chalhe and is followed by something other than an l or ends string that starts with chalhel and is followed by something other than an m or ends string that starts with chalhelm and is followed by additional characters Presented above, the regular expression is not in proper WeiDU syntax. For visual clarity, I left out the backslashes for groupings and alternatives. Here is the same expression formatted for WeiDU. ^\([^c].*\|c\([^h].*\)?\|ch\([^a].*\)?\|cha\([^l].*\)?\|chal\([^h].*\)?\|chalh\([^e].*\)?\|chalhe\([^l].*\)?\|chalhel\([^m].*\)?\|chalhelm.+\)$ You will understand why we don't use this method. If this pops up on non-borked files, it's indicative of an error in the patching code. That should be fixed rather than excluding the files it fails on.

Those regular expressions don't do what you think they do. Crev's way is better and it should work. Maybe there is a problem with case sensitivity. Try replacing: PATCH_IF found_dispel=1 && "%SOURCE_RES%" STR_CMP trollreg BEGIN With: PATCH_IF found_dispel=1 && NOT ~%SOURCE_RES%~ STRING_EQUAL_CASE ~trollreg~ && NOT ~%SOURCE_RES%~ STRING_EQUAL_CASE ~cdtorgal~ Edit - with this: PATCH_IF found_dispel=1 && NOT ~%SOURCE_RES%~ STRING_EQUAL_CASE ~trollreg~ && NOT ~%SOURCE_RES%~ STRING_EQUAL_CASE ~cdtorgal~ BEGIN

That sounds like an EE/WeiDU problem rather than an IR bug. IR doesn't do anything fancy here - it uses WeiDU to write the string "Bastard Sword" as the item name. WeiDU looks up "Bastard Sword" in dialog.tlk and puts in the strref it finds. Edit: Actually, this is something you can fix in your mod. Instead of writing your new proficiency string on top of the "Bastard Sword" strref in dialog.tlk, you should assign your string its own strref and update the value stored in weapprof.2da.

To be fair to the author (Ardanis?), the chance of it breaking something was pretty low. If you try to cover every possible exception, you'll never get anything done.

Only with caster levels.