8 replies to this topic

[igi]

Hi again,
Another quick question ( I hope). I'm putting my mod together, I've integrated all the separate things into the 1 tp2 file, I've written + patched in the descriptions, I've added the itms into the game containers, patched a few areas, and now I'd like to add a few items to pre-existing stores.

For example, say I want to add a new scroll to Lady Yuth, in the Adventurers Mart. If I add my item to the .sto file, and compare this with an original copy, I can see what data needs to be put in the .sto when I am patching it, and the offset to patch to.
Then, I can use COPY_EXISTING to get the the .sto file (scrolls.sto).

Thats as far as I get... do I use WRITE_BYTE, WRITE_LONG, WRITE_SHORT, WRITE_ASCII? How long is a short? The data to patch is " iiscr01

" (the blank spaces are null when viewed in hex). Is it a short length? Or 2 shorts? Or a long? Short usually seems to be 4 characters, but sometimes 5. I dont recall a Long example anywhere. And the only ASCII I saw was in Valens tp2, for a protrait on a cre.
I guess I could use several WRITE_BYTE, but it hardly seems optimal.

So.. clarification (ok.. help :-) please
/bt_igi

[japheth]

You can actually get WeiDU to emit the WRITE_BYTE's for you.

Example:

We'll call the new store file "storenew.sto" and the old store file "storeold.sto".

Browse to the directory where WeiDU is located, (you probably should just put the .sto files in the same directory as well to make it easier on yourself) and issue this command on the command line:

weidu --cmp-from storeold.sto --cmp-to storenew.sto>file.txt

WeiDU will figure out which bytes need to be written and then pump them out to "file.txt".

Then you just take those write bytes and copy+paste them into your .tp2 file.

[igi]

Thanks japheth, thats a bit of a help. It appears the two files have to be the same size for that to work, but its not too hard to pad a file with blank data.

But, I do have a problem... it seems really unreliable. I added an item to scrolls.sto, blanked the original file up to the same size, and the compared the files, and put that data in the tp2. Then I tested it, and it all worked fine.

So, I moved onto the next store, did the same, but it woudlnt run, (setup-mod.exe was giving errors about empty lex strings or something). So.. i tried again, and got the same error. So I deleted that section from the tp2, and tried it with just the scrolls store again, and that was refusing to work (setup-mod.exe ran through the tp2 until that point, but then chucked up an error, patch failed on COPY_EXISTING or something).

So... I deleted the lot, and redid the scrolls store, tested it, and it worked. Then I moved onto a different store (not the one from the previous example), and exactly the same thing happened, with that store not working, and somehow corrupting a previously working scrolls.sto.
So.. I'm a little stumped. Is it valid to have:

COPY_EXISTING ~scrolls.sto~ ~override/scrolls.sto~
  WRITE_BYTE 10 10
  .....
COPY_EXISTING ~other.sto~ ~override/other.sto~
  WRITE_BYTE 1 19
  .....

Its driving me mad! It seems to work sometimes and not other. If I make a new tp2, and put the code in there (using the write_bytes from the file generated in the comparison), which used to work, then stopped working after attempting another .sto, it refuses to work straight off.
Any help, suggestions, criticism or comments welcome..
/bt_baffled_igi

[japheth]

Well, another option would be to nab WinHex off of http://www.winhex.com

You can use it's compare option to figure out how many bytes you need to insert and to figure out which bytes need to be written.

I used it quite a bit when I was writing the .tp2 code for the Baldurdash Remix.

Email me your updated scrolls.sto to rene_heroux@yahoo.com and I'll write out the code for you if you get really stumped.

[weimer]

The code you quoted should work. Why don't you send me a copy of the code that doesn't work that you think should work and I'll look into it.

By the way, it might just be easier (and less likely to cause bugs) to make a whole new store file (using NI, say) and then change Ribald's dialogue action (or whomever) so that they do StartStore(mystore) instead of StartStore(ribald).

There's some REPLACE_ACTION_TEXT command or something that may help you there.

[igi]

japheth - I've e-mailed you the files, I would be so greateful if you could sort them out :-)

weimer - I've e-mailed you the code, let me know if I'm an idiot :-)

When I couldnt get it to work as I wanted, I cut back the amount of stores my items were to be available in, and gave them a "pile of new scrolls" like Ribalds "special items", (ie. a 2nd dialog option with a new store), which is a fair enough solution.
So the emergency is over, but I'd still like to know why write_byte wasnt working for me, as if I could sort it, I could have more than 2 people selling my spells :-)
Anyway, thanks for the time, let me know how things go.
/bt_igi

[japheth]

Okay, this is weird. It's patching the store and everything correctly every time, but for some reason, when I try and patch item descriptions in for your items it's adding characters to the dialog.tlk rather than 4 separate strings.

Here's the code anyways for your first store:

BACKUP ~backup~
AUTHOR ~you@me.com~
BEGIN ~Store Trials~

COPY ~blah/iiscr01.itm~ ~override/iiscr01.itm~
SAY NAME1 ~Super Duper Scroll~
SAY 0x50 ~This scroll is super!~
SAY NAME2 ~Scroll of Monkey Slaying~
SAY 0x54 ~This is the renowned scroll of monkey slaying.~


COPY_EXISTING ~scrolls.sto~ ~override/scrolls.sto~
INSERT_BYTES 0x7f4 28
WRITE_BYTE 0x2c 0x0c
WRITE_BYTE 0x2d 0x08
WRITE_BYTE 0x38 0x44
WRITE_BYTE 0x4c 0xb8
WRITE_BYTE 0x70 0x0c
WRITE_BYTE 0x71 0x08
WRITE_BYTE 0x7f0 0x69
WRITE_BYTE 0x7f1 0x69
WRITE_BYTE 0x7f2 0x73
WRITE_BYTE 0x7f3 0x63
WRITE_BYTE 0x7f4 0x72
WRITE_BYTE 0x7f5 0x30
WRITE_BYTE 0x7f6 0x31
WRITE_BYTE 0x800 0x01
WRITE_BYTE 0x804 0x02
WRITE_BYTE 0x80c 0x0b

So I ran that, and then WeiDU said this:

109 characters added to the dialog.tlk

I checked the item file in NI after installing the tp2 and for long name, short name, identified desc and unidentified desc it seems that the references are pointing to the correct places, it's just that the strings aren't there.

So then, to take it a step further, I tried doing it with an existing item from BG2 just to make sure that his item file wasn't screwed up and I had the same results.

Perhaps a bug Wes?

[weimer]

Did you remember to say "--tlkout"? Perhaps you can quote your exact command line and what WeiDU said as it ran.

[japheth]

Heh, oh dear.

I've been installing and uninstalling Baldurdash so many times, I forgot that --tlkout was required when your doing it right from the commandline.

I suppose it was a good way to waste a Friday afternoon though, hehe.