Discussion: Changing Class/Race/Kit Restrictions with WeiDU

[Andyr]

Hang on... So, can we do this for new kits (eg to permit Clerics weapon usability for their deity's favoured weapon)?

[CamDawg]

Again, yes and no. Kits are additionally restricted by the true class usability restrictions. So to give a cleric kit access to axes would require giving true class clerics acess to them as well.

 

The other problem is that there are a total of 32 kit usability bits, all of them in use. (This is the biggest reason why it's a lot easier to use an existing set of item restrictions than try to make new ones.) There are a few that you could free up (i.e. kits that have the same restrictions as true class) but it's only a handful. I used this method in the SP Collection kits; you could take a look to see how I hacked around it. For example, the druid kit Archer of Sylvanus has access to bows and crossbows. To do this I had to use these hacks:

 

* Changed the Undead Hunter kit to use generic paladin item restrictions, "freeing" the Undead Hunter usability bit for my own purpose

* Set the Archer of Sylvanus to have generic ranger restrictions plus Undead Hunter restrictions (using ranger as a base instead of druid meant I didn't have to give all druids access to bows, though it does mean the restrictions are not perfect in terms of druid items)

* Changed any item that should be unusable to the kit to be flagged as unusable by Undead Hunters

 

However, there are only a few kit usability flags you could "free up" in this fashion, since there are only a few kits that have true-class restrictions. The three cleric kits, Undead Hunter, and Inquisitors. Changing Inquisitors, though, will likely lock Keldorn out of using his own armor and sword. The thief and bard kits also come with some hard-coded abilities so they can't be changed to true class either.

[Andyr]

Right, I see. Never mind then.

[CamDawg]

Yep, it's a pain. It means that item usability changes are not an effective tool for balancing kits, which is a shame.

[Andyr]

(It may help you to look at a .DLG file such as ARAN.DLG response 179 as you look at this)

 

Ok, I'm going to direct you people to this thread: http://www.teambg.net/forum/?board=20;acti...t=0;boardseen=1

 

So I can use these bitwise operators to check if there's a journal entry there, and then alter it as I want.

 

I don't know binary, though. From what I gather (well, mainly what Ghrey has told me) 4 bytes consist of 32 bits. They are read from right to left. So if I want to check that a journal entry is set (byte 4 = 1), what that means is the bits look like:

 

00000001 00000000 00000000 00000000

 

Is that right?

 

And if I want to set bit 8 (which I think means Done Quest) I put a 1 in the 8th position from the right, so:

 

00000001 00000000 00000000 10000000

 

Is this correct?

 

If so, what happens if I want to set Bit 31 (unknown meaning), as that's already set to 1 by byte 4 being 1?

 

Coming on MSN/IRC to chat to me could be useful. Or just confusing. One of the two.

[CamDawg]

I don't know binary, though. From what I gather (well, mainly what Ghrey has told me) 4 bytes consist of 32 bits. They are read from right to left. So if I want to check that a journal entry is set (byte 4 = 1), what that means is the bits look like:

 

00000001 00000000 00000000 00000000

 

I know it's confusing... the bits do read right to left, but the bytes still read left to right. So the order of bits in this is actually:

 

7-6-5-4-3-2-1-0 15-14-13-12-11-10-9-8 23-22-21-20-19-18-17-16 31-30-29-28-27-26-25-24.

 

From what I can gather from this and your post over at TBG, I think you're actually looking for bit 4 in the first four bytes of response 179 for Aran, yes? The bytes 0x1DA4, 0x1DA5, 0x1DA6, and 0x1DA7. If you look at it with NI, you see that flags 2, 3, 4, and 6 are set. In hex, this is equivalent to the value of 0x5C000000, or in binary, 0b01011100 00000000 00000000 00000000.

 

If you wanted this to be flagged as a completed quest (bit 8) rather than bit 4, it would be 0b01001100 00000001 00000000 00000000. I think you were also asking about the unknown bit, bit 5? In that case, it would be 0b01101100 00000000 00000000 00000000.

[Idobek]

So you want to scan every response in every dialogue to see if bit 4 of the flags is checked and, if it is, check bit 6?

[Andyr]

Idobek: Well, I can do each manually.

 

Ideally, if you can just tell me what the should look like with a Journal entry set, and then with bits 6/7/8 set too that'd be great, and I can puzzle the rest out.

 

Also, check your PMs. Thanks for the responses! Cam, your post helped. But I'll need to read it a few more times.

[CamDawg]

When you see something as "flagged" or "checked" in NI, it means that the corresponding bit is set to 1. So if a dialogue transition has check marks in, for example, action (2), terminates dialogue (3), and journal entry (6), it's equivalent to 0b01001100 00000000 00000000 00000000. Compare this to the bit order in my previous post and it may make sense.

[Andyr]

Much of the confusion has gone, I wasn't reading the IESDP completely correct. You've all been most helpful, thanks.

[Ghreyfain]

So what is the exact command you're going to use?

 

From reading the explanation on kits above, I think BOR is what we want to use, since if a flag is already set, we want it to remain set, and if it isn't set, we want to set it to how it shall be.

 

 

COPY_EXISTING ~aran.dlg~ ~override~ // Looking at the journal entry for response 102

READ_BYTE 0x1514 "resflag1" // This is the first byte of the dialogue response flags. We want to make sure flags 4 and 7 are checked

WRITE_BYTE 0x1514 ("resflag1" BOR "0b01010000")

READ_BYTE 0x1515 "resflag2" // This is the second byte of the dialogue response flags. We want to make sure flag 8 is checked

WRITE_BYTE 0x1515 ("resflag2" BOR "0b10000000")

[Andyr]

So, what I need to do seems to be this:

 

-Work out which flags I need setting for an entry.

-Work out what this is in binary: Bytes numbered left-right, bits right-left.

-Convert to hexadecimal with NI.

-Reverse it, as pairs.

-WRITE_LONG this at the appropriate offset.

 

[CamDawg]

Using a READ/WRITE_LONG will result in a lot of zeroes you don't need. You can use Ghrey's code as an example: he's only writing to the single bytes with WRITE_BYTE rather than a WRITE_LONG. You could even combine the two commands with a single WRITE_SHORT:

 

COPY_EXISTING ~ARAN.DLG~ ~override/ARAN.DLG~
 READ_SHORT 0x1514 "flags"
 WRITE_SHORT 0x1514 ("%flags%" BOR 0b0101000010000000)

 

If you did the same with LONG, it's the same effect, but a lot more zeroes:

 

COPY_EXISTING ~ARAN.DLG~ ~override/ARAN.DLG~
 READ_LONG 0x1514 "flags"
 WRITE_LONG 0x1514 ("%flags%" BOR 0b01010000100000000000000000000000)

[Idobek]

The problem is that if someone has changed the file (BG1 Banter Pack, for example) your offset is going to be wrong.

[Andyr]

Yeah, though I can convert the binary value to hexadecimal and write that. So sayeth NI, Ghrey and Idobek. I don't need to check for what's already there, just do something like:

 

COPY_EXISTING ~ARAN.DLG~ ~override/ARAN.DLG~

WRITE_LONG 0x8e4 0000005e