Mike1072

Yes, SCS is aware of SR and takes advantage of some of its changes. But from the other perspective, both SR and IR were designed with SCS compatibility in mind.

Agreed. It was only done the other way because that was a simpler regexp. (And I was quite concerned about being able to detect newlines properly.) I'm unlikely to spend significant efforts maintaining a version of the mod that works on both the original games and enhanced editions much longer. It takes too much time, makes the mod much more complicated, and restricts the mod to only include things that work on both platforms. If an EE-specific version was created someday, the description formatting would likely be changed to blend in more with the EE style. If you include them in there with the appropriate value for their shield or armor type, you shouldn't need to do anything else. to That can probably be done by changing @100313 in description_updates.tra. That's getting more complicated and may be better suited to a new topic in Modding Q&A. Essentially you'd want to use a REPLACE_TEXTUALLY on the description, finding a line that starts with "– Armor Class:" followed by a line starting with "Special:" and replace the newline in between them. It would involve a regexp similar to the one in my previous post.

It likely has to do with the encoding of the file and the attempted conversion to Unicode performed by HANDLE_CHARSETS. Because the description-updating code is supposed to work on both the original and enhanced editions, it might be better to leave it as is and add the dash in a separate step, executed only for enhanced edition games. Then, you could ensure the en dash was in a file that was encoded in UTF-8 already and that file could be added to the list of files ignored by HANDLE_CHARSETS. Adjusting the position of the THAC0 line is a little tricky but not too bad. Swap the position of this code that cleans up the Special line with this code that adds the THAC0 line (to make it easier to match the line), then adjust the regexp that finds the Armor Class line @100319 so it includes an optional grouping for the Special line at the end: @100319 = ~\(Armor Class\([ %tab%]*Bonus[ %tab%]*\)?:.*\(%MNL%?%LNL%Special: \+[0-9]+ vs\. Missile Weapons\)?\)~ While doing some testing, I noticed the enhanced editions changed the way that the special line is formatted. If you were to install the revised shields component on vanilla EE (without IR's main component), the special line would get wiped out unintentionally. Something I should consider fixing at some point.

WeiDU is not a separate program that you have to use; it's included in every mod. Each .exe file prefixed with "setup-" is an instance of WeiDU.

This topic is about an extension for Visual Studio Code. Visual Studio Code is a free program that is completely separate from Visual Studio. Yes, it's a little confusing. VS Code is a fast and lightweight source code editor that's been around for about 5 years, while Visual Studio is a slower and more full-featured IDE that's been around for over 20 years. There is a free version of Visual Studio (the Community edition) which has almost all the features as the paid versions. If you were looking to get into programming, or game development with Unity, I would recommend the Community edition of Visual Studio. For Infinity Engine modding, VS Code with this extension is more appropriate.

For any modders out there who haven't given VS Code a try with this extension, I highly recommend it. It has all the benefits of the old syntax highlighter packages and then some. Along with the specific IE modding support provided by the extension, you also gain some nice features from VS Code itself: explorer and search for quickly navigating between files in your mod source control support, including comparing changes with side-by-side diffs in the editor terminal window which you can use to interact with git lots of configuration options, extensions, and community support

Demi introduced it here.

G3 is proud to introduce The Cowled Menace, a quest mod by @Daxtreme! Someone has been working in the shadows, manipulating events on the Sword Coast to their advantage. Unravel the mysteries of the Twisted Rune and investigate the Cowled Wizards in this Enhanced Edition Trilogy mod! IMPORTANT: This mod requires EET. Download Project Page Readme Forum

Nope.

@Bartimaeus @subtledoctor I've released a new SCS version with those changes. Hopefully that will resolve the issues.

A minor update to SCS has been released, Version 32.8. Version 32.8 fixes a compatibility issue with Spell Revisions v4b17 and newer. This is a community update, so don't blame @DavidW if there's anything wrong with it. I've tested that the AI change components install correctly. (Also, apparently he usually uses a special script to create the mod packages. I don't have access to that script, so there's a chance these mod packages may be different in some way. Or maybe they're exactly the same.)

Cheers, I'll try to merge it soon and release a new version. I believe the chunk in always.tph can be removed entirely (the surrounding code seems designed to ensure it is only executed once).

It looks like they are also referenced in some .2da files that contain the identifiers minus the WIZARD_ or CLERIC_ prefix.

No, there's no need to adjust any of the code that interacts with spell.ids on behalf of SR. It can all be removed. SCS added identifiers because SR didn't have them; that's no longer the case. What needs to be changed are the places in the SCS codebase that reference the "unofficial" identifiers added by SCS. Those identifiers can be replaced with the official identifiers added by SR. This is the search/replace I was referring to. Example: the places that refer to WIZARD_MONSTER_SUMMONING_SR_1 (weak_summons.ssl and easy.ssl) should be changed to refer to WIZARD_MONSTER_SUMMONING_LEVEL_1.

As I mentioned previously, the SCS code is now completely unnecessary. And yes, I'm suggesting a small update to SCS itself.

The switch to ADD_SPELL wasn't to accommodate SCS; it was to improve compatibility with other spell-adding mods. The recent effort was motivated by DavidW's post about the workaround he was using to add SR spells to spell.ids, but using ADD_SPELL had been a goal for a long time. Players can use SRv4b16 with SCS 32.7 until SCS receives a compatibility update. Any modders who want to look into a hotfix for SCS, feel free. I imagine it will consist of removing the code SCS uses to adjust spell.ids for SR and then doing a search/replace for any IDS references that differ between DavidW's list and the SR implementation. Take a look at this post for details on the different names and the first post in that topic for the code SCS is using to adjust spell.ids for SR.

Thanks, will fix. Good suggestion. It's not a super high priority, but I'll try to write it down so it doesn't get lost.

Yes, that's right. If IESDP doesn't explicitly state the length of a structure, you can determine it from the last field in the structure. Take the offset of that field (in this case, 0xc0) and add to it the length of the field (in this case, 8 bytes). Note that the offset is listed in hex notation while the length of the field is listed in decimal notation, so you may have to convert them when adding. For example, the actor structure in the ARE format has its last field listed as 'Unused' at offset 0x90 and it's 128 bytes long. If you convert the length of the field to hex (128 = 0x80), you can add it to the offset (0x90) to get the length of the structure (0x80 + 0x90 = 0x110). You can perform these conversions and additions quite easily with the Programmer mode on Windows' built-in Calculator program.

Congrats on the v1.0.0 release!

G3 is pleased to officially welcome SoD to Baldur's Gate 2: Enhanced Edition Item Upgrade, a new mod by @Daeros_Trollkiller. SoD to BG2EE Item Upgrade is a mod for BG2:EE that imports many more items from Siege of Dragonspear into the game, placing them into thoughtful location in Shadows of Amn. The mod also has an optional component to force importation of the SoD items that a player can normally import into BG2:EE at their normal locations. Lastly, the mod also gives upgrade recipes to Cromwell and Cespenar to upgrade most of the imported SoD items. Download Project Page Readme Forum

It's nice when the problems turn out to be easy fixes.

You should be running the function on the .are file, not .bcs.

It's safe (and preferred) to re-use strrefs that are part of the vanilla game, but it's not safe to rely on strrefs that are added by mods, since these can change depending on installation order. For EET, this would mean only using references to strings that exist in unmodded BG2EE. For strings that don't exist in the vanilla game, you should include them fully in your mod just like any brand new strings you plan to add. My RESOLVE_REF function wouldn't really factor in here. It's main purpose is to allow you to store a mixture of string references and TRA references for eventual conversion into just string references. For example, in Item Revisions, we have a table that includes the names and descriptions of all of the items. Some of them are defined using strrefs from the vanilla game, like #6976 ('Potion'), and others are defined using TRA references to new strings added by IR. During installation, the mod retrieves the mixed references from the table and converts them all into strrefs so they can be assigned to the items.

For anyone finding this in a search years later, I won't leave you hanging. The reason it was tricky was because of the parameters used by opcode 9. Both parameter1 and parameter2 need to store multiple pieces of data. Parameter1: Parameter2: To generate the parameters to supply to a function like ADD_ITEM_EQEFFECT, you need to use bit shifting and add the individual values together. COPY_EXISTING ~shld24.itm~ ~override~ SET r = 30 SET g = 60 SET b = 90 SET parameter1 = (b BLSL 24) + (g BLSL 16) + (r BLSL 8) SET location = 5 SET cycle_speed = 90 SET parameter2 = (cycle_speed BLSL 16) + location LPF ADD_ITEM_EQEFFECT INT_VAR opcode = 9 target = 1 parameter1 parameter2 timing = 2 END

Many of the changes made with standard functions could be executed more efficiently if they were done using custom patching code, especially when performing multiple alterations together. However, doing it that way requires much more effort and is more error-prone, so I would only recommend it if performance becomes a concern, or if the standard functions cannot accomplish your goal. I found a couple of my posts with custom patches and some explanations that you can take a look at here and here.