12 replies to this topic

[russ]

I probably shouldn't be asking this question here but I think the problem I'm having is related to BGT. Some NPCs are created when you enter a new area and the script for that area will CreateCreature that NPC at a specific point and if the script has a level check it will spawn a specific .cre file that matches the level of the PC. That I understand. It seems, though, that several NPCs (Yoshimo, Kachiko, Aerie, for example) aren't created this way. I was trying to find what file is used to create them and the best I could come up with was NPCLEVEL.2DA. I've just joined Yoshimo and he was level 10 and based on the Yoshi7.cre. Based on my PC's level he should have been level 11 and based on Yoshi11.cre. Using NI to look into my save games Kachiko and Aerie will also be the wrong levels when I join them since the NPC list (in baldur.gam in my save dir using NI) points to Kachi10 and Aerie7. However, if I'm right, I should be joining with the 11th level version of each of them. Does anyone know how the game engine puts these NPCs into your game and how it does the level check?

Thanks.

[Sir BillyBob]

I use a script on my NPC in BoneHill to level up. Normally the NPC's use the area script to level them based on when you first enter the area. Not a great solution if you enter several times before you actually have them join.

The NPCLEVEL.2DA file should help control which CRE file you will meet. Aerie is kind of different. There is nothing about her in the AR0604 area script and she isn't on the ARE file as an actor. Not exactly sure how they added her to the game.

As for your match of levels against an NPC, I assume your PC is not a dual-class or multi? Those seem to throw the game when doing level comparisons. Remember Flop in the Copper Coronet? He's appearance will be different for a multi-class PC than for a single class PC. Also, the game may be comparing your XP amount not the exact level you are at. Though in this case, I would assume Yoshi would be a higher level than you since most thieves advanced in levels faster than other classes.

Anyone else have an idea?

[horred the plague]

Anyone else have an idea?

BALDUR.GAM is the game's default NPC add-er (not the one in your savegame, the real file). Most of the standards (all, before modder intervention) were added this way. TS NPC's were done this way--though Vlad may have changed it in v6.0--if so, I'll have to back him up. Remind me, i'll check when back on the BP duty. It does work in conjunction with npclevel.2da. It's proven itself to be a bit buggy at times, as I'm sure you've noticed.--That's why most modders discarded this system, and went with the scripting method. XP seems to be the better check, because in dual/multiclassers--only the first class level is counted in the Level (LevelGT/LT) checks. XP counts both classes' XP towards the enumeration.

[russ]

BALDUR.GAM is the game's default NPC add-er (not the one in your savegame, the real file). Most of the standards (all, before modder intervention) were added this way. TS NPC's were done this way--though Vlad may have changed it in v6.0--if so, I'll have to back him up. Remind me, i'll check when back on the BP duty. It does work in conjunction with npclevel.2da. It's proven itself to be a bit buggy at times, as I'm sure you've noticed.--That's why most modders discarded this system, and went with the scripting method. XP seems to be the better check, because in dual/multiclassers--only the first class level is counted in the Level (LevelGT/LT) checks. XP counts both classes' XP towards the enumeration.

Once again Horred proves he is worth every penny we pay him! :thumb:
.
.
.
ok, maybe all the praise we give him, yeah that's it :thumb: :thumb:

i've done some testing and I think I've learned a little more about this. For me Baldur.gam, npclevel.2da and npclvl25.2da were in biffs. When I extracted these files into my override, increased the XP on all my in-partyNPCs and my PC, and moved to an area (0603) with new NPCs, the NPC's in that area also increased in level, whether I joined them or not.

First, what I've learned about the starting level of the NPCs, it doesn't get updated until you enter their area for the first time (no surprise there) and I think it's dependent on the XP/level of all the characters in your party not just the PC.

More important, I think having these files in a biff actually hurts the performance of the game. Before I moved these files into the override Yoshi wouldn't increase his starting level but Kachiko would. With them in the override, however, both increased their starting level. (I first tried just baldur.gam in the override but that didn't work and then I put all 3 files in the override and that did work.) I think that's because as soon as you enter 0603 Yoshi is created (so there isn't enough time for the game to update his starting level) but Kachiko isn't created until you are about to leave (so there is time for her starting level to be changed from the default). If I'm right having these files in the biff is what produces the bug.

And now I'm also wondering if baldur.gam is somehow involved in the xpcap problem we were having. Because the xpcap was checked as soon as you loaded a game maybe there wasn't enough time for the game engine to check the new cap levels in the .2da file and, therefore, stuck with the default cap level.

Anyway, thanks Horred and I hope the solution to this is as easy as I think it is.

[horred the plague]

Anyway, thanks Horred and I hope the solution to this is as easy as I think it is.

No prob, russ--but I disagree with your theory. Baldur.gam is in the biff files in ToB "vanilla", even the patched version. As is NPCLEVEL.2DA and NPCLVL25.2DA.
So, toss fate to the wind and flip a coin...

[Vlad]

TS NPC's were done this way...

No.

[horred the plague]

TS NPC's were done this way...

No.

Okay, i'll change it in BPv170. Originally, they most certainly were. I remember the nightmares of NooB autumn 2002, trying to figure out how to edit Baldur.GAM file.

[Ascension64]

TS NPC's were done this way...

No.

Okay, i'll change it in BPv170. Originally, they most certainly were. I remember the nightmares of NooB autumn 2002, trying to figure out how to edit Baldur.GAM file.

I would just like to note that BGT-WeiDU OVERWRITES the original BALDUR.GAM to remove Minsc and Jaheira (there might be others) from appearing at a 'mono'-level. I suppose I could get WeiDU to remove the relevant bytes but that could be tricky.

[russ]

No prob, russ--but I disagree with your theory. Baldur.gam is in the biff files in ToB "vanilla", even the patched version. As is NPCLEVEL.2DA and NPCLVL25.2DA.
So, toss fate to the wind and flip a coin... 

Yeah, but maybe when chitin.key gets too big, or if a file is biffed multiple times (in my game it would have been biffed by ToB, then BP-BGT-NEJ, then (I think) CtB. Something causes the files not to be read quickly enough by the game. Something to think about for the new biffing strategy in BPv170?

[horred the plague]

I would just like to note that BGT-WeiDU OVERWRITES the original BALDUR.GAM to remove Minsc and Jaheira (there might be others) from appearing at a 'mono'-level.  I suppose I could get WeiDU to remove the relevant bytes but that could be tricky.    

Or, wait for BPv170, and use that BALDUR.GAM as a base. Just take out Jaheira and Minsc (we'll have to check Imoen as well). Then, when it matters, you'll have a new overwrite version--up to date. No need for fancy coding then. Or, better yet--I add these 2 (3) via scripting even in BP, doing the .GAM overwrite for you while I'm fixing the others. That way, it won't even be a concern of yours. Or, at worst case--we'll have some AR0602.BCS issues to sort out.

[Ascension64]

I would just like to note that BGT-WeiDU OVERWRITES the original BALDUR.GAM to remove Minsc and Jaheira (there might be others) from appearing at a 'mono'-level.  I suppose I could get WeiDU to remove the relevant bytes but that could be tricky.    

Or, wait for BPv170, and use that BALDUR.GAM as a base. Just take out Jaheira and Minsc (we'll have to check Imoen as well). Then, when it matters, you'll have a new overwrite version--up to date. No need for fancy coding then. Or, better yet--I add these 2 (3) via scripting even in BP, doing the .GAM overwrite for you while I'm fixing the others. That way, it won't even be a concern of yours. Or, at worst case--we'll have some AR0602.BCS issues to sort out.

Yup, Imoen as well. What is the change to AR0602.BCS? I currently do a rather large REPLACE_BCS_BLOCK on it.

[hlidskialf]

Don't do a REPLACE_BCS_BLOCK, instead do a creative DECOMPILE_BCS_TO_BAF and COMPILE_BAF_TO_BCS. Just replacing the block will fail unless the block matches exactly. There are more code options with the latter.

[Ascension64]

Don't do a REPLACE_BCS_BLOCK, instead do a creative DECOMPILE_BCS_TO_BAF and COMPILE_BAF_TO_BCS. Just replacing the block will fail unless the block matches exactly. There are more code options with the latter.

I was thinking of doing that, because the BGT-WeiDU.tp2 is so messy that adding some script lines would be little compared to the mass conundrum that I have at the moment.