Post reply

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.
Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
What color is grass?:
What is the seventh word in this sentence?:
What is five minus two (use the full word)?:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: Wisp
« on: August 02, 2013, 05:50:06 PM »

Why did you strike out the 2nd part of your response? Because that would be exactly what's needed - is it in progress still?
Because I decided a usage example was more relevant. SAVE_DIRECTORY has been implemented since January, well, March.
Posted by: Miloch
« on: August 02, 2013, 04:15:28 PM »

Should be valid everywhere except BGEE on Linux, and maybe not on all configurations of BGEE on OS X, if there are more than the one I have been told of.
For not-BGEE, that's just ./save and ./mpsave, otherwise:
The location of "My Documents" is read from the registry on Windows. On OS X, the location of $HOME is read from the user database (to the effect of getpwuid(getuid())->pw_dir). In all cases, a compile-time constant is appended to arrive at the directory where BGEE stores its user files (and then /save/ on top of that to arrive at the save dir). I am not absolutely super sure about OS X. I have had it told it works, but it seems the location of the BGEE dir also varies with version of OS X and whether you bought the game from Beamdog or through the MAS, or something.
(On Linux and BGEE, it's ./save and ./mpsave, just as with not-BGEE, because it makes it easier for me. When/if BGEE is officially available, it'll use the same system as OS X).
Why did you strike out the 2nd part of your response? Because that would be exactly what's needed - is it in progress still?
Posted by: Wisp
« on: July 26, 2013, 07:54:52 PM »

Alright, let's talk idiot-proofing. Will the user be prompted at every mod install for tlk selection, or just the first? If it's just the first and the user selects the wrong option, how do they go back and change it?

I'd suggest just prompting once (for convenience) and storing the selection in the commented-out top of weidu.log. Users who need to change this in the future can force a new choice by deleting the relevant line out of weidu.log.
Currently it asks once per BGEE/BG2EE/OTHEREE, provided WeiDU was not told which lang to use on the command line. The result is stored in the same dir that BGEE stores baldur.ini in, as weidu.conf. Output language can be changed on the command line (which everyone loves) or by deleting weidu.conf or editing its contents.

If it's thought to be better, I might be able to swing the tlk selection being an uncommented part of weidu.log. Storing it commented is no good, because the parser disregards comments and I would have to do truly, horrendously bad things to it to have it otherwise.
Posted by: CamDawg
« on: July 26, 2013, 05:42:02 PM »

Alright, let's talk idiot-proofing. Will the user be prompted at every mod install for tlk selection, or just the first? If it's just the first and the user selects the wrong option, how do they go back and change it?

I'd suggest just prompting once (for convenience) and storing the selection in the commented-out top of weidu.log. Users who need to change this in the future can force a new choice by deleting the relevant line out of weidu.log.
Posted by: Wisp
« on: July 26, 2013, 03:36:16 PM »

We've been discussing it elsewhere and I think the best solution is the simplest one for now. If we need complexities (e.g. mass STRING_SET padding) down the road, maybe those can be implemented later but aren't strictly needed at present IMO.
As Miloch says, all things considered, the third solution is probably the best. I would just change the prompt to something more exhaustive.

Yeah, there have been some developments on the subject that I have not made public. BGEE support is pretty far along towards being implemented as per the proposal where the user is asked for which TLK to install to. Some surrounding concerns remain to be taken care of. I think I'm abandoning padding, because it turns out it's not really necessary, or something (all mod-added strings would need to be reinstalled when language is changed, so where you start adding strings doesn't much matter. You would be more likely to lose saved-game compatibility on switching language, but I don't think I could guarantee that anyway, due to deduplication). The ask-for-lang-dir text is rather basic at this point, but I can certainly pile it on. It is translatable, btw, and displayed after you select mod language.

Maybe I have forgotten something, but I think that's it.
Posted by: Wisp
« on: July 26, 2013, 03:04:24 PM »

Edit: Also, we were wondering whether the functionality to recognize saved games in "My Documents" is in - do SAVE_DIRECTORY and MPSAVE_DIRECTORY require explicit arguments or can those paths be determined from the OS registry or .ini files somehow?
Yes, it's in. SAVE_DIRECTORY and MPSAVE_DIRECTORY are regular variables that evaluate to the save directory.
Usage:
Code: [Select]
GET_FILE_ARRAY saves "%SAVE_DIRECTORY%" "[0-9]+.+"
ACTION_PHP_EACH saves AS i => dir BEGIN
  ACTION_IF FILE_EXISTS "%dir%/baldur.gam" BEGIN
    // do things here
  END
END
Should be valid everywhere except BGEE on Linux, and maybe not on all configurations of BGEE on OS X, if there are more than the one I have been told of.
For not-BGEE, that's just ./save and ./mpsave, otherwise:
The location of "My Documents" is read from the registry on Windows. On OS X, the location of $HOME is read from the user database (to the effect of getpwuid(getuid())->pw_dir). In all cases, a compile-time constant is appended to arrive at the directory where BGEE stores its user files (and then /save/ on top of that to arrive at the save dir). I am not absolutely super sure about OS X. I have had it told it works, but it seems the location of the BGEE dir also varies with version of OS X and whether you bought the game from Beamdog or through the MAS, or something.
(On Linux and BGEE, it's ./save and ./mpsave, just as with not-BGEE, because it makes it easier for me. When/if BGEE is officially available, it'll use the same system as OS X).
Posted by: GeN1e
« on: July 26, 2013, 02:09:50 PM »

As Miloch says, all things considered, the third solution is probably the best. I would just change the prompt to something more exhaustive.

Quote
WeiDU has detected that your game comes with the multi-language support, allowing you to switch the game language in the middle of playing. Due to overcomplicated technical reasons, it is not possible to install third-party mods - such as this - and retain the language switch function without introducing severe glitches, such as the in-game text becoming incorrect or outright missing - suffice to say that over the course of its development WeiDU has never been optimized to simultaneously support more than one language.

In light of the abovementioned, it is necessary that you decide which of the game's pre-existing language files will be used for the purpose of installing third-party mods from now on. Changing the language in game options to another one will result in ill behavior as described above.

Which game language file would you like to use for installing mods?
  • The currently selected language (English)
  • [1] English
    [2] French
    ...
[N] foo_bar (language foo as spoken in country bar, so presented because a new translation was released and WeiDU has yet to be updated)
Posted by: Miloch
« on: July 26, 2013, 01:41:01 PM »

You can have another beta, if you like. You people like betas, right?
Yes, we like betas... thanks for the latest one. I'm willing to test a beta version of this functionality anyway, and there's been a lot of demand for a solution. We've been discussing it elsewhere and I think the best solution is the simplest one for now. If we need complexities (e.g. mass STRING_SET padding) down the road, maybe those can be implemented later but aren't strictly needed at present IMO.

Edit: Also, we were wondering whether the functionality to recognize saved games in "My Documents" is in - do SAVE_DIRECTORY and MPSAVE_DIRECTORY require explicit arguments or can those paths be determined from the OS registry or .ini files somehow?
Posted by: Wisp
« on: March 07, 2013, 06:13:30 AM »

So any ETA on a next version? ;)
Not yet. You can have another beta, if you like. You people like betas, right?

Another problem with proposal #2 that I neglected to mention is what to do with STRING_SETs. If you pad with install strings, STRING_SETs will still be missing, so if two mods install to different TLKs, you still have the incompleteness problem. It's not insurmountable, as you could probably just STRING_SET to all TLKs, as per proposal #1, but it does lead to a more complicated (and thus problem-prone) implementation.
Posted by: Miloch
« on: March 06, 2013, 05:01:13 PM »

I think that last proposal is sound. There's a difference between game language and mod language. So any ETA on a next version? ;)
Posted by: Wisp
« on: March 06, 2013, 10:35:25 AM »

I was thinking more like
Quote
Which language file would you like to install to?
[1] English
[2] French
...
[N] foo_bar (language foo as spoken in country bar, so presented because a new translation was released and WeiDU has yet to be updated)

This would be followed by the usual "choose your language", which could be altered to be a little more clear about what it concerns.

Admittedly there is some slight overlap, but as I see it, it is a robust and unconstraining way of mapping the unknown set of mod-languages onto the set of game languages. It is also something you do once, that is applicable to all mods, rather than something you have to do for each mod (and possibly do slightly differently for each).
Posted by: GeN1e
« on: March 06, 2013, 12:03:04 AM »

I think a user capable of understanding what in the Nine Hells the TLK files are about, should also be able to edit the TP2 language arguments.
Otherwise you'll just add extra confusion to the installation process, which, simple as it may seem to us, is pretty complicated to others. I've seen enough players preferring to torrent a pre-installed mega-mod game, than read through the BWP manual. Possibly - for I've never researched the matter - it is a Russia-specific issue, but I bet you'll find it spreading when people are presented with more questions they don't really understand.

I vote for the second proposal, padding is done with install strings.
Posted by: Wisp
« on: March 05, 2013, 04:34:42 PM »

Proposal the third:

General:
If it has not already been done and the results saved, the user is prompted for which TLK set he/she would like to install to (or uninstall from). The result is saved to a config file among the other BGEE files (saves, baldur.ini and such) and reused when any subsequent mods are installed. If the file is deleted, WeiDU asks again. Two command-line options are added, something like "--use-tlk en_us" and "--force-tlk en_us". The first sets the TLK path if unset but is disregarded otherwise, the second sets the TLK path even if it is already set. Both obviously inhibit the prompting. If the argument is invalid (referring to a non-existent directory), WeiDU errors out. We call the TLK(s) so selected the active TLK(s).

The rest works as per proposal #2 (except for the bit about falling back on the TLK(s) obtained from baldur.ini; instead we fall back on the user-specified TLK(s)). We pad with filler strings, not install strings.

(No, it did not take me a week to come up with this.)
Posted by: Wisp
« on: March 02, 2013, 04:03:00 PM »

There are users who prefer to install mods in Language A but will install them in Language B when A is not available.  If the padding consisted of empty strings, after installing two mods in different languages, neither of the .tlk files would be complete.
Good point.
Posted by: GeN1e
« on: February 28, 2013, 02:46:08 PM »

Would the post-processing padding copy the new strings from the active .tlk file to the others or append empty strings to the others?
Thinking very carefully, wouldn't copying only brand new English (or whatever) strings to another TLKs result in correct overlapping? E.g. if we have SAY'ed "Buckler" somewhere, then it would set the value to #13709 instead of appending new entry - and #13709 should have already been provided with the translation in other languages.

There will still be a room for language differences, but for the most part installing a mod in any language could then automatically provide the correct translation for re-used strings, leaving only new ones in gibberish.