jastey Posted July 31, 2013 Share Posted July 31, 2013 Is there like a list of things that I have to keep in mind when making my mods BG:EE compatible (I don't dare to ask for a tutorial)? Just because BG2:EE is cancelled doesn't mean the BG1 mods shouldn't be compatible with BG:EE, right? Quote Link to comment
CamDawg Posted July 31, 2013 Share Posted July 31, 2013 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. Quote Link to comment
jastey Posted July 31, 2013 Author Share Posted July 31, 2013 (edited) 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 July 31, 2013 by jastey Quote Link to comment
CamDawg Posted July 31, 2013 Share Posted July 31, 2013 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. Quote Link to comment
Wisp Posted July 31, 2013 Share Posted July 31, 2013 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). Quote Link to comment
Kulyok Posted July 31, 2013 Share Posted July 31, 2013 And I'd love that tutorial for dummies HANDLE_AUDIO, please(=how to use it, where to put the command, why it's better, and most importantly, how to use it and not screw up everything). Quote Link to comment
CamDawg Posted July 31, 2013 Share Posted July 31, 2013 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. Quote Link to comment
Wisp Posted July 31, 2013 Share Posted July 31, 2013 (edited) 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 July 31, 2013 by Wisp Quote Link to comment
jastey Posted July 31, 2013 Author Share Posted July 31, 2013 (edited) 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 July 31, 2013 by jastey Quote Link to comment
Kulyok Posted August 1, 2013 Share Posted August 1, 2013 Oh, that's very simple and absolutely cool, thank you! (I'll wait with the updates until the version's stable, but I will use this command). Quote Link to comment
Echon Posted August 8, 2013 Share Posted August 8, 2013 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. That would be highly appreciated. Quote Link to comment
jastey Posted September 3, 2013 Author Share Posted September 3, 2013 Some more useful info: http://forums.pocketplane.net/index.php/topic,28596.0/topicseen.html Putting this here because this thread I will find if I need it.. Quote Link to comment
Austin Posted June 6, 2020 Share Posted June 6, 2020 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? Quote Link to comment
Gwendolyne Posted June 6, 2020 Share Posted June 6, 2020 Yes! This function automatically converts .ogg files to .wav if installed on a classic game, and rename .ogg files to .wav with EE games. Quote Link to comment
Austin Posted June 6, 2020 Share Posted June 6, 2020 1 hour ago, Gwendolyne said: Yes! This function automatically converts .ogg files to .wav if installed on a classic game, and rename .ogg files to .wav with EE games. This is amazing! Thank you so much! Quote Link to comment
Recommended Posts
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.