Mike1072

For all estimates, just keep in mind that Demi is a very optimistic guy.

Since v3 beta 1.6 (17 December 2011), IR's main component avoids changing any cursed items if Salk's Cursed Item Revisions mod has been installed. So, if you want Salk's Cursed Items, you can get them by installing that mod before IR.

Not likely. Once it's ready, it will just be officially released. Demi can provide access to the current version if you want to beta test.

I'd wager that the icons are normal. It looks like a usability problem.

Which shield has the wrong icon?

Never heard of this bug before...is anyone else experiencing it? o.O What game is Baptor using? Playing on BGEE, I have noticed a few cases where spells display incorrect strings. BGEE doesn't share the exact same .tlk as BG2, so we will have to change some of the places to not use hardcoded string references.

Credit for that goes to Ardanis.

I forgot... change-log: Mods affecting POTN11.SPL: 00000: ~ITEM_REV/ITEM_REV.TP2~ 0 1300 // Shields Can Bash: V4 Beta 3 That is interesting. I took a brief look at the code and there is some stuff that inserts bytes and updates offsets; there may be a bug causing it to corrupt some files. I'll leave this for Ardanis to investigate.

That's a similar error message, but it's a different bug. In this case, 1PP is assuming the file has 4 effects, like it does in vanilla, but it doesn't anymore. 1PP should use a loop to alter each effect, so that it will work regardless of the number of effects. 1pp/install/114_effects.tph Current Code ADD_PROJECTILE ~1pp/core/1ppv4_pro/1PINCIND.PRO~ ACTION_IF (FILE_EXISTS_IN_GAME ~SPWI810.SPL~) THEN BEGIN COPY_EXISTING ~SPWI810.SPL~ ~override~ PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // protects against invalid files WRITE_SHORT 0x98 ~%1PINCIND%~ WRITE_SHORT 0xc0 ~%1PINCIND%~ WRITE_SHORT 0x110 ~%1PINCIND%~ WRITE_SHORT 0x138 ~%1PINCIND%~ END BUT_ONLY_IF_IT_CHANGES END Looping Code ADD_PROJECTILE ~1pp/core/1ppv4_pro/1PINCIND.PRO~ ACTION_IF (FILE_EXISTS_IN_GAME ~SPWI810.SPL~) THEN BEGIN COPY_EXISTING ~SPWI810.SPL~ ~override~ PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // protects against invalid files READ_LONG 0x64 abilities_off READ_SHORT 0x68 num_abilities FOR (i = 0; i < num_abilities; i += 1) BEGIN WRITE_SHORT (abilities_off + 0x28*i + 0x26) 1PINCIND END END BUT_ONLY_IF_IT_CHANGES ENDI believe there are other patches in this component and other 1PP components that have similar issues.

You can try asking in the GemRB forum. You will probably get a better response if you add punctuation to your posts.

We work on mods when we have the time, energy, and desire, and for me, that's just not happening right now. It's hard to say when the modding bug will strike. Similarly, it's been quite some time since I last played an IE game. If I recall correctly, my IR to-do list consists of: Research known/suspected mod compatibility issues for IR (and possibly SR). Mainly 1PP and BGT/Tutu/BG(2?)EE. Fix any easily fixed compatibility issues and update readme with compatibility recommendations Confirm everything else is ready to go with Demi and Ardanis Package and release the mod Now #4 is relatively simple enough, but #1 and #2 are the things that will make the release actually successful.

Are you using BGEE?

For Item Revisions Arda uploaded his final version more or less a week ago and we only needed to prepare the readme, package everything and upload it, but this time around it was Mike's turn to be uber busy with RL stuff. Keep in mind there are some other things I need to look at as well - providing a recommendation on 1PPv4 compatibility will probably require investigating the code in 1PP.

Both do.

I think the standard behaviour of rods should be that they are activated from the quick item slots like wands. It doesn't seem like rods are intended to function as a weapon type: the majority of them cannot be equipped as weapons. So, it doesn't seem like we could reasonably extrapolate weapon characteristics from their shared qualities. Out of the two rods that can be wielded as weapons, the Rod of Terror's description says "When activated this rod may be used as a staff +3". This activation step seems like something they glossed over to save trouble. The Rod of Smiting description states that it is a long rod which can be used as a staff. In 4th edition, the Rod of Smiting is a rod that can also be wielded as a mace. I think the concept is that it's a unique rod whose special property is that it can be wielded as a weapon. I'd prefer that the Rod of Terror be changed to function like the other rods so this uniqueness is highlighted. I don't think either rod needs to be changed into a club based on these descriptions.

Does the "Special" parameter for opcode 319 refer to the field at 0x2c Avenger described as Param 2.5? Is the list of IDS files that can be referenced by this and other opcodes increased at all? Referencing kit.ids would be nice. To make sure I understand "Spell level set to 1 means only usable by", let's say there was an effect that specified Param2=7 (GENDER.IDS) and Param1=2 (FEMALE). With spell level set to 1, it would prevent non-female characters from using the item, but with spell level set to something else, it would prevent female characters from using it? Is there anything that could make an item usable by a kit but not its parent class?

That is the part that can be easily automated. This code copies all shields that use the c4 animation from the item_rev/itm folder into an item_rev/output folder, giving them the c2 animation. MKDIR ~item_rev/output~ // create a new folder called output ACTION_BASH_FOR ~item_rev/itm~ ~.+\.itm~ BEGIN // for every .itm file in the item_rev/itm folder... COPY ~%BASH_FOR_FILESPEC%~ ~item_rev/output~ // copy that file to the output folder PATCH_IF (SHORT_AT 0x1c == 0x0c) BEGIN // if item is a shield READ_ASCII 0x22 animation (2) PATCH_IF (~%animation%~ STRING_EQUAL_CASE ~c4~) BEGIN // if animation was "c4" WRITE_ASCII 0x22 ~c2~ #2 // make it "c2" END END BUT_ONLY // only copy the files that changed as a result END You throw this in a standalone mod, install it, then copy the files it outputs before uninstalling it.

Heh, talk about OP.

The list of all proficiencies shouldn't be affected by which proficiencies are available to divine casters. If you're concerned about the component in BG2 Tweaks that groups multiple proficiencies into BG1 weapon groupings, I just tested it. That component doesn't create new proficiencies; it renames old ones. Fighters gain proficiency in categories that no longer exist, but these don't even show up on the character sheet, so it seems to work fine.

Yeah. Replace this: /* LAF ~GET_KIT_STRREF~ STR_VAR kit_name = ~monk~ RET kit_strref END STRING_SET_EVALUATE kit_strref @6 // Monk description */ STRING_SET ~45867~ @6 // Fighter description With this: OUTER_SET monk_strref = 45867 ACTION_IF (GAME_IS ~bgee~) BEGIN OUTER_SET monk_strref = 24234 END STRING_SET_EVALUATE monk_strref @6 // Monk description

I can't comment on this specific issue, but in general, if your game is installed in the Program Files directory (and your OS is Windows Vista or newer), mod installations are a lot less reliable. The OS sometimes (silently) redirects changed files to a different directory, leaving the ones used by the game unmodified. There might be a setting that disables this behaviour, but it's easiest just to advise installing the game somewhere else. Many of the changes in mods like SR and IR are based on community feedback. I know Demi would appreciate hearing your ideas. We have a Modding Q&A forum designed just for this sort of thing. Ask away.

Fixed for the next beta. Perhaps because it's a true fighter's advantage. You won't see "cannot use scrolls, scribe spells, Turn Undead etc." here also. I don't think this is needed. It is a problem that some abilities given to kits are only described in the true fighter section, and it seems we need to make it more clear which base class features are inherited and which are not. The current descriptions are nearing the character limit allowed, so unfortunately there is not a lot of wiggle room to paste lots of text in. Not a problem. If you mean it gets no 9th level upgrade I fixed it early this morning sorry. The 3rd Cleave should work instead, Arda tested it in-game and it worked. I'll double check. Edit: found the problem in the clab file. Fixed. I'll probably upload a new beta after lunch. Yeah, this was one of the wonky things I noticed in the CLAB files. I'd recommend double-checking all of them at some point. Not on my install. Very strange, I'll make sure it will. P.S We should probably split the discussion and keep here just bug/issue reports, with a separate topic for feedback. Quoted for preservation after split.

Try now. Also, I did some stuff that might have solved the BGEE problem that was reported, so let me know if it worked.

Seems to work here.

The base game should not be installed within Program Files. The expansion should be installed wherever the base game is.