[Request] Reload TLK after --make-tlk, variable with total number of strings

[K4thos]

Correct me if I'm wrong but I think currently there is no other way to reload current TLK file without restarting the exe or using --force-install. Not ideal solution considering something like this called from component 0:

Code: [Select]

AT_NOW ~setup-test.exe --force-install 1~doesn't create weidu.log entry for component 1 (is this a bug?), so the mod can't be properly uninstalled.

Request:
1. Automatically reload TLK after --make-tlk is used without --tlkout argument (which currently automatically replaces current TLK) OR add a new command to force weidu to reload TLK file manually
2. Also if it's not much work please add a constant variable that returns total amount of strings within currently loaded TLK. For now I'm using:

Code: [Select]

COPY ~lang/en_US/dialog.tlk~ ~lang/en_US~
READ_LONG 0xa "tlk_cnt"But something like this is no longer possible if you install some mods due to weidu COPY command size limit. Considering weidu always prints this text:

Code: [Select]

[.\lang\en_us/dialog.tlk] 103214 string entriesit would be great to have access to this value from tp2 file code.

Thanks in advance.

[K4thos]

And another problem that looks like a bug to me. --make-tlk doesn't support dialogF.tlk file.
What I've already tried:

Code: [Select]

AT_NOW ~weidu --noautoupdate --no-auto-tp2 --make-tlk "test/test.tra"~this will automatically replace current TLK with new one. But only dialog.tlk is generated even though test.tra file has female versions of strings too (the file has been created using --traify-tlk which automatically appends both male and female strings). dialogF.tlk remains unchanged

Code: [Select]

AT_NOW ~weidu --noautoupdate --no-auto-tp2 --make-tlk "test/test.tra" --ftlkout "test/dialogF.tlk~--ftlkout is ignored, TLK is created inside default TLK directory

Code: [Select]

AT_NOW ~weidu --noautoupdate --no-auto-tp2 --make-tlk "test/test.tra" --tlkout "test/dialog.tlk" --ftlkout "test/dialogF.tlk~this allows you to move generated dialog.tlk outside default directory. --ftlkout is ignored.

Workaround for this is generating TRA files for each TLK file alone (--traify-tlk running in dummy language directory with 1 TLK present), so that --make-tlk can have both male and female version of the input file.

[Wisp]

1. Automatically reload TLK after --make-tlk is used without --tlkout argument (which currently automatically replaces current TLK) OR add a new command to force weidu to reload TLK file manually

What's the use-case here?
If you are calling an inferior WeiDU with --make-tlk from within a WeiDU setup process, I have identified your problem. Don't to that. Only the "master" process may do some things, and modifying the key and tlk are among those things. Oh, you are. Well, don't do that.

2. Also if it's not much work please add a constant variable that returns total amount of strings within currently loaded TLK.

It stalled somewhere in the pipeline. I'll give it a shove after 240.

And another problem that looks like a bug to me. --make-tlk doesn't support dialogF.tlk file.

No, it doesn't. I'll fix.

[K4thos]

What's the use-case here?
If you are calling an inferior WeiDU with --make-tlk from within a WeiDU setup process, I have identified your problem. Don't to that. Only the "master" process may do some things, and modifying the key and tlk are among those things. Oh, you are. Well, don't do that.

It's for on the fly TLK appending in EET. This topic discuss why it's worth it. My first intuition was to use --tlkmerge X to append the larger TLK file (constructed from BG2:EE TLK + some reserved strings+BG:EE TLK) with existing TLK but from my tests it looks like this command can only do it up to the amount of strings already present within loaded TLK and can't really expand the file beyond that. Not even sure if this would be viable either way considering we need to later change some newly added BG:EE strings via STRING_SET and from what I remember weidu doesn't allow to edit new strings until it finishes the runtime.

No, it doesn't. I'll fix.

Glad to hear it

It stalled somewhere in the pipeline. I'll give it a shove after 240.

thanks!

edit: removed information about workaround used since it didn't work correctly at the end (problems when mod fails to install). In order to solve the not existing weidu.log entry mentioned in the first post I've changed AT_NOW with AT_EXIT. I guess this is what you were suggesting by not messing with master process.