Pocket Plane Group
Friends and Neighbors => Weimer Republic (WeiDU.org) => WeiDU => Topic started by: Wisp on November 09, 2014, 08:18:34 AM
-
WeiDU v237.00 "Something about the lateness" has been released.
Download for Windows (http://www.weidu.org/%7Ethebigg/WeiDU-Windows-237.zip)
Download for GNU/Linux (http://www.weidu.org/%7Ethebigg/WeiDU-Linux-237.zip)
Download for OS X (http://www.weidu.org/%7Ethebigg/WeiDU-Mac-237.zip)
Download the source code (http://www.weidu.org/%7Ethebigg/WeiDU-Src-237.zip)
Change log (http://weidu.org/~thebigg/README-WeiDU-Changes.txt)
Readme (http://weidu.org/~thebigg/README-WeiDU.html)
An OS X build will be up when it's compiled. The only changes since v236.04 are two bugfixes to ADD_AREA_REGION and fj_are_structure. Come to think of it, the former is not mentioned in the change-log, my bad (but it enables an advertised but previously non-functional feature).
-
Whoops! Here's the OSX build: https://www.dropbox.com/s/7q8uy0ra6oez1ng/WeiDU-Mac-237.zip
-
Uploaded. Thanks.
-
Bug report: FYI, when I try to install mods on IWDEE with Mac Weidu v237, it seems to fail updating dialog.tlk. Any new strings just show "INVALID: 40286" and such. The 236.04 beta worked better... but it didn't support "GAME_IS ~iwdee~"
So I'm on the horns of a dilemma over which to use, but my mods requires both of those features! These horns are uncomfortable!
OS X 10.8 Mountain Lion, IWD:EE via GOG, Weidu 237.
-
Make sure WeiDU and the game are configured to use the same TLK(s). WeiDU will print which TLK(s) is used during installation (you can find the info in your debug file).
-
Whoops! Somehow Weidu was "using language: English" but installed itself pointing to the German .tlk.
No bug here after all, good job guys!
-
The OS X build has been updated with statically linked versions of TISPack and MosPack, courtesy of StefanO.
-
Okay, I'm going to tentatively revive my bug report after all. After reading Wisp's post over at G3:
For whatever reason, it seems to be unusally common for people to install their mods in the wrong language on IWD: EE.
...and after seeing other similar reports like this:
http://forum.baldursgate.com/discussion/comment/579833/#Comment_579833
... I think that v237 is somehow defaulting to using German, or perhaps just defaulting to a different language than the one already chosen by the user when a weidu.conf has already been generated by an earlier version of Weidu. Easy enough to fix once you know what the problem is, but it's tripping up some users. FYI.
-
The "problem" is that WeiDU lists available game languages in alphabetical order which places German (de_DE) on first position. Many times people unconsciously press "0" if they want to select english. I've almost fallen for this as well when I tested my mod with one of the WeiDU betas.
One possible solution might be to fetch the game language from the baldur.ini (or use english by default if this entry doesn't exist) and put it on first position in the game language selection.
-
It wasn't a case of mistakenly pressing zero. What happened to me was, I had installed/uninstalled a bunch of stuff with Weidu v236, testing various versions of my own mod. I had chosen English as my language and it was using the English dialog.tlk.
Later, I simply deleted Weidu (I'm using OS X and keep a single copy of Mac Weidu, with various symlinks called "setup-modname" to install mods) ... deleted Weidu and replaced the file with the v236.04 beta. Installed/uninstalled a bunch of stuff, it all worked fine.
Then I once again deleted the file, and replaced it with v237, changing nothing else, and it started using the German dialog.tlk rather than the English one. I deleted weidu.conf, weidu.debug, weidu.log, and all symlinks and .log/.debug files associated with my mods, and upon running Weidu again it asked me for my language and I chose English.
Somehow replacing the file caused it to switch the language it was using. I don't know why, but a few people have had the same problem.
-
Can you reproduce? Can you check weidu.conf at regular intervals while you are doing so? When does it switch to "lang_dir = de_de" over whatever you had in there before?
-
I still have the older versions, I'll clean out my install, try to reproduce it, and report back.
-
Greetings.
Has anyone tried Weidu-237 for linux ? I didn't have any problems with 236 but i since i was doing a new bg2 installation i thought i should upgrade. I noticed two problems.
a) The amd64 version of weinstall segfaults on my box (the i386 one works ok)
b) tolower (both amd64 and i386 versions) instead of running recursively, only lowercases the first level of files. I ran tolower in the Big World Fixpack directory and while all the directories were correctly modified, none of the files within were modified.
Maybe there is something wrong with my linux setup but everything works correctly with 236 that is why i am posting. Has anyone else noticed any problems with the 237 linux build ?
Thank you for your time.
-
I'd like to make weidu available for mac users through macports. As I understand it, elkhound and ocaml are dependencies to build weidu. Ocaml is already available. I tried building elkhound on Mac OS X 10.9 (Mavericks) but it fails with bison 3 (something to do with the bison headers). I know the weidu source provides a pre-compiled elkhound, but the makefile for elkhound references bison 1.xx which is very old. For a macports distribution I would also need to provide a port for elkhound that can compile from source.
-
a) The amd64 version of weinstall segfaults on my box (the i386 one works ok)
What version and bitness of which distribution are you using?
b) tolower (both amd64 and i386 versions) instead of running recursively, only lowercases the first level of files. I ran tolower in the Big World Fixpack directory and while all the directories were correctly modified, none of the files within were modified.
Will fix. One of the recent optimisations broke the recursive descent.
-
a) The amd64 version of weinstall segfaults on my box (the i386 one works ok)
What version and bitness of which distribution are you using?
I use Slackware64-current (kernel 3.18.0, binutils 2.24.51.0.3, glibc 2.20).
If it helps you, dmesg mentions "error 14" as the cause for the segmentation fault
which according to arch/x86/mm/fault.c means "user-mode write (with reserved bit) that couldn't find a page".
All the amd64 binaries use GNU/Linux ABI whereas weinstall uses SYSV (though this shouldn't be a problem)
and all of them have no section headers except weinstall which has 2 section headers.
You can get this info by using the "file" utility or better by using "readelf" but i don't know if they help you
to identify the problem.
b) tolower (both amd64 and i386 versions) instead of running recursively, only lowercases the first level of files. I ran tolower in the Big World Fixpack directory and while all the directories were correctly modified, none of the files within were modified.
Will fix. One of the recent optimisations broke the recursive descent.
Thank you for taking the time to look at it.
-
I use Slackware64-current (kernel 3.18.0, binutils 2.24.51.0.3, glibc 2.20).
If it helps you, dmesg mentions "error 14" as the cause for the segmentation fault
which according to arch/x86/mm/fault.c means "user-mode write (with reserved bit) that couldn't find a page".
All the amd64 binaries use GNU/Linux ABI whereas weinstall uses SYSV (though this shouldn't be a problem)
and all of them have no section headers except weinstall which has 2 section headers.
You can get this info by using the "file" utility or better by using "readelf" but i don't know if they help you
to identify the problem.
All I can suggest is that you try compiling from source. However, bitness makes no practical difference for weinstall, so if the 32-bit version works, you may just as well use that.
-
All I can suggest is that you try compiling from source. However, bitness makes no practical difference for weinstall, so if the 32-bit version works, you may just as well use that.
Yes i use the 32bit binary now and it works fine that is why i didn't try to compile it from source. I will keep the 32bit binary (and tolower from 236) and upgrade everything to 238 when it is released.
Thank you.
-
I can't get it to work with IWD:EE on 64bit Linux...
The amd64 build of weinstall doesn't even run (apparently a segfault).
The i386 build runs, but curiously reports its version as 23600 and doesn't find the game's dialog.tk file:
$ weinstall bg2_tweaks
weidu --log setup-bg2_tweaks.debug bg2_tweaks.tp2 setup-bg2_tweaks.tp2 bg2_tweaks/bg2_tweaks.tp2 bg2_tweaks/setup-bg2_tweaks.tp2
[weidu] WeiDU version 23600
ERROR: Unable to find DIALOG.TLK in:
./^dialog\.tlk$
Please run this program in your Infinity Engine game directory.
FATAL ERROR: Failure("Unable to find DIALOG.TLK")
And explicitly specifying it does not seem to work either:
$ weinstall --use-lang en_US bg2_tweaks
weidu --log setup---use-lang.debug --use-lang.tp2 setup---use-lang.tp2 --use-lang/--use-lang.tp2 --use-lang/setup---use-lang.tp2 en_US bg2_tweaks
[weidu] WeiDU version 23600
weidu: unknown option `--use-lang.tp2'.
WeiDU (version 23600: "Your daily WTF")
usage: WeiDU [options] BAF,BCS,D,DLG,TRA,TP,TP2-files
...
$ weinstall --tlkin ./lang/en_US/dialog.tlk bg2_tweaks
weidu --log setup---tlkin.debug --tlkin.tp2 setup---tlkin.tp2 --tlkin/--tlkin.tp2 --tlkin/setup---tlkin.tp2 ./lang/en_US/dialog.tlk bg2_tweaks
[weidu] WeiDU version 23600
weidu: unknown option `--tlkin.tp2'.
WeiDU (version 23600: "Your daily WTF")
usage: WeiDU [options] BAF,BCS,D,DLG,TRA,TP,TP2-files
...
-
UPDATE: I managed to compile it from source, so now I have a 64bit weinstall that doesn't segfault and that reports its version as "23700". However, it still can't find the dialog.tlk, even when running weidu directly:
$ weidu --use-lang en_US bg2_tweaks/setup-bg2_tweaks.tp2
[weidu] WeiDU version 23700
[./chitin.key] 165 BIFFs, 37105 resources
ERROR: Unable to find DIALOG.TLK in:
./^dialog\.tlk$
Please run this program in your Infinity Engine game directory.
FATAL ERROR: Failure("Unable to find DIALOG.TLK")
-
UPDATE: I managed to compile it from source, so now I have a 64bit weinstall that doesn't segfault and that reports its version as "23700". However, it still can't find the dialog.tlk, even when running weidu directly:
$ weidu --use-lang en_US bg2_tweaks/setup-bg2_tweaks.tp2
[weidu] WeiDU version 23700
[./chitin.key] 165 BIFFs, 37105 resources
ERROR: Unable to find DIALOG.TLK in:
./^dialog\.tlk$
Please run this program in your Infinity Engine game directory.
FATAL ERROR: Failure("Unable to find DIALOG.TLK")
I can't get it to work with IWD:EE on 64bit Linux...
The amd64 build of weinstall doesn't even run (apparently a segfault).
The i386 build runs, but curiously reports its version as 23600 and doesn't find the game's dialog.tk file:
$ weinstall bg2_tweaks
weidu --log setup-bg2_tweaks.debug bg2_tweaks.tp2 setup-bg2_tweaks.tp2 bg2_tweaks/bg2_tweaks.tp2 bg2_tweaks/setup-bg2_tweaks.tp2
[weidu] WeiDU version 23600
ERROR: Unable to find DIALOG.TLK in:
./^dialog\.tlk$
Please run this program in your Infinity Engine game directory.
FATAL ERROR: Failure("Unable to find DIALOG.TLK")
And explicitly specifying it does not seem to work either:
$ weinstall --use-lang en_US bg2_tweaks
weidu --log setup---use-lang.debug --use-lang.tp2 setup---use-lang.tp2 --use-lang/--use-lang.tp2 --use-lang/setup---use-lang.tp2 en_US bg2_tweaks
[weidu] WeiDU version 23600
weidu: unknown option `--use-lang.tp2'.
WeiDU (version 23600: "Your daily WTF")
usage: WeiDU [options] BAF,BCS,D,DLG,TRA,TP,TP2-files
...
$ weinstall --tlkin ./lang/en_US/dialog.tlk bg2_tweaks
weidu --log setup---tlkin.debug --tlkin.tp2 setup---tlkin.tp2 --tlkin/--tlkin.tp2 --tlkin/setup---tlkin.tp2 ./lang/en_US/dialog.tlk bg2_tweaks
[weidu] WeiDU version 23600
weidu: unknown option `--tlkin.tp2'.
WeiDU (version 23600: "Your daily WTF")
usage: WeiDU [options] BAF,BCS,D,DLG,TRA,TP,TP2-files
...
Actually you're misplacing the options on weinstall without having specified a path for the .tlk. And when you ran WeiDU to set the language don't add any other parameters, because it won't make the --use-lang work that way. Also be sure you're in the path the contain the CHITIN.KEY file.
I would recommend doing this:$ weidu --use-lang en_US
$ weinstall bg2_tweaks.tp2
-
The amd64 build of weinstall doesn't even run (apparently a segfault).
Which version of what distribution are you using?
The i386 build runs, but curiously reports its version as 23600
That'd be because the 32-bit version you are using is v236. I have verified that the 32-bit build being distributed in the 237 package is actually v237, so kindly make sure you haven't made a mistake on your end. (As you may or may not know, IWD: EE is only properly supported by 237 and greater).
-
On Linux Mint 17.1 (equal to Ubuntu Trusty 14.04) I can confirm the amd64 binary returns is killed by SIGKILL immediately.
On all the binaries, that's the only one to fail. Using i386 is fine. *Might* have been caused by the fact that the PC it was compiled on had the following kernel value set to a non-default value:
http://cateee.net/lkddb/web-lkddb/DEFAULT_MMAP_MIN_ADDR.html
Can be checked easily:
$ cat /proc/sys/vm/mmap_min_addr
65536
That's the most common value I think. Might be worth to give it a try, Wisp (if it's you to compile the Linux version). But I'm just guessing.
-
Well, I suppose it is possible Debian Wheezy runs with a non-standard value. However, that system is sitting on my shelf at this time and I have no particular plans on hooking the drive back up (so I won't be checking). It's also the same system all 64-bit binaries in recent memory have been compiled on. FWIW, my current workstation (Fedora 21) uses the standard value.
-
There is problem with corrupted DLG files with latest XPmod. Angel says that it is Weidu's fault.
Bug report with logs is here:
http://forums.pocketplane.net/index.php/topic,29333.msg336456.html#msg336456
Thanks!
-
It's harmless, as demonstrated by the fact it's existed since forever (the empty action DO bug). But I'll fix it all the same, because it's a ridiculous.
-
Thanks Wisp!
-
Actually, I'll get back to you. The DLG produced by WeiDU is structurally valid. This can equally well be a false positive by NI, but it's bed time now. Edit: the issue remains ridiculous. regardless.
-
It looks like all of the affected DLG files contain one or more script structures (i.e. state trigger, transition trigger or action table structures) with their "Length" field set to 0. The DLG format definition (http://gibberlings3.net/iesdp/file_formats/ie_formats/dlg_v1.htm) in IESDP is open to interpretation in this matter, so I'm not sure if these are valid structures or not.
Near Infinity is treating these cases as invalid and I haven't found a DLG file affected by this issue in any unmodded game yet. On the other hand, the games don't seem to crash or behave unusual when triggering the affected dialogs. I can try to add a fix or work-around in Near Infinity, but I don't know if or when I'll be successful as it touches a fundamental design aspect of NI. Maybe WeiDU's dialog compiler can be changed to preserve empty script structures by adding a single newline or space character.
-
Next WeiDU will output DLGs as monotonically increasing structures, which satisfies both NI's assumptions as well as backward compatibility.
-
The "problem" is that WeiDU lists available game languages in alphabetical order which places German (de_DE) on first position. Many times people unconsciously press "0" if they want to select english. I've almost fallen for this as well when I tested my mod with one of the WeiDU betas.
One possible solution might be to fetch the game language from the baldur.ini (or use english by default if this entry doesn't exist) and put it on first position in the game language selection.
I have had this issue as well (with v238) that I press 0 by reflex when the language dialogue comes up, so I had to manually modify the wiedu.conf file as I was getting strange <invalid reference>s when installing mods.
Another possible solution is to switch to using letters (ie "e" for english, "d" for german, etc.) instead to force the user to read through the text.
-
I am working on making this menu obsolete.