Mike1072

If you want the two names to match, I'd take whatever value exists in cowenf2 and write it to mage18a. COPY_EXISTING ~cowenf2.cre~ ~override~ READ_LONG 0x08 name READ_LONG 0x0c tooltip BUT_ONLY COPY_EXISTING ~mage18a.cre~ ~override~ WRITE_LONG 0x08 name WRITE_LONG 0x0c tooltip BUT_ONLY

There are functions that can handle that. LPF ~ADD_ITEM_EQEFFECT~ INT_VAR opcode = 263 target = 1 timing = 2 parameter1 = 1 parameter2 = 1 END

1) I assume you're talking about this tutorial. This code should work for setting the flag to toggle critical hit aversion. COPY_EXISTING_REGEXP GLOB ~^.+\.itm$~ ~override~ // copy all item files PATCH_IF (SOURCE_SIZE > 0x71) BEGIN READ_BYTE 0x31 proficiency // read the byte containing weapon proficiency type PATCH_IF (proficiency == 102) BEGIN // quarterstaff WRITE_BYTE 0x1b (THIS BOR 0b00000010) // set flag for toggle critical hit aversion END END BUT_ONLY_IF_IT_CHANGES However, as far as I'm aware, that flag doesn't have anything to do with backstabs. It has to do with changing whether helmets and other items prevent critical hits or not. You can probably achieve what you want by adding an effect to the items (opcode #263) that sets the wielder's backstab multiplier to x1. 2) For the weapprof.2da patching, it's mostly a matter of keeping track of how you count the rows and columns and the effect of the required column count parameter. We will be using a required column count of 0, which has the effect of starting counting from the first row of the file ("2DA V1.0"). If you wanted to start counting from the first row of data ("LARGE_SWORD..."), you would use a required column count equal to the number of columns in the largest row (determined by performing COUNT_COLS). Here is your code with just the values fixed. COPY_EXISTING ~weapprof.2da~ override COUNT_2DA_COLS cols FOR (col = 4; col < cols; ++col) BEGIN READ_2DA_ENTRY 34 col 0 val PATCH_IF (val == 3) BEGIN SET_2DA_ENTRY 34 col 0 2 END END This method can be slow if you are performing a large number of operations dealing with a large file, since each call to READ_2DA_ENTRY and SET_2DA_ENTRY involves parsing the text. To avoid this, you can instead use READ_2DA_ENTRIES_NOW and SET_2DA_ENTRIES_LATER, which perform all the reads at once and all the sets at once. COPY_EXISTING ~weapprof.2da~ override COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW r2en_weapprof 0 FOR (col = 4; col < cols; ++col) BEGIN READ_2DA_ENTRY_FORMER r2en_weapprof 34 col val PATCH_IF (val == 3) BEGIN SET_2DA_ENTRY_LATER s2el_weapprof 34 col 2 END END SET_2DA_ENTRIES_NOW s2el_weapprof 0

Yes, RING40 is the Reaching Ring with IR.

The main reason the files in this thread aren't on GitHub is because kreso hadn't worked out all the kinks yet. There's a warning in the first post that if you're not playing on EE, some spells might cause the game to crash. If you go ahead and install this on a non-EE game, you're accepting that risk and offering to act as a tester to report any such errors. Beta 14, the latest official release, shouldn't have those problems. It can be found in the pinned thread titled SR v4 Open Beta (last update 25 December 2016).

I suspect morningstars being in the heavy category is intentional. I added the component in v2 and it originally only had bastard swords, katanas, and flails as heavy weapons and daggers, short swords, wakizashis, ninja-tos, and clubs as light weapons. It looks like some changes were introduced around v3 (this was when I was away and Ardanis coded a bunch of stuff). Battleaxes and morningstars were added to the heavy category, and handaxes were added to the light category. Two of those additions were listed in the readme, but morningstars weren't. These quotes contain some evidence that the change to morningstars was intentional and it is the readme that is currently incorrect.

I suspect the crash may be caused by a dream script instead of the spell. To truly rule out SR, you could take the version of spwi401.spl from SR's backup\0 folder and place it in the override folder. That will revert the spell to the previous version. If you still get a crash when resting after doing that, it's probably not because of the spell itself. I'm not sure how best to go about tracking down dream script issues, but I would start with looking up the scripts for the NPCs in your party in pdialog.2da.

Nobody likes being told this.

I don't think there's any incompatibility with those components from Tweaks Anthology. As far as I can tell, they just make the recipes that are available in ToB available in SoA and vice versa. They aren't adding any new items. With regard to something like Item Upgrade, which adds brand new items, there may be conceptual compatibility issues but there shouldn't be any technical ones. (If there's a recipe that requires item A and item B, and you have IR's versions of item A and item B, it would still create the upgrade. However, the upgraded item's lore and abilities would be based on the vanilla versions of item A and item B, so you might find that odd.)

Maybe try a COPY - instead of COPY?

Thanks for the feedback. Even if it sometimes seems like maintainers are on a permanent vacation, we appreciate the info you provide, and having it written down lets us refer back to it later.

So, if you wanted, you could store your template file in a variable and perform your REPLACE_TEXTUALLY statements using INNER_PATCH. You could also use an inlined template file and COPY - statements to do REPLACE_TEXTUALLY, which should also keep everything in-memory. (Probably what I would suggest.) As a third option, you could avoid REPLACE_TEXTUALLY and just assemble your files by concatenating variables.

INNER_PATCH lets you perform patch operations within its scope. Patch operations are normally done in the context of the current file that you are modifying (e.g. in a COPY action). Patch statements let you do things like READ_* and WRITE_*, INSERT_BYTES, REPLACE_TEXTUALLY and REPLACE_EVALUATE. With INNER_PATCH, instead of performing these operations on the current file, they are performed on whatever string you provide. INNER_PATCH ~1234567890~ BEGIN READ_ASCII 0x00 numbers (5) END PATCH_PRINT ~%numbers%~ This READ_ASCII operation behaves as though it is dealing with a text file that has as its contents "1234567890". It reads five characters from the start of the file and stores them in a variable for use later. The PATCH_PRINT statement should print out "12345". The difference between INNER_PATCH and INNER_PATCH_SAVE is that any changes you make to the "file" in an INNER_PATCH are completely discarded. With INNER_PATCH_SAVE, you can store those changes back into a variable. INNER_PATCH_SAVE results ~1234567890~ BEGIN WRITE_ASCII 0x00 ~33333~ #5 END PATCH_PRINT ~%results%~ Here, the changes we make to the "file" that originally contained "1234567890" get stored into a variable named results. The PATCH_PRINT statement should print out "3333367890". Instead of providing the static string "1234567890" to the command, we can provide the contents of a variable. READ_STRREF UNIDENTIFIED_DESC description INNER_PATCH_SAVE new_description ~%description%~ BEGIN REPLACE_TEXTUALLY CASE_SENSITIVE ~armor~ ~armour~ REPLACE_TEXTUALLY CASE_SENSITIVE ~Armor~ ~Armour~ END SAY_EVALUATED UNIDENTIFIED_DESC ~%new_description%~ In this example, we read the unidentified description of an item or spell into a variable named description. Then, we initiate an INNER_PATCH on the contents of that variable and save the changes into a variable named new_description. Our modifications are to change the spelling of armor wherever it appears. Once we are done, we write our new description back to the item or spell file. Addendum: There is also OUTER_PATCH, which functions the same as INNER_PATCH. The difference is that you use INNER_PATCH when you are already within a patch (e.g. COPYing a file), and you use OUTER_PATCH when you aren't. It's the same as using PATCH_PRINT and PRINT.

I'm not sure if I'm following exactly what you're trying to do, but there's probably a way to do it that minimizes usage of the file system, either with inlined files or variables. You can use OUTER_PATCH_SAVE/INNER_PATCH_SAVE on a variable to treat it like a file if you need to do REPLACE_TEXTUALLY or something.

There's a slight difference between the original games and the enhanced editions. The original games match up the UNUSABLE column in kitlist.2da with the identifiers in kit.ids, while the enhanced editions match up the KITIDS column in kitlist.2da with the identifiers in kit.ids. So, you'll need to read from column 7 of kitlist.2da for the original games and from column 9 for the enhanced editions. Here's how you'd do it on the original game. COPY_EXISTING ~kitlist.2da~ ~override~ COUNT_2DA_COLS cols READ_2DA_ENTRIES_NOW ~r2en_kitlist~ cols FOR (row = 1; row < r2en_kitlist; row += 1) BEGIN READ_2DA_ENTRY_FORMER ~r2en_kitlist~ row 7 kitids_num LOOKUP_IDS_SYMBOL_OF_INT identifier ~kit~ kitids_num SPRINT $d5_kits_profs(~%kitids_num%~) ~%prof_col%~ SPRINT $d5_kits_ids(~%kitids_num%~) ~%identifier%~ END BUT_ONLYI saved the identifier in an array but you can do whatever you want with it. Note that there might not be an entry in kit.ids in the original games for WILDMAGE.

It's not that hard from a technical perspective. Usually artistic ability is the limiting factor. The only slightly tricky thing is that BAM files use a palette, like GIFs. The basic process is: export frames from BAM to a more standard format (e.g. BMP, PNG, GIF), edit them in your favourite editor, then reassemble them back into a BAM. You can use a tool like BAM Workshop or BAM Workshop II to do this. I believe the original BAM Workshop is generally more reliable. Here are some detailed notes from a more knowledgeable authority:

I think they got it, Jarno.

To clarify, the bonus will be applied, but it won't be listed on the character sheet.

For #3, you could make global replacements using ALTER_TLK or ALTER_TLK_RANGE. Global replacements aren't really very common, though. What are you trying to do?

Your best bet would be to remove the files for the half-elf paperdolls from the override folder (CE*INV.BAM and CE*INV.PLT), which would revert them to the BGEE versions and hope that fixes them. The animations and paperdolls for particular items (e.g. shields) can be altered by loading the .itm and changing the value at 0x22 (item animation).

I think you just discovered a particular description that has a bad character in it. I searched the text from the screenshot you posted in the other thread and that description (@626 in arcane.tra) has a bad apostrophe in it. If you notice any similar issues, post them here. If you want to fix the spell's description in your current game, you can load the spell with Near Infinity and use the dialog.tlk editor to replace the apostrophe.

The new opcodes probably snuck in with kreso's other changes and he can fix them. Nothing to worry about.

Awesome. I checked my old PC and could only find weird dev versions.

Are you playing on one of the Enhanced Editions? EET? Or regular BG2/BGT/Tutu? And do you have 1PPv4 installed?

Ashes of Embers was out of date long before the EEs were released.