WanderingScholar

I still have this quagmire where I have to switch to WeiDU v249(Legacy) when installing gen-biffing. If you don't use this legacy version you'll have a broken game if infinity animations is biffed.

So, what I end up doing is moving all the setup files out of the main BG2 directory when it's time to install gen-biffing to ensure that the v249(Legacy) doesn't get auto updated somehow.

For some reason, the legacy version doesn't seem to distinguish itself when run inside the BG2 directory which is baffling me.

I get this when I run v249(Legacy) outside the BG2 directory:

But this when I run v249(Legacy) inside: 

Any ideas?

There has to be a safer solution.

Ideally, I'd like to update all the setup files to WeiDU v249(Legacy) so I don't have to make this switch at all. Can I force it to do this? Or maybe prevent the auto updating all together?

4 hours ago, DavidW said:

Feel free to make the case for specific ones to be taken off that list, I haven't gone systematically through it just now (I just happened to recall Vay-ya).

I guess my argument would probably be that single class mages vastly outnumber multi-classed ones throughout the game, so it might be nice for variety sake to preserve the few exceptions that exist. 

I was asking more out of curiosity. 

Thanks anyway. 

It's pretty minor, but do you think you could have the inquisitor dispel magic nerf update the kit description to reflet changes?

For SCS player summoned fiends what is the problem with giving them teleport without error? Why not just use Target([ANYONE]) with an exclusion maybe for Allegiance NUETRAL. That way they'd only teleport to creatures in battle. Then maybe set the range to greater than 15 but less than 50, or something else to keep them from going across the whole map if that's an issue.

In bg1fix.tpa you have the following line:

LAF edit_creature INT_VAR tv=1 STR_VAR creature=~joia sakul vayya naaman cuchol beyn dezkie garan~ tv=1 editstring=~class=>MAGE~ END

These guys are originally fighter/mages or mage/thief.

Cuchol for example is a level 8/8 fighter/mage. He gets changed to a mage, and somewhere else has his level reduced to 7, Thac0 changed to 18...etc

Why not keep them as multiclass? The scripts exist.

Edit: This probably belongs in the pinned v35 questions / comments thread. @DavidW or another mod can move it there.

44 minutes ago, CamDawg said:

Update your WeiDU. It's choking on RESOURCE_CONTAINS, a command added in v247.

I was using v246 because generalized biffing breaks infinity animations with v247+ 

However, according to a recent post by Wisp over at pocketplane, it looks like there's a legacy version of WeiDU v249 that fixes the aforementioned issue, which is great news to me.

So it's all good 

@CamDawg I get the following error when running gen-biff using WeiDU v246. 

Darn it, I should have tested this right away after making the change. I got distracted with something else and assumed I'd found the answer.

I still get a parse error. What on earth is it upset about!?

////////////////////////////// only evil aligned conjurers summon demons //////////////////////////////////////

DEFINE_PATCH_FUNCTION mage_spell_swap_alignment
     INT_VAR level=0
     STR_VAR spells=""
             kit=""
             alignment=""
     RET spells
BEGIN
    TO_LOWER alignment
    PATCH_MATCH ~%alignment%~ WITH lawful_good neutral_good chaotic_good lawful_neutral neutral chaotic_neutral BEGIN
        PATCH_IF (level>13 && ~%kit%~ STRING_EQUAL_CASE conjurer) BEGIN
         LPF substitute_spells STR_VAR spells swap_out=CACOFIEND swap_in=~MORDENKAINENS_SWORD POWER_WORD_STUN~ RET spells=spells END
         LPF substitute_spells STR_VAR spells swap_out=SUMMON_FIEND swap_in=MONSTER_SUMMONING_LEVEL_6 RET spells=spells END
         LPF substitute_spells STR_VAR spells swap_out=GATE swap_in=MONSTER_SUMMONING_LEVEL_9 RET spells=spells END
        END    
    END
END

One END for the PATCH_IF, PATCH_MATCH, and DEFINE_PATCH_FUNCTION.

The whole setup file is filled with functions structured the exact same way.

NVM. The second END needed to be END DEFAULT END. 

Remove ADD_PROJECTILE and use ALTER_SPELL_HEADER. It works perfectly. Sorry for any confusion

ACTION_IF (GAME_IS ~tutu tutu_totsc bg2 tob bgt~ AND NOT GAME_IS ~bgee bg2ee eet iwdee~) BEGIN
    ACTION_FOR_EACH resource IN
      ~spcl722~ // Priest of Talos Lightning Bolt
      ~spdr301~ // Avenger Lightning Bolt
      ~spwi308~ // Lightning Bolt
      ~wand07~  // Wand of Lightning
      ~dvlight~
      ~dvlightb~
    BEGIN
      ACTION_IF (FILE_EXISTS_IN_GAME ~%resource%.spl~) BEGIN
        COPY_EXISTING ~%resource%.spl~ ~override\%resource%.spl~
        PATCH_IF (SOURCE_SIZE > 0x71) BEGIN
          READ_SHORT 0x68 "number_of_headers"
          SET "loop" = 0
          WHILE (%loop% < %number_of_headers%) BEGIN
            LPF ALTER_SPELL_HEADER INT_VAR projectile=40 END
            SET "loop" = %loop% + 1
          END
        END
        BUT_ONLY
      END
    END
  END ELSE...

14 hours ago, Bartimaeus said:

...I didn't bother to check my own preferred install type? Dearie me. The EEs also have LIGHTBLT, but it looks the (previously hard-coded?) reference to it was replaced with LIGHTB. Anyways, it's now been fixed in the latest repository version, thank you!

Lucky I decided to test the new code on a dummy install. If WeiDU rolls back spell revisions on a big install from an error it can bork the whole thing.

I still get an error. 

Just to be clear lightblt.pro does not exist in PROJECTL.IDS on oBG2. Your ADD_PROJECTILE trick will not work.

This is lightning bolt spwi308 projectile on oBG2

So lightblt.pro is definitely the lightning bolt projectile, but I'm guessing this means it's hard coded? I might have given you bad info earlier, that's my mistake.

So I guess what you'll need to do is patch lightning bolts projectile back to this hard coded value?

2 hours ago, Bartimaeus said:

No, this kind of "false adding" a projectile that I know the game already has is my incredibly lazy way of getting weidu to go fetch its ID in projectl.ids for me (as when weidu tries to add a projectile, it first goes and checks to see if it's already in there or not...and if it is, then it skips adding it but helpfully remembers its ID for you so that it can be used for the rest of the installation for anywhere it might be referenced). What game type are you installing SRR to that it doesn't already have lightb.pro? I guess I figured every game type SRR could be installed to would already have lightb.pro, but I must've overlooked something.

I did some investigating. It seems oBG2 uses LIGHTBLT.PRO

2 hours ago, Bartimaeus said:

I pray that nobody has ever learned anything about weidu from following my example: all my work is duct tape and bubblegum, hodgepodge and quackery learned from two seconds of looking at how someone else did something similar-ish once upon a time and spending nary a thought on it further once it works.

Oh, I guarantee mine is worse. It's about as functional as a diseased gibberling. 

ERROR: Unix.Unix_error(20, "stat", "spell_rev\\projectles\\lightb.pro")

@Bartimaeus I think you may have forgotten to add "lightb.pro" to "spell_rev\projectiles" 

26 minutes ago, jmerry said:

Honestly, I don't know that much about two-dimensional arrays - I just know the one setup that I used in the snippet from my mod, with the array and two arguments. Copying a row at a time and then pulling elements of that row - not something I'm sure about. And so, I'm not surprised when the version I posted didn't work.

Oh, wait. I'm pretty sure that should be PHP_EACH rather than FOR_EACH. It's an array we're working with here, not a simple list...

Alternate form, using the exact structure I'm familiar with:

That did the trick finally. It just needed some quotes around the -1 in "PATCH_IF (newprice > -1)" Not sure what I was missing the first time I tried it.

ACTION_PHP_EACH was a no go with the other one. 

Hopefully this will be the last one.

This throws a ERROR locating resource for 'COPY' for ~%row_0%.itm~. Resource [%row_0%.itm] not found in KEY file:

ACTION_FOR_EACH row IN pricelist BEGIN
  OUTER_SET "new_price" = "-1"
  COPY_EXISTING ~%row_0%.itm~ ~override~
    PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN
    SPRINT item_name "%SOURCE_RES%"
    END
    PATCH_IF ("%row_0%" STRING_EQUAL_CASE "%item_name%") THEN BEGIN
    SET new_price = "%row_1%"
    END
    PATCH_IF ("%new_price%" > "-1") THEN BEGIN 
    WRITE_LONG 0x34 ("%new_price%") 
    END
  BUT_ONLY
END

I'm guessing I'm missing something that defines what "row_0" should be before it goes to copy since it doesn't "see" anything.

@jmerry I tried incorporating and adapting the code from your first post in various ways but it didn't get me anywhere, and the WeiDU docs ain't helping. 

I'm just sort of guessing at this point. 

Holy smokes. So I was aware of the distinction between ACTION and PATCH, but for some reason I spaced out when writing this. This is the 3rd iteration of this code I've attempted. 

13 minutes ago, jmerry said:

First, and more minor, your sanity check is basically nullified by ENDing it before you do anything else. If you want to condition your changes on the file being valid, you have to put your changes inside the IF block. Which is probably about the extra END; in retrospect, the END immediately after the IF looks like the one that shouldn't be there.

 Yeah, the reason I added "END // Ends IF block" is because I was getting frustrated and blindly responding to WeiDU errors. Looks like many things were broken anyway. 

16 minutes ago, jmerry said:

Second, your fundamental structure here is O(n^2) in the number of items, when it could be O(n). There are about 3000 items in unmodified BG2EE. Making your code run a thousand times faster is absolutely worth it. What you're currently doing - or at least, trying to do - is to iterate over every item, then compare each item to the entire array of items and do stuff when they match. What you could do instead is iterate over the array and load the item file the current row corresponds to:

Good to know. I wasn't thinking about this. I was just trying to get it to run. 

8 hours ago, jmerry said:

Hopefully, that helps with your second component.

In my example, the table is pre-built; the first column is the resource ID for a given CRE, and the remaining columns are data for that CRE. I also have a header row, which is discarded by the READ_2DA_ENTRIES_NOW because it's shorter.

Thanks a lot for the help @jmerry. I feel like I'm getting close, but I just can't make it over the finish line . It's the first time I'm using most of these commands. WeiDU doesn't like what is happening at PATCH_IF ("%row_0%" STRING_EQUAL_CASE "item_name") THEN BEGIN. I get a GLR Parse Error. This is the hardest thing to figure out. I need to match all the item names in the game with those in every row of first column in pricelist.2da

////////////////////////////////////////////////////////////////////
BEGIN ~Change item prices for IR to their original values~
//REQUIRE_COMPONENT "item_rev.tp2" 0 "This component needs to be installed after Item Revisions"
////////////////////////////////////////////////////////////////////

COPY ~weidu_external/data/WStweaks/pricelist.2da~ ~override~
    READ_2DA_ENTRIES_NOW pricelist 2  // Read the entries in "pricelist". "pricelist.2da" is only 2 columns 
BUT_ONLY

COPY_EXISTING_REGEXP GLOB ~.*\.itm~ ~override~
  PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // only patch if the item file is large enough to have a price field
    READ_LONG 0x34 "price" // read the current price at offset 0x34
    END
    OUTER_SET "new_price" = "-1" // Set the "new_price" to "-1" to check later if it changes
    OUTER_SPRINT "item_name" "%SOURCE_RES%" // Get all the item source names
    ACTION_FOR_EACH row IN pricelist BEGIN 
      PATCH_IF ("%row_0%" STRING_EQUAL_CASE "item_name") THEN BEGIN 
        SET "new_price" = "%row_1%"
      END
    END
    PATCH_IF ("%new_price%" > "-1") THEN BEGIN // check if a new price is specified
      WRITE_LONG 0x34 ("%new_price%") // write the new price at offset 0x34
    END
  END
BUT_ONLY

I'm trying to write a mod that patches the prices of all items in the game. The purpose is to revert the price changes made by the Item Revisions mod. 

The first component is installed before IR. It gathers and stores all the items and their prices into a table. "pricelist.2da" I couldn't think of another way to do this.

The second component, which should be installed after IR, is meant to read pricelist.2da and patch all of the items in the game to match the corresponding prices listed in the table.

I'm struggling to write this second component. I'm assuming I need to use something like READ_2DA_ENTRIES_NOW to get the info out of the table, then store it in a variable to be used in some of loop. I guess I'd have to match the SOURCE_RES of the item with it's SOURCE_RES in the table, then tell it to patch the price value in that same row. 

Any ideas?

////////////////////////////////////////////////////////////////////
BEGIN ~Read in item prices for IR price reversions~
FORBID_COMPONENT "item_rev.tp2" 0 "This component needs to be installed before Item Revisions"
////////////////////////////////////////////////////////////////////

<<<<<<<<.../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
    READ_LONG 0x34 itemprice
    SPRINT data ~%data%%SOURCE_RES%%TAB%%itemprice%%WNL%~
    
APPEND_OUTER ~weidu_external/data/WStweaks/pricelist.2da~ ~%data%~

////////////////////////////////////////////////////////////////////
BEGIN ~Change item prices for IR to their original values~
REQUIRE_COMPONENT "item_rev.tp2" 0 "This component needs to be installed after Item Revisions"
////////////////////////////////////////////////////////////////////

?

25 minutes ago, subtledoctor said:

There is little risk here. Even if it is not an exact match, SAY will just add a new string and set the description to it. Which is fine. The game can handle many thousands of added strings. 

Good to know.

25 minutes ago, subtledoctor said:

But a bigger question is why this is happening in the first place. You speak as if it should be expected, but my installs include hundreds of mods and I see very few mistaken string references. You might want to run “./weidu --change-log spwi694.spl” to find out which kods changed the file. Drop the .SPL files tgat generates into /override and see which one(s) have correct descriptions. Then match up the first broken one to the --change-log output to see which mod broke it. Then you can move toward figuring out how to make an install where this doesn’t happen. 

I also only have a few, but they've been elusive to me for a while and I'd rather just patch them for the time being.  

Can you offer any insight into GET_STRREF?

Can I just do something like this:

COPY_EXISTING ~spwi604.spl~ ~override~
    GET_STRREF 121654 variable      //   correct description at ref# 121654
    SAY IDENTIFIED_DESC ~%variable%~
    BUT_ONLY

In any install with a plethora of mods it always seems like a you get at least a handful of broken dialogue/string references. 

I'm curious what the best practice is for making a mod that patches these. 

As an example, I'll use the spell SPWI604.spl (Flesh to Stone)

In my game the correct description for this modified spell exists but SPWI604.spl has the wrong string ref. for its description. 

Originally, I thought it would be easiest to use LOAD_TRA ~modname\language\something.tra~ to pull the correct descriptions right out of the language files from the original mod folder then use  SAY IDENTIFIED_DESC to patch SPWI604.spl back to it's correct description. 

But what happens when I need to patch files from an assortment of .tra's across different mods? Surely if I load them all in at the beginning of my patch the references are going to get mixed up if two .tra's share the same @#'s. 

I'm also aware that I can use SAY to just write out the full description inside " " and WeiDU will point to the string ref if it's in game or create a new one, but I feel like I might get into trouble if I'm putting things like long spell descriptions in this way. Will everything be oriented correctly in game?

Then I started looking at ACTION_GET_STRREF. So with this, it looks like I can pull an existing ref. right out of the game, store it in a variable, then possibly use SAY IDENTIFIED_DESC "variable" to assign it the correct text?

What's the best way to go about this?

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. 

Hopefully someone can provide some insight to the issue I've had getting the original games to look decent.

My native resolution is 2560 x 1600. For most of my BGT installs I've selected the 1024 x 768 option in BGconfig. I set "Full Panel" in my graphics settings and let the application control DPI.

This gives me a decently wide game window, but of course, has the unfortunate drawback of shrinking the GUI. 

I though I found my solution with @Insomniator's amazing BG2 ImprovedGUI mod.

The component "x2 Scaled Graphics for HD Resolutions (1280x960 and above) -> GUI + Cursor/Tooltips + Main Game Window"  seemed like it might solve the issue...Unfortunately it didn't seem to do anything on previous installs. 

This time I relented and installed the Widescreen mod, which I've avoided because of past problems. I set the X and Y to 1280 and 800 respectively. 

I chose these components for BG2 ImprovedGUI, with the following results:

~BG2IMPROVEDGUI/BG2IMPROVEDGUI.TP2~ #0 #2330 // x2 Scaled Graphics for HD Resolutions (1280x960 and above) -> GUI + Cursor/Tooltips + Main Game Window: 5.6
~BG2IMPROVEDGUI/BG2IMPROVEDGUI.TP2~ #0 #2400 // x2 Scaled Graphics for Widescreen Mod, select only if Widescreen Mod was installed with special half resolution: 5.6

All the menu's now have black bars and the GUI is still completely shrunk 

The only thing I can think of at this point is that there might be a conflict with these components and the 1PP GUI component that's installed before them.

~1PP/1PP.TP2~ #0 #104 // 1ppv4: GUI additions for BGII: v4.2.1

It's the only other mod changing the GUI.

Any thoughts or solutions?

5 minutes ago, jmerry said:

Well, let's start with the obvious surface-level problem: your BEGINs and ENDs don't match. You have two ENDs at the end, where you need three; one for the IF block, one for the MATCH block, and one for the function definition. Judging by your indentation, it's the MATCH block that's missing its END. But when WeiDU goes to parse this, it assigns that second END to the MATCH block, leaving the function definition open, and whatever's next in that document becomes part of the function when it isn't supposed to be, at least until the whole thing collapses in syntax errors that appear to point somewhere far from the actual problem. Or, worse, it runs and does things you weren't expecting at all.

Yep, that would explain why I'm getting errors further down the page. It was really confusing me. Still learning 

I need a function that removes all level 9 arcane spells from creatures with class "caster" and level > 18.  Solved

I've got a bug with my current install that's causing every mage in my game to get a 9th level spell, and unfortunately many of them have the script blocks to cast it. 

The second thing I'm trying to do is substitute out all fiend summoning spells from non-evil conjurers. There's something in the code below that's causing an error. WIZARD_MONSTER_SUMMONING_6 is added with SR. 

////////////////////////////// only evil aligned conjurers summon demons //////////////////////////////////////

DEFINE_PATCH_FUNCTION mage_spell_swap_alignment
     INT_VAR level=0
     STR_VAR spells=""
             kit=""
             alignment=""
     RET spells
BEGIN
    TO_UPPER alignment
    PATCH_MATCH ~%alignment%~ WITH LAWFUL_GOOD NEUTRAL_GOOD CHAOTIC_GOOD LAWFUL_NEUTRAL NEUTRAL CHAOTIC_NEUTRAL BEGIN
     PATCH_IF (level>13 && ~%kit%~ STRING_EQUAL_CASE conjurer) BEGIN
         LPF substitute_spells STR_VAR spells swap_out=CACOFIEND swap_in=~MORDENKAINENS_SWORD WIZARD_POWER_WORD_STUN~ RET spells=spells END
         LPF substitute_spells STR_VAR spells swap_out=SUMMON_FIEND swap_in=WIZARD_MONSTER_SUMMONING_6 RET spells=spells END
         LPF substitute_spells STR_VAR spells swap_out=GATE swap_in=~ABSOLUTE_IMMUNITY WIZARD_SPELL_STRIKE~ RET spells=spells END
     END

END

I run the above function with 

Thanks

On 12/10/2023 at 4:13 AM, jacklhoward said:

Hi.

Could you plz teach me how to change lightning bolts back to its original form?

So I do this by editing "\spell_rev\components\main_component.tpa" before install. I use notepad ++

We comment out all the instances of lightning bolt with /* and */

So that would be:

/*COPY_EXISTING ~newbolt1.pro~ ~override~  // Lightning Bolt's "new" projectile
  WRITE_SHORT 0x0a 30    // 30 speed
  BUT_ONLY_IF_IT_CHANGES*/

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

/* ---------------- Priest of Talos Abilities ---------------- */

COPY ~spell_rev\shared\spcl721.spl~      ~override~  // Storm Shield
  SAY NAME1 @1109    SAY UNIDENTIFIED_DESC @1110
/*COPY ~spell_rev\shared\spcl722.spl~      ~override~  // Lightning Bolt
  SAY NAME1 @515    SAY UNIDENTIFIED_DESC @516*/

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

/* ---------------- Avenger Abilities ---------------- */

COPY ~spell_rev\shared\spdr101.spl~      ~override~  // Chromatic Orb
  SAY NAME1 @433000    SAY UNIDENTIFIED_DESC @434000
ACTION_IF slowing_web=1 BEGIN
COPY ~spell_rev\spalt\spdr201.spl~      ~override~  // Web
  SAY NAME1 @477    SAY UNIDENTIFIED_DESC @478000
END ELSE BEGIN
COPY ~spell_rev\shared\spdr201.spl~      ~override~  // Web
  SAY NAME1 @477    SAY UNIDENTIFIED_DESC @478
END
COPY ~spell_rev\shared\spdr201i.eff~     ~override~
/*COPY ~spell_rev\shared\spdr301.spl~      ~override~  // Lightning Bolt
  SAY NAME1 @515    SAY UNIDENTIFIED_DESC @516*/

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

/*COPY ~spell_rev\spwi3##\spwi308.spl~     ~override~  // Lightning Bolt
  SAY NAME1 @515    SAY UNIDENTIFIED_DESC @516
COPY ~spell_rev\spwi3##\scrl1k.itm~      ~override~
  SAY NAME2 @515    SAY IDENTIFIED_DESC   @516*/

On 12/10/2023 at 4:13 AM, jacklhoward said:

And if you only have SRR, and do not have IRR installed, do you get bouncy lightning bolts for wands and stormstar? if so I would just keep the spell versions as they are from SRR, but use items in later game.

I assume if you exclude IRR and your lightning bolts should be bouncy for items. 

Is there any risk having Near Infinity open when installing WeiDU mods?

I can understand it might be problematic if you were editing files simultaneously, but simply having the editor open shouldn't cause any issues, correct?