Pocket Plane Group
Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: smeagolheart on November 30, 2012, 10:35:19 PM
-
Anybody working on this? BG:EE is out and weidu doesn't work without workarounds.
-
It will come out on Tuesday.
-
Tuesday! God, I missed that phrase. :) And good to see you, naturally.
-
I still browse the fora (and sometimes even reply in a ME3 thread, or even something mod-related), but I'm afraid my BG2 modding days are over for the foreseeable future - and, unlike my earlier hiatuses, playing the game had no effect in getting me back in my modding mood.
-
unlike my earlier hiatuses, playing the game had no effect in getting me back in my modding mood.
What about a free copy of BG:EE? 'Cause I might be able to lend a hand, if that could help your modding mood ;)
-
The offer is nice. However, getting paid to mod (since this is what it basically would boil down) is not the same thing as actually wanting to mod.
-
Does this mean I had better get cracking on learning WeiDU's codebase? (Unless someone else wants to volunteer…?)
-
I'm pretty sure that's what it means.
-
Yeah, totally.
Wes had been on hiatus for just four months when I started tinkering!
-
Bigg, do you possibly have a windows compile of elkhound to share? Both Scott's and roy's sources fail with different errors at different stages and I really don't care enough for C++/ast/whatever to hunker down with some unmaintained freakshow long enough to sort it out.
-
I still browse the fora (and sometimes even reply in a ME3 thread, or even something mod-related), but I'm afraid my BG2 modding days are over for the foreseeable future - and, unlike my earlier hiatuses, playing the game had no effect in getting me back in my modding mood.
In such a case, thank you for all the years you've been maintaining WeiDU - twice as long as Wes, in fact! - and patiently answering stupid questions, some of them mine, about to get something very simple wprking :)
And yeah, I support Wisp's candidature for overtaking too.
-
Bigg, do you possibly have a windows compile of elkhound to share? Both Scott's and roy's sources fail with different errors at different stages and I really don't care enough for C++/ast/whatever to hunker down with some unmaintained freakshow long enough to sort it out.
https://www.dropbox.com/s/asua0vkh6irsc5o/elkhound.exe (https://www.dropbox.com/s/asua0vkh6irsc5o/elkhound.exe) - it requires cygwin, but you should already have that installed.
-
Thank you.
-
Well, the windows build environment seems a tad convoluted. After failing on the symlink cygwin provides for gcc, the build process now fails on "i686-w64-mingw32-gcc" during the linking. I notice FlexDLL/Flexlink requests that file, and that OVerbld provides a FlexDLL/Flexlink.
Bigg, do you know if this is like with OVerbld? A requirement that changed without making it into the documentation? Cygwin does not seem to provide it (although the FlexDLL docs mention it as part of cygwin).
-
Well, the windows build environment seems a tad convoluted.
I assume you never had the pleasure of J2EE...
Flexlink was added as an external dependancy to OCaml sometimes ago; last time I set up the build environment, I used Overbld.
-
Anyone working on this?
Stuff like ability to extract the new filetypes and accessing large bifs is needed.
-
Yes.
For a while longer, at least..
-
Well, I now have a mostly working win32 build environment ("mostly" because something is wrong with win32 WeiGUI's tk dependency). Naturally it was actually embarrassingly easy once the secret was uncovered.
Anyway,
what's on people's wishlist for 232? Unconventional biffs , (GAME|ENGINE)_IS and an update of the standard library of macros and functions are already in. I'm thinking of leaving parallel TLKs, UTF-8 conversions (libraries permitting) and BGEE saves (et al.) for 233, because it is potentially a lot of work and we want a new WeiDU now, now, now, now! Right?
-
Wisp - I'm not sure whether this makes a difference when it comes to WeiDU, or whether that's what you mean with "UTF-8 conversions", but the BG:EE game text makes use of non-ASCII characters (especially in foreign languages, but also in English). If this has an impact on WeiDU at any rate, could you add support for them?
-
Avenger mentioned something about the door arrays... without having to relist tons of code for each one. Same for the triggers I think.
-
what's on people's wishlist for 232? Unconventional biffs , (GAME|ENGINE)_IS and an update of the standard library of macros and functions are already in. I'm thinking of leaving parallel TLKs, UTF-8 conversions (libraries permitting) and BGEE saves (et al.) for 233, because it is potentially a lot of work and we want a new WeiDU now, now, now, now! Right?
Right.
-
what's on people's wishlist for 232? Unconventional biffs , (GAME|ENGINE)_IS and an update of the standard library of macros and functions are already in.
Does this include my patch functions (http://forums.pocketplane.net/index.php/topic,27532.msg330349.html#msg330349)? I'll live either way, I just want to know if I should start with documentation.
edit: fixed broken link
-
Well, I now have a mostly working win32 build environment ("mostly" because something is wrong with win32 WeiGUI's tk dependency). Naturally it was actually embarrassingly easy once the secret was uncovered.
Anyway,
what's on people's wishlist for 232? Unconventional biffs , (GAME|ENGINE)_IS and an update of the standard library of macros and functions are already in. I'm thinking of leaving parallel TLKs, UTF-8 conversions (libraries permitting) and BGEE saves (et al.) for 233, because it is potentially a lot of work and we want a new WeiDU now, now, now, now! Right?
Filetypes and large biffs are the most important for BGEE.
Well, utf8 strings is also very important.
-
Avenger mentioned something about the door arrays... without having to relist tons of code for each one. Same for the triggers I think.
This is not terribly important, but stuff like
FOR_EACH_DOOR BEGIN WRITE_LONG 0x40 1 END
etc. for any substructures and resource types where it is expected to be used. Probably there are already macros for some, or whatever. But a weidu noob like me has no knowledge about these.
Also REPLACE_TRANS_TRIGGER ...
meh, i don't know how any weidu user can live without explicitly targeting a trans trigger.
REPLACE_TRIGGER_TEXT is just outright lame
But again, these might already been somewhat handled by macros/etc and they are not comparable to large bif/new resource type support.
Hmm, looking at Cam's patch functions, i think that is roughly about the thing i mentioned here :)
-
Wisp - I'm not sure whether this makes a difference when it comes to WeiDU, or whether that's what you mean with "UTF-8 conversions", but the BG:EE game text makes use of non-ASCII characters (especially in foreign languages, but also in English). If this has an impact on WeiDU at any rate, could you add support for them?
Well, background for everyone's benefit: BGEE uses UTF-8 across the board, whereas the original editions use a multitude of different local encodings. The only commonality between UTF-8 and these other encodings is ACSII, so anything that is not expressible as ASCII will be interpreted incorrectly if it is in the wrong encoding. In practice, this means hassles aplenty for languages other than English, since BGEE requires that the translation is encoded in UTF-8, whereas the original editions require that the translation is encoded in, e.g., CP1252 (in the case of western-European languages). English doesn't escape entirely either, since some mods use dashes or ellipses or other non-ASCII characters.
The tentative plan is for WeiDU to automagically convert text into UTF-8 when the platform is BGEE, thus avoiding the nasty prospect of having to maintain multiple sets of TRA files whenever non-ASCII is used (and compatibility with both the EEs and the original editions is desired). The most likely hitch would be that the OCaml UTF-8 library (-ies) need to know which encoding the text should be converted from. Since TP2 language declarations are completely fluid, it would be very hard (and error prone) to deduce the encoding from that information. There is also the ugly practice of mixing several encodings in the same file and probably a number of additional complicating factors. If it goes in, I imagine this feature will require some sort of non-ambiguous declaration (e.g., you explicitly declare which encoding is used for the TRA file inside the TRA file itself, and if the file originally used multiple encodings, you need to split it apart into one file for each).
what's on people's wishlist for 232? Unconventional biffs , (GAME|ENGINE)_IS and an update of the standard library of macros and functions are already in.
Does this include my patch functions (http://forums.pocketplane.net/index.php/topic,27532.msg330349.html#msg330349)? I'll live either way, I just want to know if I should start with documentation.
edit: fixed broken link
I don't think the latter submissions in that thread have yet been included. But I can probably do it tomorrow.
Filetypes
What are the new file types? I've only got the numbers and they don't tell me much, I am afraid. (And if there was schooling to be had on the subject, I slept through the class.) Aside from being made recognisable types, is there anything else to be done?
-
This (https://www.dropbox.com/s/lfph4834caqnznc/BG2%20Modding%20TBD.html) is my BG2 TBD list (includes both WeiDU stuff and other mods). Hopefully that's useful.
There's no reasonable way to support ASCII, UTF-8 and whatnot, no matter the language and libraries used (not when you're dealing with disciplined people who know enough to use a proper text editor and save all their files in the same encoding, much less when people use a cracked copy of MS Word 2003 as their editor of choice). If anything, I'd embed an ad-hoc C++ utility and use it to overwrite local .tra files (doing ASCII -> UTF-8 for mods coded under Tutu and installed under BGEE, and viceversa).
-
Filetypes
What are the new file types? I've only got the numbers and they don't tell me much, I am afraid. (And if there was schooling to be had on the subject, I slept through the class.) Aside from being made recognisable types, is there anything else to be done?
0x400 .fnt font format (bitmap? didn't care)
0x403 .sql text format (semi script/some parts are csv), replace_textually is enuff for now
0x402 .gui text format (semi script), replace_textually is enuff for now
0x401 .wbm standard movie format
0x404 .pvrz compressed binary format (textures)
Of these, only .sql and .gui are something i would touch with weidu (but all should be known as resource type).
Btw, i was self taught in the subject, there is not school for this.
-
Anyway,
what's on people's wishlist for 232?
We may need a tp2 macro to patch DLGs. The existing .D syntax is just not enough when you want to match and compare the script string line by line before applying a patch. Gonna be quite complex, however, if it were to be any useful.
-
much less when people use a cracked copy of MS Word 2003 as their editor of choice
Shows what you know. Mine's a cracked coy of WordPerfect, so there!
We may need a tp2 macro to patch DLGs. The existing .D syntax is just not enough when you want to match and compare the script string line by line before applying a patch. Gonna be quite complex, however, if it were to be any useful.
Can you give an example? I've found the current .d syntax incredibly powerful for making changes.
-
Can you give an example? I've found the current .d syntax incredibly powerful for making changes.
ALTER_TRANSing in a state that may have been top- or bottom- appended with new transitions, i.e. when you may want to check what the trigger/action/text/etc. is before altering it blindly.
Also when you need to patch rather than overwrite the trigger/action - REPLACE_TRANS_ACTION/TRIGGER are quite good, but I recall lacking in freedom with it somewhere.
Basically, it's a compatibility thing. I mostly need it for the eventual Quest Revisions.
-
Okay, I built a new beta. Link (https://www.dropbox.com/s/mjm5y0sk52gl9t4/WeiDU-Windows-23106.zip).
Among other tricks, 231.06 can cope with Beamhauled biffs, unbiff the new file types and recognise BGEE for purposes of (GAME|ENGINE)_IS.
I didn't have time to go over the standard library, I'm afraid (and probably won't have until Thursday).
-
Small suggestion: if the game is BGEE and no override folder exists, create one?
Also, TLK location is still an issue.
Confirming that dialogue tokens now work with the new beta, thanks Wisp!
-
Okay, I built a new beta. Link (https://www.dropbox.com/s/mjm5y0sk52gl9t4/WeiDU-Windows-23106.zip).
Among other tricks, 231.06 can cope with Beamhauled biffs, unbiff the new file types and recognise BGEE for purposes of (GAME|ENGINE)_IS.
I didn't have time to go over the standard library, I'm afraid (and probably won't have until Thursday).
Thank you, Wisp. I will be testing it.
-
This (https://www.dropbox.com/s/lfph4834caqnznc/BG2%20Modding%20TBD.html) is my BG2 TBD list (includes both WeiDU stuff and other mods). Hopefully that's useful.
Thank you.
Small suggestion: if the game is BGEE and no override folder exists, create one?
Yes, I should put that in.
Also, TLK location is still an issue.
Yeah, and it will likely remain a problem for a while longer (but in the mean time, hardlinking the file is easy). Aside from adjusting the code to deal with multiple output TLKs without breaking existing functionality, there is also the matter of which TLK strings should be sourced from (for, e.g., the German who wants to decompile a DLG and get German text), the matter of the character encoding and possibly a few other issues that need to be, or should be, sorted out at the same time. All in all, it's a fair bit of work.
-
Hey, is there any reason *not* to distribute (.d|.baf|.tp2|.tpa) files for weidu for all target i.e. games using UTF=8 encoding, rather than ANSI? i know you are working on coversion, but if a modder throws down in UTF-8 it should be good for BG/Tutu/BG:EE/BG2/ToB/BG2:EE/IWD1|IWD2/PST, right?
-
The issue is languages. x86 Windows systems still use local code pages for display of text. While you can use UTF-8 for Mac/Linux stuff, it special characters will display funny in Windows.
-
Oh bother.
OK, so ANSI for encoding, and let weidu do the conversion.
-
The issue is languages. x86 Windows systems still use local code pages for display of text. While you can use UTF-8 for Mac/Linux stuff, it special characters will display funny in Windows.
I may be on the wrong page here - but is the issue how UTF-8 is displayed (or not) in some editing programs?
Because if that's the issue, Notepad++ handles UTF-8 - and it's free. I use it for all my scripting/coding and have done for probably decades.
Would telling folks to use Notepad++ help with this issue?
-
Would telling folks to use Notepad++ help with this issue?
Unfortunately, the point is not the editor people would use to write the tra files but the way the games handle character sets. And the fact that WeiDU shall operate with both older games and BGEE.
In older games, they only want ANSI, so UTF-8 characters wil become garbage in the games. Besides a few Eastern Europe languages use ANSI codes from Windows code pages (equivalent to their ISO-8859-X counterparts) to get their special characters displayed. So there is not a single ANSI encoding, but several. So conversion from ANSI to UTF-8 or from UTF-8 to ANSI is not a simple thing either, as it depends on the language.
For more on this topic, you may read this thread (http://forums.pocketplane.net/index.php/topic,28311.0.html) regarding a proposal to handle this with WeiDU and that topic (http://forum.baldursgate.com/discussion/12677/localisation-of-mods-for-bgee) explaining the issue with ANSI characters in BGEE.