Beta 236.03

[Wisp]

Beta location. Mac version will be uploaded when I get one. Mac version is up.

New:

• Fix bug where the wrong TLKs were loaded if --game pointed to an EE-type game.
• Make BG(2): EE checks more general.
• Preliminary/speculative compatibility with IWD: EE.
• Documentation of GAME_IS does not state TOLM is a synonym for TOTLM.
• WeiDU prints the subcomponent group name in addition to the component name where applicable.
• In ambiguous engine checks, WeiDU prefers BGII: EE over BG: EE.
• Add EET to GAME_IS.
• Support SetGlobalTimerRandom().

Plus fixes for regressions.

[Almateria]

New problem with compiling, I blame the new xcode.

Code: [Select]

Error: Could not find the .cmi file for interface batteries-lite/batList.mli.
cp: batteries-lite/batList.cmi: No such file or directory
cp: batteries-lite/batList.o: No such file or directory
make: *** [obj/x86_LINUX/batList.cmx] Error 1

[Wisp]

Can you post the preceding part of the output. There is probably some reason why batlist fails to compile (and as I think it's the first file, something is probably off in your build environment).

[Argent77]

New problem with compiling, I blame the new xcode.

Code: [Select]

Error: Could not find the .cmi file for interface batteries-lite/batList.mli.
cp: batteries-lite/batList.cmi: No such file or directory
cp: batteries-lite/batList.o: No such file or directory
make: *** [obj/x86_LINUX/batList.cmx] Error 1

Did you upgrade OCaml to v4.x? This version caused trouble with a similar error message on my machine before I downgraded to v3.12.1.

[Almateria]

Can you post the preceding part of the output. There is probably some reason why batlist fails to compile (and as I think it's the first file, something is probably off in your build environment).

This is the entire output after make osx_zip. I recently installed Yosemite beta 4 and the new xcode, think that might be it?

[Wisp]

Did you upgrade OCaml to v4.x? This version caused trouble with a similar error message on my machine before I downgraded to v3.12.1.

There is no inherent problem with compiling current WeiDU with OCaml 4.01. It's what I use on Windows.

The most straightforward explanation of this error is that make is not finding your OCaml compiler and when it tries to proceed it fails because one of the required files (generated by the compiler) is missing.

This is the entire output after make osx_zip. I recently installed Yosemite beta 4 and the new xcode, think that might be it?

Make sure the locations of your OCaml binaries and Elkhound are present on your system path (check it with echo $PATH). There should definitely be more before anything involving batlist, both from OCaml and from Elkhound. You can also try opening a terminal and invoking e.g, ocaml --version and/or elkhound (without arguments). If the former prints the version of your installed OCaml and the latter prints usage instructions for Elkhound, it's not that they're missing from your path, at least.

[Almateria]

Turns out I had to reinstall both ocaml and opam. Oh well.

http://www.mediafire.com/download/spq42vhwf4jjnwb/WeiDU-Mac-23603.zip

[Wisp]

Uploaded. Thanks.

[AL|EN]

Trying to install worldmap on BG2:EE:

Installing [Rozszerzona mapa swiata dla Baldur's Gate - wlacznie z kolorowymi ikonami miejsc dla Baldur's Gate] [v10.0.2
]
Copying 1 file ...
Creating 1 directory
Copying and patching 1 file ...
ERROR: error loading [%fl#area_table%]
Stopping installation because of error.
Stopping installation because of error.
Stopping installation because of error.
Stopping installation because of error.
ERROR Installing [Rozszerzona mapa swiata dla Baldur's Gate - wlacznie z kolorowymi ikonami miejsc dla Baldur's Gate], r
olling back to previous state
Will uninstall   1 files for [SETUP-BP-BGT-WORLDMAP.TP2] component 0.
Uninstalled      1 files for [SETUP-BP-BGT-WORLDMAP.TP2] component 0.
ERROR: Unix.Unix_error(20, "stat", "%fl#area_table%")
PLEASE email the file SETUP-BP-BGT-WORLDMAP.DEBUG to www.shsforums.net/forum/401-worldmap/
Using Language [Polish]

everything is fine when I use 236.02

[Wisp]

I can't reproduce. Can you check that GAME_IS detects your BGII: EE as BGII: EE? Anything like

Code: [Select]

ACTION_IF GAME_IS bg2ee BEGIN
  PRINT works
END
will suffice.

(Notably, games that are detected as EET will no longer detect as BG(II): EE and Worldmap needs to be updated, but that's not a WeiDU problem. Whoops, looks like I left that out of the change log. Will fix.)

[K4thos]

Thank you Wisp for all the work you have done on weidu. Here is a modified version of the worldmap with EET detection (2 files: tp2 + original.tpa): https://www.sendspace.com/file/1fvr1p

I will test other fixed weidu commands later today and give feedback if everything is working fine.

[AL|EN]

Trying to install worldmap on BG2:EE:

My bad, its EET. No weidu problem, as you say.

[K4thos]

--traify-tlk is still broken when used with AT_NOW command. This time it's the --use-lang portion. Try this on BG2:EE tp2:

Code: [Select]

AT_NOW ~weidu.exe --noautoupdate --no-auto-tp2 --logapp --log "test/bash.debug" --game "C:/Program Files (x86)/BeamDog/Games/00766" --use-lang "en_US" --traify-tlk --out "test/bgee.tra"~it will traify the BG:EE TLK file just fine.

Now use the same command but with "pl_PL" instead of "en_US":

Code: [Select]

AT_NOW ~weidu.exe --noautoupdate --no-auto-tp2 --logapp --log "test/bash.debug" --game "C:/Program Files (x86)/BeamDog/Games/00766" --use-lang "pl_PL" --traify-tlk --out "test/bgee.tra"~the TLK files within 00766/lang/pl_PL won't be traified.

edit: the HANDLE_CHARSETS issue I've reported before was related to the case sensitivity when creating custom "charset_table" VAR. It looks like names of language directories typed in "charset_table" must lower cased, even if you are using upper cases in folder names. For example:
"en_US" => "CP1252" will give an error, but this will work fine: "en_us" => "CP1252"
Not really a problem, just need to be mentioned in the readme file.

-----

this error has not been fixed:

ERROR: BIFF [C:\Program Files (x86)\BeamDog\Games\00766/DATA/AREA0900.BIF] has tileset entries 0--0, cannot extract tileset at entry 0 (this BIFF and your KEY file don't match)

[AR0900N.TIS] --biff-get error: Failure("invalid biff tileset entry")

[K4thos]

edit: need a little more testing.
ok, there is a huge problem unless I'm missing something. Please download this test mod: https://www.sendspace.com/file/qogzk4
Extract it in BG2:EE and install it. You will see correctly unbiffed BG:EE BALDUR.GAM file within test directory. Uninstall it.

Now go to BG:EE directory, make a backup of the whole dir, and then use this bat file: https://www.sendspace.com/file/wrptyk

Go back do BG2:EE directory and try to install the test mod once again. You will receive this error:

Code: [Select]

ERROR: None of the dialog paths were a match against pl_pl
FATAL ERROR: Not_foundFrom now on you will always get this error when trying to access BG:EE dir from BG2:EE unless you restore the BG:EE copy from a backup.

edit:it seems to be related to weidu.conf located in BG:EE. In BG2:EE only english language is supported and weidu probably once again confuses folders giving error that should not occur - BG:EE has pl_PL directory. That would be my guass.

[Wisp]

the TLK files within 00766/lang/pl_PL won't be traified.

Fixed. Stupid code was checking validity against the working dir.

edit: the HANDLE_CHARSETS issue I've reported before was related to the case sensitivity when creating custom "charset_table" VAR. It looks like names of language directories typed in "charset_table" must lower cased, even if you are using upper cases in folder names. For example:
"en_US" => "CP1252" will give an error, but this will work fine: "en_us" => "CP1252"
Not really a problem, just need to be mentioned in the readme file.

Yes, the lookup is case-sensitive and for sanity it is done in lowercase. You're right it should be documented.

this error has not been fixed:

I know. Most likely I won't have time to look at it until after 237.

[Wisp]

edit:it seems to be related to weidu.conf located in BG:EE. In BG2:EE only english language is supported and weidu probably once again confuses folders giving error that should not occur - BG:EE has pl_PL directory. That would be my guass.

I can't reproduce. Possibly because this is the same error as the one I've already fixed.

[K4thos]

sounds promissing. Now I hope that no one will post any more bugs, so the next beta will come soon enough Once again thanks for the effort.

[CrevsDaak]

Wisp, the OSX version Almateria compiled won't work in any other OS than OSX 10.9 and Yosemite :\
Would you like me to compile WeiDU for OSX 10.6, 10.7 and 10.8?

[Almateria]

It's not my fault for trying to stay on the World's Most Advanced Operating System

[The Imp]

Would you like me to compile WeiDU for OSX 10.6, 10.7 and 10.8?

I think the answer to all of those is YES ! Even I, a PC user knows this.
Also making a one for each on the v23600 would be appreciated by some. I say each as I have no idea if they are compatible with the other OSX versions, so ... cause like said, I won't be using any of them.

[CrevsDaak]

Would you like me to compile WeiDU for OSX 10.6, 10.7 and 10.8?

I think the answer to all of those is YES !

OK here it is: https://www.dropbox.com/s/izc33ca20yhcwt7/WeiDU-Mac-23603.zip?dl=0
Still there's the need for someone to compile WeiDU on a PPC mac and someone to test if it runs on 10.6.

It's not my fault for trying to stay on the World's Most Advanced Operating System

I know. It's great that someone compiles weidu on Yosemite

[Wisp]

Thanks, CrevsDaak. How do you wish to be credited?

If binaries produced on older versions of OS X work on the most recent versions (and reportedly they do), I'd much prefer to be able to distribute a single, reasonably universal binary (i.e., the one built on older OS X). Assuming you, CrevsDaak, is not averse to continuing to provide builds?

[Almateria]

Should I make a melodramatic post about being discarded now, or later?

[CrevsDaak]

If binaries produced on older versions of OS X work on the most recent versions (and reportedly they do), I'd much prefer to be able to distribute a single, reasonably universal binary (i.e., the one built on older OS X). Assuming you, CrevsDaak, is not averse to continuing to provide builds?

Yes, I can continue provide builds without any problems, I'm glad I could help!
I don't think what I compiled would run on 10.9 or newer but it's just a matter of testing so (it does work on 10..

Thanks, CrevsDaak. How do you wish to be credited?

I'd like to be credited as Nicolás Clotta aka Crevs Daak.

Should I make a melodramatic post about being discarded now, or later?

My compiled binaries won't run on Yosemite (unless they actually do), so you should continue compiling for newer OSX versions.

[Wisp]

Should I make a melodramatic post about being discarded now, or later?

Your stepping in when it was needed is appreciated. Thank you.