33 replies to this topic

[subtledoctor]

So, one of my mods that drastically changes the weapon proficiency system, drops all joinable NPCs to 1st level and assigns only 1st-level proficiencies, allowing the player to level up and choose any higher-level proficiencies.  I saw a way to identify and patch only joinable NPCs, by checking whether there is any value assigned to the "biography" field at 0x1cc of the .CRE file.  I got this form one of the older, established mods - I don't remember which one, but it was maybe SR or RR or BG2Tweaks or aTweaks or something.  Basically it's something that's been played for 10+ years with BGT, so I thought it was a tried-and-true method.

 

Well, I thought wrong.  There is at least one false negative: GARRIC4 in BGEE doesn't have a biography, though he should... and there are several false positives: various non-joinable NPCs in the Dark Horizons mod have biographies (for what reason, I have no idea, as you will never see them).  The latter is quite problematic - dropping a .CRE to level 1 and 8-12 hit points when it's an enemy and supposed to be a good challenging fight, is a really bad bug.

 

So... any thoughts on a more reliable method to distinguish joinable .CRE files from enemy .CRE files? Is there another part of the .CRE file that would clearly be different?  I just opened up NI and I'm eyeing the "leader" sound that NPCs make when you move them to the first slot... but I don't have a mega-mod install handy to check whether there isn't some creature from some (old, abandoned) mod that has something in that offset for no good reason.

 

Would it make sense/be feasible to do it the hard way - check every .DLG and/or .BCS for FILE_CONTAINS_EVALUATED ~JoinParty~ and then check every .CRE to see which ones use any of the resulting .DLGs/BCS's?

[Mike1072]

Might be easier to just fix the outliers.

[Roxanne]

So, one of my mods that drastically changes the weapon proficiency system, drops all joinable NPCs to 1st level and assigns only 1st-level proficiencies, allowing the player to level up and choose any higher-level proficiencies.  I saw a way to identify and patch only joinable NPCs, by checking whether there is any value assigned to the "biography" field at 0x1cc of the .CRE file.  I got this form one of the older, established mods - I don't remember which one, but it was maybe SR or RR or BG2Tweaks or aTweaks or something.  Basically it's something that's been played for 10+ years with BGT, so I thought it was a tried-and-true method.

 

Well, I thought wrong.  There is at least one false negative: GARRIC4 in BGEE doesn't have a biography, though he should... and there are several false positives: various non-joinable NPCs in the Dark Horizons mod have biographies (for what reason, I have no idea, as you will never see them).  The latter is quite problematic - dropping a .CRE to level 1 and 8-12 hit points when it's an enemy and supposed to be a good challenging fight, is a really bad bug.

 

So... any thoughts on a more reliable method to distinguish joinable .CRE files from enemy .CRE files? Is there another part of the .CRE file that would clearly be different?  I just opened up NI and I'm eyeing the "leader" sound that NPCs make when you move them to the first slot... but I don't have a mega-mod install handy to check whether there isn't some creature from some (old, abandoned) mod that has something in that offset for no good reason.

 

Would it make sense/be feasible to do it the hard way - check every .DLG and/or .BCS for FILE_CONTAINS_EVALUATED ~JoinParty~ and then check every .CRE to see which ones use any of the resulting .DLGs/BCS's?

 

 

Might be easier to just fix the outliers.

Hold on for a second. To *fix* something implies that it is broken. (just like in a recent discussion about *missing/broken* 10th colums for kits, this again may not be the case.)

 

check whether there isn't some creature from some (old, abandoned) mod that has something in that offset for no good reason.

The mod being *old* or *abandoned* does not automatically justify the assumption that this offset is used with *no good reason*. (Especially when saying at the same time you did not even check it).

 

Some examples

In Dark Horizons (Nikita and her brother), Region of Terror (Jarlaxle) and some other mods, there are NPCs that MAY become joinable if you convince them but are otherwise your enemies. Jarlaxle may be the most striking example, he is the end boss in that mod but an evil, charismatic protagonist can turn him to join the party instead, i.e reducing him to a level 1 NPC would invalidate the whole mod for the case where you decide to fight him (not much of a fight left in this case). There is also Balthazar in ToB who may become your enemy or your ally.

Shar-Teel - she only joins you after a fight with a male of your party. Reducing her before she joins creates issues unless you use another tweak to prevent her death.

You meet a number of NPCs in dangerous situations. where they fight their own enemies and you can join that battle and help them before you recruit them (e.g. Tyris Flare or Chloe etc). Reducing them to level 1 almost guarantees they will have no chance to survive long enough before talking to you, they cannot even use their own weapons until they level up.

Other NPCs start as enemies and if you beat them, they surrender and you may show mercy/interest to let them join.

Garrick in BG1 is a vanilla NPC.

 

Just take a closer look at some cases to see that the *outliers* are legitimate NPCs the way they are. It just means that a *one-size-fits-all* approach, regardless which method you use to identify joinable NPCs, creates incompatibility with some cases. Even with a 100% method to identify all joinable NPCs, the question remains whether it is legitimate modding to change other mod's NPCs to a point that can break them

 

It is quite some strange attitude to always predicate that all others do it wrong...

 

PS - K4thos for EET uses some method to identify the joinable NPCs, it might be like having an entry in Pdialog.2da, but I am not sure. Better ask him direcly.

Edited by Roxanne, 23 August 2017 - 10:50 PM.

[jastey]

Roxanne: None of the points were ever mentioned for Level One NPCs? I totally agree that what you wrote about the instances where joinable NPCs have to fight before joining makes sense but I'd still be curious why it was never a problem with Level One NPCs (or at least I never heard of it).

Edited by jastey, 23 August 2017 - 11:04 PM.

[Roxanne]

Generally, is not Level One NPCs (or the new EE equivalent to it) the better method here?

The player has the choice to select the NPCs to be treated that way and some NPCs (especially mod NPCs) would only appear as candidates for selection if appropriate.

The method to enforce these changes on just anyone remains doubtful and will always create one issue or another.

Edited by Roxanne, 23 August 2017 - 11:21 PM.

[Roxanne]

Maybe there is a quite simple solution:

- let the mod do all its tweaks on all NPCs as it likes

- create a short exclusion list for NPCs which need to be left unchanged

- after the component has finished, restore the cre files from the list from mod/backup back to /override.

[K4thos]

Here you go: http://gibberlings3....835#entry256207

 

Although I must say that your implementation indeed sounds risky. Another example (SoD end game spoilers, don't click if you haven't finished the expansion)

Spoiler

At the end of SoD you are fighting with or against Caelar Argent. If she will be at level 1 than this will be a joke of a fight (she should be level 15)

Edited by K4thos, 24 August 2017 - 01:08 AM.

[Roxanne]

Here you go: http://gibberlings3....835#entry256207

 

Although I must say that your implementation indeed sounds risky. Another example (SoD end game spoilers, don't click if you haven't finished the expansion)

Spoiler

At the end of SoD you are fighting with or against Caelar Argent. If she will be at level 1 than this will be a joke of a fight (she should be level 15)

Her cre files have BIO, so definitely affected and not  *some creature from some (old, abandoned) mod that has something in that offset for no good reason.*

[Mike1072]

Might be easier to just fix the outliers.

Hold on for a second. To *fix* something implies that it is broken. (just like in a recent discussion about *missing/broken* 10th colums for kits, this again may not be the case.)

If there's a version of Garric that's missing his bio, that sounds like it might be broken. And if there are some non-joinable NPCs that have a bio, they don't need it. It could be removed from them before patching or they could be specifically excluded from the patch.

My point was that fixing the few false positives/negatives that occur with this detection scheme may be simpler than combining it with some new criteria like leader sound (and having to deal with any false positives/negatives that it may have).

[subtledoctor]

Roxanne, I don't understand why you take such umbrage at simple adjectives (Dark Horizons is after all both old and abandoned... other mods are old and maintained (e.g. CDTweaks) and yet others are new but abandoned (e.g. FGKits).  It's not a criticism, just a statement of what we have to work with.  If there is a problem with Dark Horizons, is the mod going to be updated, or will a patch be added to the BWFixPack?  If the latter, then the mod is abandoned.  Simple.

 

When someone tells me a non-joinable NPC has something in their biography or leader sound field... it is a perfectly reasonable assumption that it is without good reason.  If that .CRE is in fact a joinable NPC, it doesn't mean the description was bad, only that it was based on incorrect information.  In such a case you could simply provide the correct information.  Literally one sentence like "some NPC .CRE files are designed both as enemies you fight and as joinable, depending on what happens in the encounter" would have sufficed to move the conversation along.

 

Anyway, now that I know that, it changes things.  Again I'm surprised that this never came up before with other mods that patch joinable NPCs, but it is possible they just don't patch them in ways that are apparent when you fight them.  Whereas this clearly does.

 

All of which means, this just requires a more complicated solution.  Leaving NPCs unchanged is not a solution... here's a "for instance:" the component allows rangers and paladins to achieve mastery (3 stars) with weapons instead of just specialization.  Say Valygar is on the "don't change" list... you could recruit him at TOB levels, and he would only have 2 stars in katanas etc.  And you might not have a chance to max out his capabilities for another million or so XP.  That's not satisfactory.  And it applies equally to any NPC you might put on the "do not change" list.

 

Off the top of my head, there are three possibilities:

 

1) Change NPCs in-game, as part of the JoinParty process.  This seems... complicated.  Probably need to patch scripts/dialogues themselves, adding a "DO(ApplySpellRes())" to every instance of JoinParty.  Or... well, something like that.

 

2) Give all joinable NPCs an ability that does everything this component does, dropping them to 1st level.  So their proficiencies would be wrong when they join but you would have the option to manually rebuild the character from the ground up within the game.  This could be pretty cool in its own right, if very 4th-wall-breaking.  Actually this might be a nice addition to NPC_EE.

 

3) Don't change levels at all, instead just add an ability that (based on class and level) allows you to increase one or more proficiencies by dialogue.  The difficulty here is one of precision.  How do I make sure the dialogue offers all the right options and none of the wrong ones?  I don't think it can read weapprof.2da the way Weidu can... making this compatible with the new Faiths & Powers system might be a nightmare. Maybe.  Though, maybe not.  If the dialogue  only allows you to increase proficiencies the character already has, it would implicitly comport with whatever rules were already applied up to that point.  Hmm...

[Ardanis]

BIO strref means nothing, really.

 

Check if creature's script name exists in PDIALOG.2DA, iirc this is how they're normally detected as valid party members.

What Kathos said about SoD also applies, there maybe special cases when a character is supposed to be high enough level for plot purpose, either as ally or as enemy.

 

PS Have a look at NPCLEVEL.2DA, should be possible to replace all level 2+ CREs with level 1 version, so even if you face an NPC as a high level boss, when they JoinParty() they'll drop to level 1 (I think it works this way). EE v2.0 has actually done exactly that, basically killing the entire purpose of that table and replacing the level growth with scripted XP adjustment, so you may need to fix that if it blocks your design.

Edited by Ardanis, 24 August 2017 - 11:37 AM.

[subtledoctor]

there maybe special cases when a character is supposed to be high enough level for plot purpose, either as ally or as enemy.

Question being, how to distinguish those? We're not just talking about boss-level people like that spoiler there (and thanks for putting that in a spoiler k4thos, I have indeed not yet played SoD... though I fear I know what you are talking about), we're also talking about some rando NPCs from a mod.

No, I think a completely different mechanism is called for.

[Ardanis]

See my post edit, NCPLEVEL.2DA may be an automatic solution for your problem. May be, I don't know for a fact.

 

PS SoD's versions of those tables are NPCLVLDS and BDDIALOG, vanilla are NPCLEVEL, NPCLVL25 and PDIALOG. Consider using only vanilla files to test the code

Edited by Ardanis, 24 August 2017 - 11:45 AM.

[CamDawg]

NPCLEVEL isn't utilized by mod NPCs, though.

I'm pretty sure it's Tweaks you found that uses the bio string for joinable detection. PDIALOG can give you a set of joinable DVs, but even then you're still going to get false positives when you start looking for those in creature files--all of the various cutscene Imoen creatures are copies of her actual joinable creature files and are difficult to differentiate. In the end, you're going to have to use some manual filtering of false positives.

[subtledoctor]

PS Have a look at NPCLEVEL.2DA, should be possible to replace all level 2+ CREs with level 1 version, so even if you face an NPC as a high level boss, when they JoinParty() they'll drop to level 1 (I think it works this way).

Wait that's really interesting. Mod NPCs don't use the table but maybe they could be appended...? Then I could clone any NPC in pdialog.2da/has biography/has leader sound... and add the clone to npclevel.2da, so the clone is only used upon joining the party, and the AI version of the NPC would remain the same.

Hmmm...