CamDawg

Geez, just because I'm single-handedly holding up progress, everyone's unhappy... j/k

Seriously, though, I've caught up on PRs. The ones left are marked as in-progress or I need to double-check something first.

1 hour ago, mickabouille said:

Thanks for the write-up but... I re-read it thrice and I'm not sure I understand.

Am I understanding correctly that the basic problem is that the vanilla tlk are not a 1:1 match in different languages?

Or that the correct way for weidu to edit the tlk would be to never reuse existing strings and always create new ones?

 

Both seem more a problem of "didn't think about it at the beginning"

 

EDIT : ah well, the original versions only came with one language IIRC so it probably wasn't even a problem

Pretty much. Let me give you a concrete example from BGEE.

Let's say I make a mod with a small area with a kitchen, to which I add a male creature named "Cook". In English, WeiDU looks in the tlk and sees the existing string "Cook" at 32197. (String 12895 is also "Cook" but WeiDU selects the last matching string.) However, cooks in the French version are "Cuisinière" (32197, female, used by fcook2 e.g.) and "Cuistot" (12895, male, used by mcook) for cooks. So WeiDU either decides to use 32197 on the French version, which isn't correct for French players, or adds a new string to all tlks, which introduces redundancy (at best) or bugs (at worst).

lynx is correct in that this can be somewhat mitigated by modders--since "Cook" is an existing string I should be using a direct string reference in my installer (in this case, 12895) rather than introducing the name like it's a new string.

11 hours ago, mickabouille said:

As an aside, is there away to have it update multiple game langage? I mean, keeping theability to change game language at runtime in the game options?

No, mainly because of the subtle way WeiDU interacts with dialog.tlk.

When a mod uses a new string, WeiDU looks in the existing talk table for a matching string; if it finds a match it uses the existing reference instead of making a new tlk entry. If it doesn't need a new entry in English, but needs one in French, you're already in a conflict since a creature or spell file can only reference one of those values. So you either force the French tlk to use the English reference value or force the English tlk to make a new entry for a redundant string. The former is bad since there's no way to know if the forced French string is a good match, and the latter is bad because if it's a feedback string for a spell (think of something like "level drained" or "held") then everything that might block the string now requires an update--and mods that come after won't know it's there at all. And all of this is a best-case scenario, where you're talking the first mod on a clean install--it will get exponentially worse as you add more mods.

59 minutes ago, argent77 said:

I don't know if or how the GOG version is different, but in my oPST (disc) version all biff files can either be found in the root directory or the "CDALL" subfolder.

There's no CDALL folder, but otherwise for the GOG version I have 185 biffs in the game root and another 188 in the data folder.

It's working on mine--NI v2.4-20231231 on Win 10 with the GOG version of oPsT.

Since brackets and periods are special characters in regexps, you need to escape them if you're literally trying to match those characters. E.g.

REPLACE_TEXTUALLY ~"ankheg",[912.1057],S~ ~"remorha",[912.1057],S~

needs to be

REPLACE_TEXTUALLY ~"ankheg",\[912\.1057\],S~ ~"remorha",[912.1057],S~

Honestly, we're about 15 years too late for a switchover. Most old mods are lucky to get maintenance (including WeiDU itself); realistically there's no way they'd be migrated to a new tool. So we're already starting from a point limiting any new tool: it would have to be backwards compatible,  which is already a lot of extra work and design constraints.

7 hours ago, AL|EN said:

the modder is free to change the DESIGNATED value without breaking other mods, simply as that

There's no upside to changing the component number of a mod once it's released, only downside, and that's true regardless of whether LABELs are being used. There's no queue of modders desperately wanting to change component numbers, being held at bay only by downstream compatibility concerns.

There are several good use cases and benefits for using LABELs. This is not one of them.

The claim is that it frees us from the tyranny of fixing a DESIGNATED value, which is nonsensical, as that's the whole point of DESIGNATED. It's like arguing that by using DESIGNATED it frees us to change LABELs, an equally nonsensical proposal.

DESIGNATED was created so that mods with multiple components (e.g. Tweaks) could present the components in a sensible order in the installer without causing massive compatibility headaches down the line. Prior to DESIGNATED, WeiDU simply numbered components itself starting with 0, so if you wanted to add components they had to be at the end of existing ones. Tweaks is barely manageable as it is; I want you to imagine the horrific mess it would be if it was organized in a purely chronological order of the components by creation date. With fixed DESIGNATED values I can freely add components where I think they fit in the order, move them around, or do whatever without making David and other modders having to constantly shift around their compatibility checks.

AL|EN's doing a little not-so-subtle lobbying here: no one is using LABELs to check against other components--at least not yet, and this paradigm shift was proposed three years ago. Keeping your component numbers DESIGNATED is more important, and I don't foresee that changing any time soon.

This isn't to say that LABELs aren't useful: they very much are, and you should use them, and they'll become even more useful is we ever get a new version of WeiDU with the proposed changes to LABEL handling. I'm simply clarifying that DESIGNATED is still relevant and not to be discarded, and that changing a DESIGNATED value is exceptionally bad practice.

DESIGNATED is important and should still be used in conjunction--WeiDU still uses component numbers for command-line installs as do some other tools. I'd recommend new mods use DESIGNATED from the start.

The important thing with DESIGNATED is that its entire purpose is to lock a component to a number, so changing the DESIGNATED number of something undermines the entire purpose. IOW once you set a component a DESIGNATED value, don't change it. Like, ever.

1 hour ago, Morgoth said:

Is this a bug?

No, this is a design decision.

Ooh, this one is subtle. The game is expecting an integer number or an IDS reference--it's not properly recognizing the hex number as a number and treating it like it's a symbol. Swapping it to "3" or "MASK_EVIL" makes it work.

There was no limit in the original. After his inventory was full, he'd still buy them and then drop them at his feet, meaning you could exploit him for infinite money starting with pelt #21.

The BD fix is to address a slightly different issue. If you already have a pelt in your inventory when you first chat with the merchant, they will simply take it as if you already heard his request. As you've already touched upon, many (if not most) BG quests were fragile in that dialogues assumed an order of events and broke easily or skipped major sections if anything was out of sequence. BD had to do a lot of cleanup to add flexibility to them.

Ages ago I coded Tracking to be a level one, at-will innate for IWDification. I didn't release it as there's only tracking info for ToB areas--having a ton of "no info" as you wander around BG and SoA seemed fairly pointless. It will be in the next IWDification release since @Lava wrote up a ton of nice, IWD-style tracking blurbs for all of the BG areas.

'comp' items are from One Pixel Productions, which was baked into the EEs. They're basically cosmetic copies of items but use a weapon animation that's supported by the creature animation that's supposed to be wielding it. In this case the comp Foebanes use long sword animations instead of bastard sword.

In this case it's unnecessary as Foebane +3 is wielded by a creature that supports bastard swords, and Foebane +5 is handed out by Cespenar, so neither of the copies are actually used.

About a year two years ago, Saltlord (user on Discord) played through a game of oIWD with Tweaks and Auril's Bane. He was fantastic about reporting bugs, so Tweaks v16 ended up getting a lot of bug fixes specifically for oIWD, and a lot of compatibility fixes for Auril's Bane.

As far as order, the one in the pinned thread should still be valid AFAIK.

As for whether you should use IWD Fixpack or AB, I'm naturally going to say IWDFP. It's more comprehensive, has been maintained over the past decade*, and uses the substantially more rigid definition of "fix" that we used for BG2FP and EEFP. I also think UB's version of the Voice is better (another unbiased opinion to be sure), mainly because I got access to the original IWD developer notes and was able to bring it better in line with the original plans.

* Yes, I know the last release was 14 months ago, don't @ me. 14 months is lightning speed for me.

1 hour ago, jmerry said:

I don't think EXTEND_TOP works on an empty script

EXTEND_TOP/BOTTOM acts as COMPILE if the target for extension doesn't exist. edit: For clarity, it compiles the script extension as the target file name.

No, I don't have to worry about red icons, or icons being imposed over another UI element of a dramatically different color. It's being done for spells with white icons only, and only for the specific icon used in the spellbook where the background is always some variant of parchment.

I could, but if I'm going to start byte-editing the BAMs I might as well go whole hog and do the borders there as well. It's just more trouble than it's worth, especially considering no one was keen on non-black borders to begin with.

This is in for the next version of Tweaks. Since the Photoshop macro was trivial to write, both options (black and gray outlines) will be available.

And speaking of the readme, Bardic Reputation Adjustment is oBG-only, which is covered in the readme. It's a special version, adapted (with permission from BG1 NPC) for oBG in the old BG Tweak Pack since BG1 NPC isn't available for oBG. For platforms where BG1 NPC is available (e.g. everything that includes BG that's not oBG) Tweaks defers to BG1 NPC.

I'll add an exclusion for TnT's Taerom component.

The reason for the change was that those were being loaded into an array, and the second entry replaced the first, so that Courage never showed up anywhere. I fixed this in IWDification, which was farmed back to the original library which propagated into the current SCS and ToF releases.