Mike1072

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.

On 7/1/2014 at 8:50 AM, Demivrgvs said:

Before starting to discuss changes to specific items that may be included in future updates of the beta, there's a couple of things that are already implemented in the current build but not yet mentioned in the first post.

Weapon Changes

Short Swords now use slashing dmg type instead of piercing.

This change may sound odd but we've done this in an effort to give every weapon type some sort of "role".

Short sword advantages over long swords:

• no backstab penalty
• can be dual wielded more efficiently
• better speed factor
• better thac0 against armor (because of piercing type)

Long sword advantages:

• +0.5 dmg

Short sword advantages over daggers:

• +0.5 dmg
• range 1 instead of 0 (not a big deal I know)

Dagger advantages:

• better speed factor

The above mentioned gloabl change would remove short sword advantage against armor compared to long swords, while giving daggers a bit more value. What do you think?

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.

1 hour ago, subtledoctor said:

As far as what to do about this: this is not my area of expertise.  Would I be correct in assuming that it is preferable to give SPWI107 two different IDS entries, vs. changing the one created by SR?

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.

7 hours ago, subtledoctor said:

In adding spell projectiles to clearair.2da, SR 4b18 adds spell names with two words, rather than a single string joined by an underscore.  This means there are three columns in the 2da file, which may be problematic.

Thanks, will fix.

On 2/5/2020 at 9:07 AM, Luke said:

For each spell that lets you polymorph into some creature (e.g., WIZARD_SHAPECHANGE and the like), you might want to disable the following buttons (via opcode #144): Stealth, Thieving, Turn undead, Bard song and Find traps.

Guess it makes sense...?

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:

Quote

The 'RGB Colour' field is handled as follows:
Second byte = Red (0-255)
Third byte = Green (0-255)
Fourth byte = Blue (0-255)

Parameter2:

Quote

The 'Location' field is handled as follows:
First byte = Location
Third byte = Speed (0-255)

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

On 1/25/2020 at 11:49 AM, jastey said:

@subtledoctor how about writing this in an own thread in Modding Tutorial section? It's gems like these that make it so much easier for later folks.

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.

I'm the author and can try to explain.  It creates an inlined file with contents:

OUTER_SPRINT string @1234

Then, it INCLUDEs the inlined file, which executes that code.

Its purpose is to fetch the text for either a TRA ref (@1234) or a strref (#1234).  You must include the @ or # symbol as part of the ref variable.

WeiDU does have built-in tools that deal with fetching only TRA refs (AT) and only strrefs (GET_STRREF).  Here are examples of their usage.  In these cases, the ref variable should contain just a number, no symbol.

SPRINT string (AT ref)

GET_STRREF ref string

The home for my function (named FETCH_STRING) is here.  There is a companion function named RESOLVE_REF in the same file, which is what Item Revisions actually uses.  It behaves similarly, taking either a TRA ref or strref, but instead of returning the associated string, it returns the associated strref.  In the case of a TRA reference, this involves adding the string to dialog.tlk.  This would be more useful for a situation where the .tra file contains complicated entries that need to be preserved, like associated sound effects or male & female lines for the same reference.  That extra information is normally lost when putting the string into a WeiDU variable.

Those last 2 columns should be strrefs according to IESDP.