READ/WRITE for beginners

[Guest The_Swordalizer]

I have read enough tutorials to know that READ/WRITE is vital for good modding, however I am struggling with a few concepts. Here's a couple of examples from tutorials: Example 1: From kits tutorial:

 

CODE

COPY_EXISTING ~Viconi6.cre~ ~override~

~Viconi8.cre~ ~override~

~Viconi9.cre~ ~override~

~Viconi11.cre~ ~override~

~Viconi13.cre~ ~override~

~Viconi16.cre~ ~override~ // ToB only, see below on ACTION_IF

WRITE_SHORT 0x244 0 // doesn't change

WRITE_BYTE 0x246 ~%A#SHAR%~ // the internal name of your kit, surrounded by %

WRITE_BYTE 0x247 0x40 // doesn't change

 

Why WRITE_SHORT and BYTE the two values that don't change? Why not just use the middle one? Also, could you not use COPY_EXISTING_REGEXP ~Viconi*.cre?

 

Example 2: From the Weidu readme.

 

COPY_EXISTING ~acolyte1.cre~ ~override/acolyte1.cre~

READ_LONG "0x2bc" "itemsoffset"

READ_LONG "0x2b8" "itemslot"

READ_LONG "0x2c0" "#items"

READ_SHORT ("%itemslot%" + 0x04) "shield"

 

WRITE_SHORT ("%itemslot%" + 0x04) "%#items%"

WRITE_LONG 0x2b8 ("%itemslot%" + 0x14)

WRITE_LONG 0x2c0 ("%#items%" + 1)

 

INSERT_BYTES ("%itemsoffset%" + "%#items%" * 0x14) 0x14

 

WRITE_ASCII ("%itemsoffset%" + "%#items%" * 0x14) ~shld01~

 

IF_EVAL ("%shield%" = "65535")

 

So, you're READing the items offset to find out where the items start. You're READing the item slot to find out . And you're READing the number of items. You add 0x04 to get the shield slot and READ this aswell. You WRITE into the itemslot the number of items. You WRITE +1 items. You INSERT enough bytes to hold the shield and write in the shield.

 

Why can't you just READ the number of items, WRITE the number of items +1, get the offset for the shield from NI and WRITE_ASCII the shield into it? What is the importance of the additional functions?

 

Why do you have to get the Shield as "0xXXXX) + X?

[the bigg]

1st one: it's to make sure that everything goes to its place (standard game files are sometimes wrong).

 

2nd one: INSERT_BYTE is IMHO one of the most difficult part of WeiDU patching, so you can wait a bit before experimenting with that on your own.

The problem with all those readings are how the .cre file works (IESDP isn't totally clear on that). Basically, you need to add the 0x14 bytes and write in there some flags and the item name (itemsoffset + #items). After that, you need to add, into the inventory (itemslot) a reference to the new item. Reading the value in the shield is to avoid overwriting old shield. Reading the offsets, rather than using them from NI, is because you need to account for another mod adding other stuff (items, effects, spells) and altering the offsets from your setup.

BTW, that tutorial doesn't account for other structures needing to be shifted forward (effects for example, or bad ordering of structures in the file); for most parts, it's easier to use ADD_CRE_ITEM than to crawl through all of that stuff by hand (even though knowing how to do that is useful).

[CamDawg]

Why WRITE_SHORT and BYTE the two values that don't change? Why not just use the middle one? Also, could you not use COPY_EXISTING_REGEXP ~Viconi*.cre?

My philosophy when writing code is to never make assumptions about what's already there. It is unlikely that someone has changed the bytes at 0x244 or 0x247, but I'd rather include the two extra patches to be thorough and avoid bugs further down the road. Be very careful with regular expressions, especially in file matching--your example would match many more files than you might think: cdViconi.cre, Viconircre.itm, etc. (And yes, the item filename is invalid as it's not 8.3, it's just an example). If you wanted to use a regexp you should use ~^viconi[0-9]+\.cre$~ at a minimum, or even more strictly, ~^viconi\([689]\|1[136]\)\.cre$~. I prefer the methodology of listing the files independently, as it easily lets me see what I'm doing when I go back and review my code.

 

Example 2: From the Weidu readme.

It's a bit unfortunate that this is still in the WeiDU readme, as in general it features deprecated code (IF_EVAL) and its specific function has been more or less replaced by ADD_CRE_ITEM. As the bigg mentioned, there's also a good chance of file corruption since the patch is making assumptions about the order of headers within the file.

 

Why can't you just READ the number of items, WRITE the number of items +1, get the offset for the shield from NI and WRITE_ASCII the shield into it? What is the importance of the additional functions?

 

There are a few reasons to always read offsets and use those as a basis for where you patch the file instead of direct offsets. The simplest is that other mods may alter the same file, meaning you are no longer patching where you think you're patching. An even better argument is that it makes your code portable. For example, you can look up the offset for a single creature and write directly to that offset. If you wanted to do the same change to multiple creatures, you'd need to look up every one, write a new patch for each one, etc. By reading the offsets and patching intelligently, you would just add the file to the copy list instead, or you could extend the patch with a regexp. (This is also why, in the case of bits, it's better to alter a bit with BAND/BOR instead of overwriting the entire field with a static value.)

 

Take a look at file structures with NI and the IESDP. The best way to learn how to do this is to look at code, and lots of it. The Tweak Packs are some good examples of file patching, though it can get hot-n-heavy in a few places. The upcoming Fixpack will feature extreme byte-patching abuses (even by my standards) and will also serve as an excellent example of what can be done.

[Guest Guest]

Okay I'm gonna review a load of item files in NI (Gotta be the best combination of user friendly and powerful in any editor I've seen yet) and see if I can get my head round this. I haven't done any coding before so the whole offset thing is still new to me. Maybe it will get easier with practice.

 

Thanks all!