Is there a really ridiculously simple new item creation weidu tutorial?

[bholland]

Okay, so I am a software engineer, I get almost all of the concept except one. How and where is the TLK file modified? I can create all of the items I want in NI and I can put them into a folder with my mod name and I have something which defines how the item is installed (the TP2) file. What I don't get is how to inject my own strings in dialog.tlk. I believe only the string references are saved in the itm file. I don't know how to link up any string (mostly name and description) so that weidu knows that my item is called "The Great Staff of Kickass" with the description about how my new and ingenious staff does in fact kick ass. I don't see why this would be done in a .d file and I don't know how it fits into a tp2 file.

 

Basically I am looking for a really really simple, step by step guide to creating (not editing an existing item but actually creating) a brand new item with a different name and description than any string which currently exists in the tlk file and THEN install it with weidu.

 

One would think this is something which is written up but I have been looking for a week and found nothing this simple... compiling a dialog script, yea but item creation seems a bit trickier.

 

Thanks for the help... yes this is a total NOOB question and yes I am total NOOB when it comes to bg2 modding but I have an idea for an interesting mod and I think I might want to try programming it up in a bit but it most likely will take a long ass time since the learning curve seems a bit steep.

 

~Ben

[Mike1072]

The SAY command is used most often for this. It adds the string to dialog.tlk and then writes the strref that was assigned to the given position in the file.

 

COPY ~yourmod/youritem.itm~ ~override~
 SAY UNIDENTIFIED_DESC ~i wonder what this thing does... durpy doo~
 SAY DESC ~oh man it's a sweet axe or something~

 

There are other ways to add things to dialog.tlk: REPLACE and RESOLVE_STR_REF.

[pro5]

You don't normally create item with new strings already in place, instead you put the strrefs when installing the mod - using SAY as above. Because the values of those strrefs are going to depend on the user's current dialog.tlk (they're appended after the last existing tlk entry).

[bholland]

Thanks for the really straightforward answer. So then is this sort of like python? There is a COPY block and a tab or two spaces link all of the lines in the block to that specific item or it is even simpler that there are a set of commands which will not break the block and the block ends on either EOF, COPY or another top level command?

 

Also, is there an API for the tp2 files? I realized just now on the weidu website that copy desc existed and most likely changed the description of the item. I am wondering if there is a list of the commands like COPY and set of attributes which change like NAME NAME2 (Whatever this is) DESC, etc.

 

Edit: NM, I finally figured out what the TP2 API does... now how about an API of what I assume are item offsets.

[Wisp]

Thanks for the really straightforward answer. So then is this sort of like python? There is a COPY block and a tab or two spaces link all of the lines in the block to that specific item or it is even simpler that there are a set of commands which will not break the block and the block ends on either EOF, COPY or another top level command?

TP2 has "actions" and "patches". Some actions (such as COPY) open a patch scope. Patches are only syntactically valid in a patch scope. Any subsequent action or when clause closes the patch scope.

 

now how about an API of what I assume are item offsets.

The IESDP has detailed information on almost all relevant file formats.

[bholland]

Hi Wisp, thanks for that really useful link. I am going to read it more in depth in a bit. What I think I am after is a list of the WeiDU offset aliases.

 

The SAY command apparently takes an offset and a string so when you do something like

 

SAY NAME ~This is the name~

 

NAME in this case is an alias for what I assume to be hex code 0x0C for the identified name. It also appears (using NI) that there are a whole lot of these things, which I know from reading about modding on other resources and particularly item creation, which all have the same offset for every item. It makes sense if the items are basically a struct with a bunch of pointers or int's for flags. I also assume that WeiDU takes these offsets and somewhere creates aliases or constant names for them so that NAME is actually going to be put into the .itm file. Typically these would be either #DEFINE or some set of global constants or an ENUM or a struct someplace. I am just wondering if there a comprehensive list of the aliases for the hex addresses that WeiDU uses.

 

I ask this because in the example on WeiDU there is something called NAME2 which I would never have guessed existed unless someone told me and I am guessing that there are a lot more like this. Things like UNIDENTIFIED_DESC I would not have guessed either.

 

Oh, in another note... I really think it is interesting how all of this fits together. I have not figured out biffs yet but other than that, this coding style is really really old and extremely outdated. It however, is really simple to write, modify, edit, pickup, and change. It is almost like BGII was not written using OO principles. For example, every single string and dialogue is in one massive file which is basically an array with each string addressed. That destroys encapsulation but makes it very easy to write. Hell, I might even put up a "My First Mod" which is basically a mess of items which I sort of feel are missing and work on getting an NPC to walk up to you and do something. It seems like that is a really decent first step.

[Jarno Mikkola]

NAME in this case is an alias for what I assume to be hex code 0x0C for the identified name.

This is the case for items. And other files...

To understand this a little better, weidu.exe actually modifies the game folders dialog.tlk file, which is where all the text in the game is stored, it's shown in the game as an index number, so what ever you write to the SAY NAME ~text~ , the bolded part gets put to the dialog.tlk file, and it gets a new string variable(the number) that's then stored into the actual file game file, so the editors and the game itself reads that number and then shows you the part in the dialog.tlk .

 

I am just wondering if there a comprehensive list of the aliases for the hex addresses that WeiDU uses.

The weidu's .tp2 can handle hex addresses as they are, so instead of: SAY NAME ~xyz~

You can use: WRITE_LONG ~0x0008~ ~xyz~

The "LONG" comes from the fact that the variable the in the itm files size is 4, "SHORT" goes for the 2 size, "BYTE" is 1 size, and "ASCII" is 8 sized variables.

There are predefined hexa values for, SAY NAME1, SAY NAME2, SAY DESC, SAY UNIDENTIFIED_DESC for items, there's in addition SAY BIO for creatures. Their names should spell out what they are. And I have not seen the any other spelled out in anywhere, as the weidu's readme just list those, and other reference files (SNDSLOT.IDS or SOUNDOFF.IDS), yes that's creature editing.

Of course the WRITE_* -commands have other connection functions such as READ_* commands that can be used to make impressive results eventually... but I won't bother you with them as this is about editing simple definitions for the game files, as I assume you are making the items with a file editor and then define them in the .tp2 file. Yes, the .tp2 commands can make you every item in the game and more if that's wanted, but it's going to take a lot of understanding to get that far. And the topic has the word "simple" in it...

 

I have not figured out biffs yet but other than that, this coding style is really really old and extremely outdated. It however, is really simple to write, modify, edit, pickup, and change.

Well, you have not learned the fact that everything in the world can be put to two distinctive sets, the "easy", and the "simple", that's it. That doesn't mean though that everything simple, is easy, nor the reverse. It's easy to make complex systems out of simple materials, and rip them apart, but try to make a simple system out of complex materials is a lot harder, and ripping it apart will simply crash the whole thing.

 

Now the .bif files can be described as archive files, files that contain other game files, it's where all the .itm files are actually in the game that has not been modified that are not in the override folder.

The good thing for us is that unlike in .rar files or .zip files, the game can read the .bif files in the games engine, and it does this faster than from the override folder.

 

Sorry for the wall of text. NOT !

[Mike1072]

The SAY command apparently takes an offset and a string so when you do something like

 

SAY NAME ~This is the name~

 

NAME in this case is an alias for what I assume to be hex code 0x0C for the identified name. It also appears (using NI) that there are a whole lot of these things, which I know from reading about modding on other resources and particularly item creation, which all have the same offset for every item. It makes sense if the items are basically a struct with a bunch of pointers or int's for flags.

That's right. Check out the IESDP section on File Formats for details on what data is stored at what offset. I usually use the hex offsets rather than the WeiDU constants for stuff other than names and descriptions. I just open the IESDP to the page for the file type I'm working on so I know what's what.

 

I also assume that WeiDU takes these offsets and somewhere creates aliases or constant names for them so that NAME is actually going to be put into the .itm file. Typically these would be either #DEFINE or some set of global constants or an ENUM or a struct someplace. I am just wondering if there a comprehensive list of the aliases for the hex addresses that WeiDU uses.

It's in the WeiDU readme here but there are only constants set for a few of the most commonly used offsets.

 

instead of: SAY NAME ~xyz~

You can use: WRITE_LONG ~0x000c~ ~xyz~

The equivalent to SAY NAME1 ~xyz~ would be SAY 0x08 ~xyz~.

 

Edit: getting a little more off-topic...

The "LONG" comes from the fact that the variable the in the itm files size is 4, "SHORT" goes for the 2 size, "BYTE" is 1 size, and "ASCII" is 8 sized variables.

It makes most sense to match your WRITE_ to the size of the field you are writing to. Using WRITE_BYTE 0 0 to a 4-byte field would not necessarily give the result you were expecting, but it is possible because WeiDU knows very little about the IE file structures.

 

WRITE_ASCII is used to write a number of ASCII characters to the file. Most ASCII fields are 8 characters long because they are used to reference the resource name of another file, so WRITE_ASCII writes 8 characters by default. There are cases where they are smaller (item animations are 2 characters) and larger (death variables are 32 characters) and you can tell WRITE_ASCII to write a different number of characters if you need to.

[Jarno Mikkola]

The equivalent to SAY NAME1 ~xyz~ would be SAY 0x08 ~xyz~.

Ahh.. corrected... by the way, was I dreaming or as I saw that the SAY NAME itself doesn't work on a few files as it needs the number NAME1 on it ? ... as there are a bunch of tutorials that don't mention it. Or have I been seeing things ?

[bholland]

Oh thank you so much for all your help! I can't believe that I missed that with all the constants. Very interesting about the structures. I am guessing regarding the NAME and NAME1 that WeiDU puts another alias where NAME=NAME1=0x08 or something like that. I have seen a ton of tp2 files which just have the name as the example.

 

Also yes, I gathered that there is some real power behind the tp2 but I am so not even close to getting there yet.

 

Actually, with all of this really really useful info, it seems like this would be ripe for a tutorial about basic item creation and then assign that item to a store.

 

See... this is why this modding is difficult. Everything is connected and you can't just unravel a tiny piece of it. The biff is connected to the itm files which are all connected to the tlk file and the tp2 files. That means to do something very trivial, you need to know about hex offsets, strings, how strings work in memory space, why references are used in the tlk file, what your override file actually does, how to create items in NI, what various flags do, why offsets exist, how offsets work within the context of the different files, and lastly how to use weidu to automate the install.

 

This "simple" process requires quite a lot of ramping up but once understood, is sort of flexible for many purposes.

 

Thanks for the heads up that I am in 32bit space and that int = 4bytes, short = 2bytes and byte = 1. Typically int and long are the same but that comes from wayyyyy back.

 

I will say this about the easy vs. simple. Putting all of your strings into a single file is very simple. You have an array, each element has a pointer to a string which is most likely defined as a global constant or even worse, the array is an array of constant string literals. That is very easy to setup but extremely complex to maintain. A much harder but much more robust way would be to encapsulate each string either within the object which says the string (like an NPC), the item, or the area. Each object would have its own set of strings with various properties like (said to) or the like. This is actually much simpler to setup (or at least as difficult) but has the added bonus that you don't need to worry about managing a giant array of strings. This giant array of strings (I assume) has a ton of duplicates just from modders and the devs being unsure which reference of the string they were suppose to use and better safe than sorry so new string with a new reference it goes. Encapsulation has the huge benefit though of one object or install or override not totally destroying your single giant array of strings. Order becomes a lot less important. Of course, that sort of change to a system would basically break everything but man, that is a shame because now we need special tools to handle a single giant (essentially db table) for us. I am really quite happy the tools exist but damn if this is not all a mess to figure out.

[Ardanis]

This giant array of strings (I assume) has a ton of duplicates just from modders and the devs being unsure which reference of the string they were suppose to use and better safe than sorry so new string with a new reference it goes. Encapsulation has the huge benefit though of one object or install or override not totally destroying your single giant array of strings.

WeiDU automatically checks the TLK before adding a new string, so if it already exists then that strref will be used instead of creating new one. For the last ten years modding is quite safe from duplicate entries.

[Avenger]

This giant array of strings (I assume) has a ton of duplicates just from modders and the devs being unsure which reference of the string they were suppose to use and better safe than sorry so new string with a new reference it goes. Encapsulation has the huge benefit though of one object or install or override not totally destroying your single giant array of strings.

WeiDU automatically checks the TLK before adding a new string, so if it already exists then that strref will be used instead of creating new one. For the last ten years modding is quite safe from duplicate entries.

 

Sometimes too safe I remember Belt (the npc) and Belt (the item).

[Ardanis]

Hmm, pretty sure BG came out several years before WeiDU did, so the original dev team couldn't have taken advantage of its features...

[Avenger]

Hmm, pretty sure BG came out several years before WeiDU did, so the original dev team couldn't have taken advantage of its features...

No, i meant, they needed to be separate, because of translations.

Weidu's string merging actually messes translations up.

[bholland]

That is quite the feat! Thanks everyone! BTW, I just created the first baby mod with english translation. Thanks to you all for the massive assist. It was actually quite easy once well... I went here. Now for something a bit more... challenging.