IR Revised V1.3.800 (2022 January 11th)

[WanderingScholar]

Is there an easy way to revert the price changes done by item revisions? Maybe some code I can add to the setup files so I don't have to manually change the price of tons of items?

The "Sensible Prices" really aren't very sensible in many ways. The original prices were batter balanced around the amount of gold you got in the game.

When playing BGT, for example, you can get access to full plate almost right out of the gate since it's only 1000gp at the Thunderhammer Smithy.

[Bartimaeus]

10 hours ago, WanderingScholar said:

Is there an easy way to revert the price changes done by item revisions? Maybe some code I can add to the setup files so I don't have to manually change the price of tons of items?

The "Sensible Prices" really aren't very sensible in many ways. The original prices were batter balanced around the amount of gold you got in the game.

When playing BGT, for example, you can get access to full plate almost right out of the gate since it's only 1000gp at the Thunderhammer Smithy.

No, it's not possible: those price changes are all baked into the .itm files. On a side-note, Demivrgvs balanced IR around BG2, not BG1, which has historically created a few rather unfortunate issues for BG1. You don't sell a lot of full plate mail in BG1, but you sure do in BG2, so it was no doubt the intent to make the economy a little less easy. And on a side-note to the side-note, AD&D's standard price for plate mail was 400 GP, which is actually 100 GP less than IR's 500...but its price for full plate mail is listed as a minimum of 4,000 and as much as 10,000, and IR's is only 1,000.

The economy is these games is a bit crude, and the differences in the availability of magical items between BG1 and BG2 makes it even tougher to strike a good balance.

[pochesun]

I have a suggestion: is it possible to place Runehammer somewhere in BG1? I know it was a possesion of Bassilus before but then it was swapped for another hammer due to balance reasoning. I agree that Runehammer is overpowered for early and mid BG1 but very late BG 1 and, whats more important, the whole SoD its a very appropriate and fun weapon to play with. Since you can carry your equipment into SoD i was thinking that maybe its reasonable to place Runehammer somewhere just before Sarevok fight?

[Bartimaeus]

5 hours ago, pochesun said:

I have a suggestion: is it possible to place Runehammer somewhere in BG1? I know it was a possesion of Bassilus before but then it was swapped for another hammer due to balance reasoning. I agree that Runehammer is overpowered for early and mid BG1 but very late BG 1 and, whats more important, the whole SoD its a very appropriate and fun weapon to play with. Since you can carry your equipment into SoD i was thinking that maybe its reasonable to place Runehammer somewhere just before Sarevok fight?

If I'm not mistaken, Ashideena is the only better than +1 war hammer throughout BG1 and even TotSC, so I don't think it'd be entirely amiss to place Rift Hammer somewhere...either pretty close to the end on a named character, or maybe in Durlag's Tower. I've put it on the list, though I'm open to suggestions as well.

Edited December 16, 2023 by Bartimaeus

[WanderingScholar]

I've been thinking about how to design a component that keeps the original prices for items. 

What I think you'd need to do is read and store the price values of all .itm files in the game at the time of install. The initialization. Then when the new items are copied over have a patch option that matches and writes those stored values into the price offsets for each corresponding item. This should allow for max compatibility with any mod that changes prices before install. 

I wish I could write this component but it's beyond my current abilities. 

[pochesun]

On 12/17/2023 at 3:02 AM, Bartimaeus said:

If I'm not mistaken, Ashideena is the only better than +1 war hammer throughout BG1 and even TotSC, so I don't think it'd be entirely amiss to place Rift Hammer somewhere...either pretty close to the end on a named character, or maybe in Durlag's Tower. I've put it on the list, though I'm open to suggestions as well.

Thats great, I will be super thrilled to see Runehammer in SoD. Besides most SoD battles are grounded on throngs of small and mid creatures rushing headlong towards you (Runehammer obviously often usefull against them) there are 2 battles where Runehammer would be part of great strategy: one i like especially -  in the dungeoun prison against boss who summoned multiple mages and one strategy would be to use Runehammer not to kill them but trigger the miscast/deafening debuff with Runehammer to make those mages way less dangerous. With Runehammer its actually possible for a complete non mage party (!) to win that battle.

Edited December 20, 2023 by pochesun

[WanderingScholar]

Sorry if this seems rather pedantic, but I just wanted to clarify something.

I was looking at Leonardo Watson's Big World Project mod install guide, which he recently updated, when I came upon this:

He has component 210, 300, and 301 of 1pp listed to be installed immediately after Item Revisions (main).

This departs somewhat from your recommended install order. 

[Bartimaeus]

1 hour ago, WanderingScholar said:

Sorry if this seems rather pedantic, but I just wanted to clarify something.

I was looking at Leonardo Watson's Big World Project mod install guide, which he recently updated, when I came upon this:

He has component 210, 300, and 301 of 1pp listed to be installed immediately after Item Revisions (main).

This departs somewhat from your recommended install order. 

My order is correct: if I had to guess, The Big World Project could possibly be in a bind there, wherein what it's saying is most likely tailored for the official version of IR, not IRR, and it can't move around where to install 1pp depending on which you're installing when both IR and IRR share the same install name and components. That's not really BWP's fault if that's the case. The way IRR is setup these days (and has been for several years now) is that its base .itm files have been all stripped of any EE/1pp content and reverted back to their default oBG2 appearances, but during installation, a series of checks are made to detect what 1pp/EE content your game currently has installed. If you're playing on an EE game, all checks will pass and all graphical customizations will then be patched into those .itm files; if you're playing on a 1pp game, then only whatever graphical customizations that you chose to install will pass and thus only that content will be patched in; if you're playing on a non-1pp, non-EE, vanilla oBG2 game, then all of its IRR's .itms will stay pretty much their vanilla oBG2 appearances. I pray that nobody is playing with IRR that way, but the capacity to do so is there.

Long story short, the main component of IRR should only be installed after everything you want from 1pp is already installed (with the exception of the Avatar Switching component, which should only be installed after all item-adding/altering mods have been installed) so that those checks will pass and IRR can fully and correctly patch its .itms. If you install IRR's main component before 1pp, then IRR will not ever have the opportunity to patch its .itms, and instead everything is left up to 1pp, which was not ever intended to be installed on top of IR and will lead to a number of incongruities. Probably not anything game-breaking, but some items will definitely not look as they should. How much that'll bother the player will depend on the player in question - anyone who is bothered should use my suggested install order, as that's really the only fix for it. It took a rather ludicrous amount of work to make everything work this way, and it was literally what I was told I'd need to do by Gwendolyn, the maintainer of 1pp, so I don't think there's much I can do about other people's install guides or automated installers being suboptimal, except to suggest that they should be amended where possible.

Edited January 26 by Bartimaeus

[WanderingScholar]

@Bartimaeus

Some time ago I made a comment about retaining the original prices on items because IR has its balance designed around BG2 and not BGT. 

If you ever want to create a .ini option so others can have this, here is the relevant code:

(Credit to jmerry for help on this)

This first block will have to go before any items are copied over. All you have to do is adjust some of the paths.

Spoiler

// Create a table with all item resource names in the 1st column and their prices in the 2nd

<<<<<<<<.../WStweaks-inline/pricelist.2da
>>>>>>>>
MKDIR ~weidu_external/data/WStweaks~
COPY ~.../WStweaks-inline/pricelist.2da~ ~weidu_external/data/WStweaks~

OUTER_SPRINT data ~~
COPY_EXISTING_REGEXP - ~.*\.itm~ nowhere
    PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN
        READ_LONG 0x34 itemprice
        SPRINT data ~%data%%SOURCE_RES%%TAB%%itemprice%%WNL%~
    END
APPEND_OUTER ~weidu_external/data/WStweaks/pricelist.2da~ ~%data%~

This second block goes after all the copies are made, so at or near the end of the main component.

Spoiler

// Read the data in from pricelist.2da and change item prices back to their original values

COPY ~weidu_external/data/WStweaks/pricelist.2da~ ~override~
 READ_2DA_ENTRIES_NOW ~pricelist~ 2
BUT_ONLY

OUTER_FOR (row = 0; row < pricelist; ++row) BEGIN
    OUTER_SPRINT FileID $pricelist(~%row%~ ~0~) 
    COPY_EXISTING ~%FileID%.itm~ ~override~
        PATCH_IF (SOURCE_SIZE > 0x71) BEGIN 
            SET newprice = $pricelist(~%row%~ ~1~)
            PATCH_IF (newprice > "-1") BEGIN
                WRITE_LONG 0x34 newprice
            END 
        END
    BUT_ONLY IF_EXISTS 
END

Once again, make sure the paths are correct.

Edited January 28 by WanderingScholar

[Bartimaeus]

22 hours ago, WanderingScholar said:

@Bartimaeus

Some time ago I made a comment about retaining the original prices on items because IR has its balance designed around BG2 and not BGT. 

If you ever want to create a .ini option so others can have this, here is the relevant code:

(Credit to jmerry for help on this)

This first block will have to go before any items are copied over. All you have to do is adjust some of the paths.

  Hide contents

// Create a table with all item resource names in the 1st column and their prices in the 2nd

<<<<<<<<.../WStweaks-inline/pricelist.2da
>>>>>>>>
MKDIR ~weidu_external/data/WStweaks~
COPY ~.../WStweaks-inline/pricelist.2da~ ~weidu_external/data/WStweaks~

OUTER_SPRINT data ~~
COPY_EXISTING_REGEXP - ~.*\.itm~ nowhere
    PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN
        READ_LONG 0x34 itemprice
        SPRINT data ~%data%%SOURCE_RES%%TAB%%itemprice%%WNL%~
    END
APPEND_OUTER ~weidu_external/data/WStweaks/pricelist.2da~ ~%data%~

This second block goes after all the copies are made, so at or near the end of the main component.

  Hide contents

// Read the data in from pricelist.2da and change item prices back to their original values

COPY ~weidu_external/data/WStweaks/pricelist.2da~ ~override~
 READ_2DA_ENTRIES_NOW ~pricelist~ 2
BUT_ONLY

OUTER_FOR (row = 0; row < pricelist; ++row) BEGIN
    OUTER_SPRINT FileID $pricelist(~%row%~ ~0~) 
    COPY_EXISTING ~%FileID%.itm~ ~override~
        PATCH_IF (SOURCE_SIZE > 0x71) BEGIN 
            SET newprice = $pricelist(~%row%~ ~1~)
            PATCH_IF (newprice > "-1") BEGIN
                WRITE_LONG 0x34 newprice
            END 
        END
    BUT_ONLY IF_EXISTS 
END

Once again, make sure the paths are correct.

Thanks: I want something a little more fine-tuned, but the idea definitely has merit. Ideally, I would like to have a secondary and re-installable component that allows the player to switch the values of items between BG1 and BG2, so that if one is playing BGT/EET, they could patch all their .itms as they progress from BG1 to BG2 on the fly. The technical implementation here would actually be very helpful for accomplishing this, as you could slightly modify it to print out the values of your items - once before all the .itms are overwritten, and once after - and compare and contrast those lists to see the discrepancies and figure out what needs to be BG1-ized, and then you could make two different pre-generated .2das, one for BG1 and one for BG2, and allow the player to patch their .itms according to the values of either lists.

At the moment, that idea is a little pie-in-the-sky given that I can't even find the time to finish the masterwork component, but...maybe eventually.

Edited January 29 by Bartimaeus

[MikeX]

@Bartimaeus

IR(R?) installs on a BGT game OHSW1H55.ITM (appears to be unused) and SW1H54.ITM with EE only Opcode 319.

[Bartimaeus]

1 hour ago, MikeX said:

@Bartimaeus

IR(R?) installs on a BGT game OHSW1H55.ITM (appears to be unused) and SW1H54.ITM with EE only Opcode 319.

The first one makes sense, since it's an EE-only item and I just over-looked it when transferring it over to IRR; the second one is the Equalizer. The last commit that I made to SW1H54.itm says "The Equalizer was usable by alignments it specifically mentioned as being denied to". The official IR description says "not usable by Lawful Good, Lawful Evil, Chaotic Good, Chaotic Evil"; the IRR description instead says it requires any kind of "neutral" alignment, which although different wording, should mean the same thing. Official IR's The Equalizer allows all alignments (including the supposedly barred Lawful/Chaotic Good/Evil) to use it, which I corrected for with the IRR version, but then I also added these 319s on top of that? I'm not certain why, especially because they're type 10 319s (restrict by character name?) and don't seem to actually reference anything. I'm a bit at a loss for what I was trying to accomplish here with these 319s...perhaps it was just left-over and unnoticed cruft from when I was trying to figure out how best to enforce the alignment restrictions? Regardless, thank you, I've fixed both swords!

Edited March 14 by Bartimaeus

[MikeX]

@Bartimaeus

Thank you!

[DrAzTiK]

Just an idea but I think it could be interesting to add a,n(optional) component allowing to remove the immunity to magical weapons of monsters.  The reason is that especially in BG2, I find that most of +1 and +2 weapons become rapidly unappealing coz you ofen face some monsters immune to it. It often takes some rounds to notice it (loosing some precious ApR) , then you are are forced to micromanage your melee weapons... and so eventually you  just end up selling all your +1 and + 2 weapons... 

This natural immunity to magical weapons  of monsters may have some sense in the lore of D&D but in practise (as always) it  make gameplay just borring

 

cheer

Edited April 3 by DrAzTiK

[Bartimaeus]

20 hours ago, DrAzTiK said:

Just an idea but I think it could be interesting to add a,n(optional) component allowing to remove the immunity to magical weapons of monsters.  The reason is that especially in BG2, I find that most of +1 and +2 weapons become rapidly unappealing coz you ofen face some monsters immune to it. It often takes some rounds to notice it (loosing some precious ApR) , then you are are forced to micromanage your melee weapons... and so eventually you  just end up selling all your +1 and + 2 weapons... 

This natural immunity to magical weapons  of monsters may have some sense in the lore of D&D but in practise (as always) it  make gameplay just borring

 

cheer

It's not something really particularly suited to the domain of IR, but I could see throwing a tweak like that into my bart_tweaks. I don't think the player is ever given any options for immunity to magical weapons of a certain enchantment level - there's immunity to non-magical weapons aplenty, but your only options for immunity to magical weapons come in blanket varieties a la PfMW and Absolute Immunity. Making enemies have to abide by the same limitations is not a bad one, and I don't believe it'd be too difficult to code.

(e): Oh, except for the Tear of Fear? Hmm...

Edited April 4 by Bartimaeus