Jump to content

How do I make my mod BG:EE compatible?


jastey

Recommended Posts

No joke, I really was going to sit down and write one this week.

 

The big things are really that all of the resources match their BG names (i.e. Beregost is ar3300) but the tlk is different than BG or BG2, so you should be very careful with straight string references like SAY #1234.

 

Journal entries are another issue that needs attention. Any journal entry not listed in the bgee.sql file will show up in the dialogue window, but not in the actual journal. The new system is needed so that all related journal entries coalesce under a unified, collapsible header. Wisp's coding up a new WeiDU function to make this easy.

 

Finally, any item descriptions shouldn't have the 'usable by/unusable by' blocks on them. The EE engine generates those directly from the underlying item. I detect EE (file check for OH1000.are for BGEE, oh6000.are for the forthcoming BG2EE) and load an alternate tra file with just the item descriptions without the usable blocks--see the item component of SP Collection, for example.

 

So if you've got, say, a mod that works on BG/BGT/Tutu, using the BGT/Tutu code with the BG resources set as variables will get you a very good had start.

Link to comment

Thank you! I wouldn't mind seeing this tutorial. ;)

As soon as Wisp finishes the new journal-entry-function I would be very interested in knowing about it.

 

A question to the "usable/unusable by" descriptions: But I guess the engine wouldn't know things like "only usabel by NPC XY"?

 

So, if I use the OUTER_SPRINT for vanilla BG, adjust the item description and live with the fact that journal entries are not written into the journal, my mods would be directly compatible? No cre/itm/spl/are sort of compatibility problem, patching of 2das etcpp? I thought it's more complicated than that. What was the BG:EE compatibility problems the weidu beta versions were created for?

Edited by jastey
Link to comment

As soon as Wisp finishes the new journal-entry-function I would be very interested in knowing about it.

It's been in the beta for a few builds, I believe.

 

A question to the "usable/unusable by" descriptions: But I guess the engine wouldn't know things like "only usabel by NPC XY"?

Good and bad news here. There's a new EE-specific opcode that lets you set an item to actually be uniquely usable by an NPC; no more futzing around with trying to match the NPC's stats and class exactly with the existing usable flags. The bad news is that you'll have to detect-and-apply the new opcode at install time (or keep two items). Let me double-check my dev docs on that and come up with something.

 

So, if I use the OUTER_SPRINT for vanilla BG, adjust the item description and live with the fact that journal entries are not written into the journal, my mods would be directly compatible? No cre/itm/spl/are sort of compatibility problem, patching of 2das etcpp? I thought it's more complicated than that. What was the BG:EE compatibility problems the weidu beta versions were created for?

A lot of game resources and settings are not where WeiDU expects it--the tlk is down two folders in lang/en_us; there are multiple tlk files for multi-language support; saves are located in the user's folder instead of the local save and mpsave folders; ini files are now actually SQL, etc. For modders, most of this will be handled internally by WeiDU, so you don't have to actually care that these resources have moved and/or changed.

 

There are a lot of new 2das that are basically softcoding of previously hardcoded features, but (so far at least) you shouldn't need to mess with them unless you're trying something really weird with a new kit.

 

One of my goals is to try and pull together all of our EE developer docs so that we can get all of this into the IESDP.

Link to comment

Yeah, ADD_JOURNAL has been in since the last few betas.

I would also recommend the HANDLE_AUDIO function for your sounds, if any. I don't know how the situation with tilesets is on BGEE, but if you can just untiz them like normal, there will also be the HANDLE_TILESETS function (coded, but not included in beta 231.10).

Link to comment

Yeah, ADD_JOURNAL has been in since the last few betas.

I would also recommend the HANDLE_AUDIO function for your sounds, if any. I don't know how the situation with tilesets is on BGEE, but if you can just untiz them like normal, there will also be the HANDLE_TILESETS function (coded, but not included in beta 231.10).

EE supports normal TIS files as well as a new super-compressed PVRZ format--which at present, no modding tools can handle.

 

I'll be happy to take the new HANDLE_foo stuff for a spin with Tweaks. It now has a tileset with the NORH stuff, and a couple of wavs I never bothered ogg'ing since it was too much overhead for two files. If WeiDU can now do that natively, I will.

Link to comment

HANDLE_AUDIO and HANDLE_TILESETS are not (yet) natively done by WeiDU. They are (thus far) wrapper functions around oggdec/SoX and tisunpack.

 

The big advantage is that you get compatibility with Windows, OS X, Linux and BGEE all in one go. Everything but decompression is also done by WeiDU, so you also get proper backups and proper uninstallations. All you need to do is supply the audio/tilesets and oggdec for Windows, SoX for OS X and tisunpack for Windows, OS X and optionally Linux.

 

For HANDLE_AUDIO, you put your audio, oggdec.exe and SoX for OS X in "MyMod/audio". Then, anywhere in the component that should install the audio, you put

LAF HANDLE_AUDIO END

and you are done. If you'd rather do things differently, say, by putting your sounds and decompression utilities in "MyMod/sound", you would put this in your TP2:

LAF HANDLE_AUDIO STR_VAR audio_path = "mymod/sound" END

The way HANDLE_AUDIO is coded, you don't need to specify the location of oggdec/SoX (you can, if you want to) unless they are located somewhere other than the same folder where you keep your sounds. Compatibility with BGEE is free. You don't need to do a thing. Compatibility with Linux is practically free. If you want to, you can state that the user should install oggdec before installing your mod, but you don't need to do anything else.

 

HANDLE_TILESETS works much the same. Analogously to audio, you put your TIZ files in "MyMod/tiz". The exception is that you put tisunpack for Windows in "MyMod/tiz/win32" and tisunpack for OS X in "MyMod/tiz/osx". If you want to, you can also put tisunpack for Linux in "MyMod/tiz/unix". Then you include

LAF HANDLE_TILESETS END

in your TP2 and you are done. If you want to put your TIZ files elsewhere, that part works the same as with HANDLE_AUDIO (except it's tiz_path instead of audio_path).

 

(For Tweaks, there is probably not yet much advantage to these functions, since Tweaks already does it right.)

Edited by Wisp
Link to comment

Thank you very much for your answers.

CamDawg: I don't have a NPC-only item, I think. It was one of my theoretical questions. But the answer could be interesting for others, of course.

 

New areas with new tis, sounds, etc: I don't have, either. This will be interesting for BG2:EE, in my case.

 

But I do re-use existing tis for "new" areas (mainly to have them empty when needed).

Edited by jastey
Link to comment

Please tell me - do I understand correctly that if I replace the old command to set sounds (with bat files) with

LAF HANDLE_AUDIO END

(and do as described in this thread), will this work in both the EE and the old (vanilla) versions of the game?

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...