"Make Xan a Generalist Mage" doesn't seem to work

[Chitown Willie]

Installed :

~CDTWEAKS/SETUP-CDTWEAKS.TP2~ #0 #4130 // Make Xan a Generalist Mage (Mike1072): v9

But Xan is still an Enchanter:

And doesn't seem like "BGXAN.CRE" is touched:

Mods affecting BGXAN.CRE:
00000: /* created or unbiffed */ ~BGT/BGT.TP2~ 0 0 // Baldur's Gate Trilogy - Corev1.21
00001:  ~BG1UB/SETUP-BG1UB.TP2~ 0 20 // Audio Restorationsv16.3
00002:  ~BG1NPC/BG1NPC.TP2~ 0 0 // The BG1 NPC Project: Required Modificationsv24.9
00003:  ~SETUP-BGTTWEAK.TP2~ 0 2400 // Enemy items shatter11 (5 Feb 12)
00004:  ~JA#BGT_TWEAK/SETUP-JA#BGT_TWEAK.TP2~ 1 28 // Xan's improved spellbook1.73
00005:  ~INFINITYANIMATIONS/SETUP-INFINITYANIMATIONS.TP2~ 0 8010 // BG1 Animations for NPCs50% of relevant creaturesv5
00006:  ~SCALES_OF_BALANCE/SCALES_OF_BALANCE.TP2~ 0 206 // SBO - Hit Dice OverhaulGenerous (above-average) hit pointsv5.28
00007:  ~XPMOD/SETUP-XPMOD.TP2~ 0 1 // Creature XP ReductionReduce to 50%7
00008:  ~CREFIXER/SETUP-CREFIXER.TP2~ 0 0 // Creature Slot Fixerv2
00009: /* acted upon in an undefined manner */ ~GENERALIZED_BIFFING/GENERALIZED_BIFFING.TP2~ 0 1 // Generalized BiffingBiff all files (recommended by the Big World Dudes)v2.4

[Mike1072]

This component needs to be updated to also modify bgxan.cre, which is is the BGT version of his 1st-level incarnation.  (Same for the Xzar generalist component and bgxzar.cre.)

[Endarire]

@Chitown Willie
NPC EE is an in-game workaround.

[Jarno Mikkola]

43 minutes ago, Endarire said:

@Chitown Willie
NPC EE is an in-game workaround.

Thing is, does that work in a BGT-weidu install ? Yeah, this is one of those. And then that shouldn't have the "EE" in it's name.

But I get the point you try to make, which is, there are several alternatives, one being Level 1 NPCs, other is several NPC mods, and a tweak or another mod that allows this... or just suitable ShadowKeeper/Near Infinity save game edit.

[Angel]

15 hours ago, Mike1072 said:

This component needs to be updated to also modify bgxan.cre, which is is the BGT version of his 1st-level incarnation.  (Same for the Xzar generalist component and bgxzar.cre.)

Yeah, I could never quite wrap my head around when to use bg and when not, it seems a little inconsistent at times.  Oh well, I'll try to make a fix (the revision of this component and extending it to Dynaheir, Edwin and Xzar was my work).  Probably best if I use %tutu_var% for Edwin and Dynaheir and %tutu_scriptbg% for Xan and Xzar, I think?

[Mike1072]

Yes, that would be a good solution.  I don't have an active BGT install to check the files, but looking at the BGT code and this folder, I think Xan, Xzar, and Quayle are the only joinable NPCs who get their own special files.

Edit: The Edwin and Dynaheir components should work fine as they are now.

Edited October 20, 2020 by Mike1072

[Angel]

21 minutes ago, Mike1072 said:

Yes, that would be a good solution.  I don't have an active BGT install to check the files, but looking at the BGT code and this folder, I think Xan, Xzar, and Quayle are the only joinable NPCs who get their own special files.

Mm, I will have to take into account that xan.cre has been changed to bgxan.cre, but xan4.cre and xan6.cre are left as they are.  Same for Xzar, xzar.cre becomes bgxzar.cre, but xzar2.cre, xzar4.cre and xzar6.cre are left alone.

[Angel]

I created a fix that seems to work properly, tested on BGT and BG1EE (I do not have Tutu).  Pull request made on github.

[Mike1072]

1 hour ago, Angel said:

Mm, I will have to take into account that xan.cre has been changed to bgxan.cre, but xan4.cre and xan6.cre are left as they are.  Same for Xzar, xzar.cre becomes bgxzar.cre, but xzar2.cre, xzar4.cre and xzar6.cre are left alone.

Woops, I didn't think of that.

Your pull request looks good.  There's some funkiness going on with the line endings that's messing up the diff but that's because the file in the repo is weird, so maybe I'll try to fix that up first.

Edit: oh god, so many files are CRLF.

Edited October 20, 2020 by Mike1072

[Angel]

10 hours ago, Mike1072 said:

Woops, I didn't think of that.

I almost missed it too. ^^

10 hours ago, Mike1072 said:

Your pull request looks good.  There's some funkiness going on with the line endings that's messing up the diff but that's because the file in the repo is weird, so maybe I'll try to fix that up first.

Edit: oh god, so many files are CRLF.

Yeah, that seems to be a common issue, often when I pull .tpa files from a repo that isn't mine they are full of CRLF.  dos2unix easily fixes that locally, but it does tend to mess diffs up.  Maybe adding "*.tp? text" to .gitattributes will help there.

[Mike1072]

For better compatibility, I don't think the Windows line endings should be stored in repos.  Users on Windows can easily deal with this by changing the git configuration setting "core.autocrlf" to true.  I think @CamDawg might not have had that set, which would explain the files in this repo.

The Windows installer for git sets "core.autocrlf" to true by default, but there are a variety of ways of installing git on Windows, and they might not all do it.

[Angel]

12 minutes ago, Mike1072 said:

For better compatibility, I don't think the Windows line endings should be stored in repos.  Users on Windows can easily deal with this by changing the git configuration setting "core.autocrlf" to true.  I think @CamDawg might not have had that set, which would explain the files in this repo.

The Windows installer for git sets "core.autocrlf" to true by default, but there are a variety of ways of installing git on Windows, and they might not all do it.

Yeah, that seems to be the case, and he's not the only one.  I've seen it with several mods I have contributed to.

From the git manual, the recommended way to address this regardless of the local settings of contributors is as follows (this is for Linux, not sure about other OS):

Quote

From a clean working directory:

$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

This ensures that any file detected as text gets stored with only LF in the repository (by default git does not change file content).