Jump to content

Rebuilding Blucher's alternate BG2 NPCs


Nythrun

Recommended Posts

Hey, silly question, but i know that

READ_ASCII offset "%myVariable%"

 

changes to

 

WRITE_EVALUATED_ASCII offset "%myVariable%" ...

 

does

READ_BYTE 0x0274 "%specific_ids%"

 

map to

WRITE_BYTE 0x0274 "%specific_ids%"

 

or does it have a similar EVALUATED command?

 

Side note: it looks like I don't understand proficiencies. I understand the table, but BG2 proficiencies look like they are effects - the only .cre references seem to be BG1. That means either the base.cre needs the correct proficiencies, or I need to try to follow a spells-like read/patch routine - any suggestions?

Link to comment
Don't worry about the text entries in the animation .ids at all, they're never written in the creature file or used.

 

By this do you mean that I don't need to change

 

WRITE_SHORT 0x0028 0x6310 //animation ID

 

to match the .cre? If so, will a base.cre with a gender change by patch automatically switch animations? (Sorry I'm slow - so much to learn, so little time... thank you so much for the handholding. It is both needed and appreciated.)

 

For those folks with time available, please jump onto the Wiki and toss some code around. I will try to have a working sample up by tomorrow midday, assuming early-morning cleanup of BG1 NPC allows me the freedom. Azazello, if you .rar the .cres so far up, please send to svowles at comcast dot net.

Link to comment

OK, folks, slight delay on the coding front - I will see what I can get done on this this weekend. The idea is to build a "template" testing mod that changes Imoen into all of the created base.cre variants, and then test on Tutu, BG2, and BGT to bump any bugs out of hiding. Then the rest of the mod is just copy/paste/delete with the bulk of the work going into the ADD_CRE_ITEM changes and the special item edits.

 

I still need to go back over this thread and some tutuorials; an attempt to change the gender by WRITE_BYTE on a BG1 NPC .cre from C_E failed this week, so while I havethe basic idea the code is still a little "black box" or "building block" for me :)

Link to comment

Checked and responded!

 

I could use an expert glancing at the code on the Wikki under the Preliminary Body category; I built the test mod, and got it to install and change Imoen to a fighter, but her proficiencies ended up being all sorts of weird things, she had all sorts of corrupt items (incuding several corrupted _BOW05.itm) and basically became scrambled as a .cre. That was on my own built .cres - on Azazello's, we somehow changed the .cre version from 1.0 to BOW05...

 

Debug shows no problems on the new creature, despite the fact that the .cre is scrambled egg on toast with a side of herring!

Tutu install detected...
Copying and patching 1 file ...
[l1npcs/fighters/hFIGHTER.cre] loaded, 2132 bytes
[./override/_imoen2.cre] loaded, 1332 bytes
[./override/_imoen2.cre] loaded, 1332 bytes
Copied [l1npcs/fighters/hFIGHTER.cre] to [l1npcs/template/imoen.cre]
Copying and patching 1 file ...
[l1npcs/template/imoen.cre] loaded, 2132 bytes
override/_imoen.cre copied to L1NPCS/backup/2/_imoen.cre, 1156 bytes
Copied [l1npcs/template/imoen.cre] to [override/_imoen.cre]
Copying and patching 1 file ...
[l1npcs/template/imoen.cre] loaded, 2132 bytes
override/_imoen1.cre copied to L1NPCS/backup/2/_imoen1.cre, 1332 bytes
Copied [l1npcs/template/imoen.cre] to [override/_imoen1.cre]
Copying and patching 1 file ...
[l1npcs/template/imoen.cre] loaded, 2132 bytes
override/_imoen2.cre copied to L1NPCS/backup/2/_imoen2.cre, 1332 bytes
Copied [l1npcs/template/imoen.cre] to [override/_imoen2.cre]
Copying and patching 1 file ...
[l1npcs/template/imoen.cre] loaded, 2132 bytes
override/_imoen4.cre copied to L1NPCS/backup/2/_imoen4.cre, 1380 bytes
Copied [l1npcs/template/imoen.cre] to [override/_imoen4.cre]
Copying and patching 1 file ...
[l1npcs/template/imoen.cre] loaded, 2132 bytes
override/_imoen6.cre copied to L1NPCS/backup/2/_imoen6.cre, 1400 bytes
Copied [l1npcs/template/imoen.cre] to [override/_imoen6.cre]

...snip...

SUCCESSFULLY INSTALLED [Imoen as a Fighter]

Link to comment

Nythrun, is there an easier way of generating the base .cres other than creating a new <CHARNAME>, saving, and converting to .cre? Or if not, inserting a universal "dummy" entry that allows the patch to set this up so it doesn't use 0x00 (perhaps that is also why the first item was overwriting the version header).

 

The point of avoiding your wicked cool fully patching thing was to make it a project that everyone could contribute to without learning the heavy duty patching stuff, and stripping out all the extra spellbook work; that way a new kitmaker can simply send in a base .cre and say "use this!". Then a quick check in the override folder for A_I F_E_I_G ~flagfile~, and we have a "one size fits all" extendable mod that could allow creative freedom to anyone in the whole IE community, regardless of advanced coding proficiency.

Link to comment

Let me say, gained from recent experience, it is preferably to use "wicked cool fully patching thing" when creating CREs.

 

It is certainly preferably for spellbook allocation; doing weapon profs. and innates makes for even more happiness. Would it make life easier for making multi/dual classes?

 

BTW the spell allocations you see in the current Mage CREs was 'cause I choose "Pick for Me" at creation. We could keep those choices and reuse them as needed.

Link to comment

I need to read this thread in full when I'm not so tired, but for now:

 

This may or may not help:

 

When I create a CHR that I intend to convert to a CRE, I select the character and begin a new game of BG2. I use:

 

CLUAConsole:CreateItem('ITEMNAME')

 

to create desired items (in general, one for each equipped slot). Then I equip the items. I sometimes use:

 

CLUAConsole:SetCurrentXP('AMOUNTEXPERIENCE')

 

to set desired experience level. Then I export the character.

 

Then I convert the CHR to a CRE using NI. I make sure to uncheck the 'export allowed' flag.

 

The relevant result is that I can edit the item fields directly in my TP2. The base file is packaged with the mod, meaning that the file is static (unchanging; the item fields will always be in the same place). The most complex part of the TP2 for this component would be WRITE_LONG (or SHORT or BYTE or ASCII). Morrow Gate has a good example of this concept in action (see the Revised Amnian Guardsmen component).

 

If this helped: Great!

 

If not: I tried. :)

 

- D

Link to comment

Very much appreciated advice (Wounded Lion, right? )We will give it a shot both ways, too; either way, we can put together a readme entry detailing what people need to do to create their own base .cres so that we can add any mod-added kits etc. by checking for thekit and using the kitmaker's .cres.

Link to comment

To do list: anyne who can build sets of sample .cres and help out, please try Wounded Lion's appoach to build a "vanilla" .cre of several different kits, and mail to svowles at comcast dot net; Azazello, if you could run Nythruns' code on the chr files and check -- test version of tp2 is up on Wikki

 

in both cases, the .cre seems to come out needing to be reordered by DLTCEP (there is a post on this over at PPG where the Bigg looked at the .cre errors and diagnosed that the created .cres were definitely in nonstandard order). We need to try building the .cres from a multiplayer game, and work through this. Other than this point, the code looks like it will work, so I will post a concept code for changing Imoen into almost anything under the sun this evening (I' m stalled on BG1 NPC while we find out why banters are choking off before completion).

Link to comment

Good news and bad news... Using an exported multiplayer .chr, running Nythrun's code (removing the #32 from the ASCIIT 0x280 ~~ #32 :)) and then putting the resulting .cre through DLTCEP reordering results in a partial success.

 

Good: Using the code I am about to put on the Wikki, I was able to turn Imoen into a human Kensai with correct proficiencies, items, etc.

 

Bad: Imoen's Allow Export flag was still set, and changing her to a Half-Elven F/T and Half-Elven T/M resulted in unix errors --

 

ERROR: Unix.Unix_error(20, "stat", "L1NPCS/CRE/heTM.cre")

 

EDIT:

exporting the .chr, opening in DLTCEP, saving the reordered .chr, and running the code results in scrambled unreadable .cre files.

Link to comment

Yep, check the extensive testing done on that batch of code. Sorry.

 

I have two questions now :)

 

Do you get the "Creature will be reordered (harmless inconsistency)" message when you open a character in DLTCEP that's already been patched by the above? If not, it means you don't need to use DLTCEP - and if you do, it means that there's a variety of misordering that DLTCEP handles without nulling part of the header. This might help Avenger to track down this problem so it would be good to know :) I can always add a few more lines to that to cover missing spell memorization tables and the like (though it shouldn't be necessary for .chr conversion).

 

How on god's black and barren earth did I manage to generate an OS error on a system I don't even use? Unless Unix doesn't allow the ^^ operator.... Will it work if you use BXOR 0x800 instead of ^^ 0x800? Or BAND 0b1111011111111111 ?

 

// edit

 

Doesn't matter I suppose, easier to just use BAND 0xfffff7ff, it will save time tracking down why the flag isn't checked on an exported .cre.

 

// edit

 

Okay, phew. I thought you were getting Unix errors why running WeiDU...bigg loves Unix, I can't imagine the Unix port not supporting everything ;)

 

// edit (Hee!)

 

Other than the racial and animation fields, absolutely nothing should be differ between any of the races, the race-specific stuff is not stored on the creature.

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...