Gender fixes

[devSin]

I'm absolutely positive that assigning STATE_SLEEPING to the CRE before loading prevents dialogue here. Without launching NI, I looked at my TP2, and I don't change the dwarf flag, which means he must not have STATE_SLEEPING by default (I already zero it for the AM* sleepers, only two of which are used, and for the wounded elf in Suldanblah), so I'm not sure what y'all are looking at...

[CamDawg]

I'm absolutely positive that assigning STATE_SLEEPING to the CRE before loading prevents dialogue here. Without launching NI, I looked at my TP2, and I don't change the dwarf flag, which means he must not have STATE_SLEEPING by default (I already zero it for the AM* sleepers, only two of which are used, and for the wounded elf in Suldanblah), so I'm not sure what y'all are looking at...

Added STATE_SLEEPING tag to sleepdw. Started new game. Went to CC. Both sleeping dwarves are clickable and have their dialogue (such as it is).

[devSin]

I may check again someday, but I'm sticking with it not working here.

 

Unless you have an EXE hack (i.e., the charm dialogue hack), it must be a Mac or ToB beta patch thing.

[CamDawg]

Could you (or one of our other OS X players) fire it up and check for sure? I don't want to add something that's going to break on OS X.

[aVENGER_(RR)]

Cam, I noticed that you are using READ/WRITE_BYTE in your code. Shouldn't that be READ/WRITE_LONG or did I misinterpret the WeiDU docs?

 

Use READ/WRITE_SHORT for anything that is two bytes. You can determine this easily by looking at the field you want to change in NI and subtracting the next listed field’s offset from the offset of the field you want to change.

 

For example, if I wanted to change Bodhi’s Max HP here’s what I would do. First look at her creature file in NI. (She has many, but for the sake of argument, we’ll use bodhi.cre). If you look at the Max HP field, it says it’s offset is 26h. The next field in the creature file is Animation ID, which is 28h. So, subtracting 28h from 26h gives you 2h. The perfect WRITE_SHORT size.

 

Use READ/WRITE_LONG for anything that is 4 bytes. Use the above example to figure this out as well.

 

Use READ/WRITE_BYTE for anything that is one byte. Again, use the above example to figure this out.

 

By reading that passage, I kind of figured that 24h - 20h = 4h meaning that I should use READ/WRITE_LONG. Admittedly, I'm only marginally familiar with the rules for hexadecimal subtraction, so it's entirely possible that I missed something here.

[devSin]

Bytes and bits. Because it's binary (8 characters 0b76543210 per byte), if you wanted to do all four bytes of the field, you'd need a 32-character binary number! It can be represented as a hex (8 characters) or decimal number, but you're still working with a bitfield instead of a value (you can write 0x100000F there, but you're concentrating on the bits of each byte, so it's "Byte1> 1 + 2 + 4 + 8; Byte2> 0; Byte3> 0; Byte4> 1" that you care about and not whatever that number equals in decimal)...

 

Luckily, the only bits we care about fall into determined bytes, so it's easier just to deal with the single byte (in this case, the first of four) where the flags you want to alter are. Using the bitwise operators on the original value ensures that we're not losing the original flags (if state were 1 in the code, %state% BOR 0x2 is 3 or 0b00000011 -- the original 0b00000001 is preserved and the new bit 0b00000010 set); you can always just patch bitfields a single byte at a time.

 

Could you (or one of our other OS X players) fire it up and check for sure?

I won't be able to check in-game for quite some time still, but I'm positive that it doesn't work here. I'd prefer independent verification anyway since I may have funky settings (the force dialog pause?) that might affect it.

[CamDawg]

Cam, I noticed that you are using READ/WRITE_BYTE in your code. Shouldn't that be READ/WRITE_LONG or did I misinterpret the WeiDU docs?

The bits in which we're interested are in that first byte. If I can get away with being lazy and only read/write one byte, I go for it. You'll see similar shortcuts if you look through the code where we patch item usabilities. The main usability block is four bytes (0x1e - 0x21), but we only read the specific byte with the flag in which we're interested.

[aVENGER_(RR)]

The bits in which we're interested are in that first byte. If I can get away with being lazy and only read/write one byte, I go for it.

 

Thanks for the clarification. I suppose this speads up the intall process a bit?

 

You'll see similar shortcuts if you look through the code where we patch item usabilities. The main usability block is four bytes (0x1e - 0x21), but we only read the specific byte with the flag in which we're interested.

 

Yeah, but I also noticed a few oddities like:

 

// why is a statue chaotic evil?
COPY_EXISTING ~shaava01.cre~ ~override~
 WRITE_BYTE 0x27b 0 // alignment: none
 BUT_ONLY_IF_IT_CHANGES

 

By the aforementioned logic, shouldn't this be WRITE_SHORT since Alignment is at 0x27b and the next field (Global ID) is at 0x27c?

[Miloch]

By the aforementioned logic, shouldn't this be WRITE_SHORT since Alignment is at 0x27b and the next field (Global ID) is at 0x27c?

Alignment is just the byte at 0x27b. If you wrote a short (2-byte) value, you'd be overwriting the next field, which probably isn't too cool.

[aVENGER_(RR)]

Alignment is just the byte at 0x27b. If you wrote a short (2-byte) value, you'd be overwriting the next field, which probably isn't too cool.

 

Heh, right. For some weird reason, I though that WRITE_SHORT would actually be shorter than WRITE_BYTE. My bad.

[CamDawg]

The bits in which we're interested are in that first byte. If I can get away with being lazy and only read/write one byte, I go for it.

 

Thanks for the clarification. I suppose this speads up the intall process a bit?

The speed difference between WeiDU reading/writing one byte as opposed to four is neglible. It's really to simplify the code. Compare:

 

COPY_EXISTING ~sw1h46.itm~ ~override~ // wakizashi
		  ~sw1h47.itm~ ~override~ // wakizashi +1
		  ~sw1h66.itm~ ~override~ // yamato +4
 PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // protects against invalid files
READ_BYTE  0x21 "use"
WRITE_BYTE 0x21 ("%use%" BOR 0b01000000) // adds druid flag
 END
 BUT_ONLY_IF_IT_CHANGES

 

against

 

COPY_EXISTING ~sw1h46.itm~ ~override~ // wakizashi
		  ~sw1h47.itm~ ~override~ // wakizashi +1
		  ~sw1h66.itm~ ~override~ // yamato +4
 PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // protects against invalid files
READ_LONG  0x1e "use"
WRITE_LONG 0x1e ("%use%" BOR 0b00000000000000000000000001000000) // adds druid flag
 END
 BUT_ONLY_IF_IT_CHANGES

One of those is a lot easier to work with.

[devSin]

Thanks for the clarification. I suppose this speads up the intall process a bit?

To be pedantic, the _LONGs should actually outperform _BYTEs (we're talking milliseconds, of course).

 

It's all about 8 character binary vs. 32 characters, like Cam says.

[devSin]

// gender fixes
COPY_EXISTING ~YSMAGE02.CRE~ ~override~
 WRITE_BYTE 0x0275 2 // female
BUT_ONLY_IF_IT_CHANGES

She needs to be unrolled (we're screwing up the EXTRACOUNT by changing from EXTRA3 to FEMALE).

 

COPY_EXISTING ~DDGUARD1.CRE~ ~override~
 WRITE_BYTE 0x0275 4 // neither
BUT_ONLY_IF_IT_CHANGES

I'm sure these guys are thrilled that in addition to cloning them we're lopping off their man bits. Unroll.

[devSin]

Could you (or one of our other OS X players) fire it up and check for sure? I don't want to add something that's going to break on OS X.

I'll need to test this more (I'm absolutely sure the sick elf was broken before), but it looks to work with one of the each sleeping* animation characters I tried.

 

That said, it seems completely pointless? These characters aren't being picked up by StateCheck(who,STATE_SLEEPING), so I'm not sure what the benefit of setting the flag is? aVENGER?

[aVENGER_(RR)]

That said, it seems completely pointless? These characters aren't being picked up by StateCheck(who,STATE_SLEEPING), so I'm not sure what the benefit of setting the flag is? aVENGER?

 

In RR, I've modified various alarm scripts to prevent sleeping (and otherwise incapacitated) characters from calling the guards when someone steals an item in their vicinity and I think BGT does something similar as well. As long as a character is properly flagged as STATE_SLEEPING he won't call the guards, but since the SoA sleeping creatures are not flagged as such (contrary to the ToB sleeping creatures) they can still summon the guards in the unmodded game.

 

I summary, I suggested that all sleeping creatures should be flagged as such mainly for consistency's sake.