Things that prevent WeiDU successor or alternative?

[lynx]

With the split tlks in ees, it would be possible to mirror the updates with low chances of problems (non-matching translations are a mod problem), but for that a bunch of things in weidu would need to be adapted first.

For gemrb we hit the same problems when thinking about adding live language switching. It's the data that is problematic, not so much the engine changes that would require. Probably simplest to devise a tool that eats tra files and creates tlk overrides that we could then swap. Or a tlk format upgrade that would make it easier. Either way, a regular mod install would not be enough.

[CamDawg]

1 hour ago, mickabouille said:

Thanks for the write-up but... I re-read it thrice and I'm not sure I understand.

Am I understanding correctly that the basic problem is that the vanilla tlk are not a 1:1 match in different languages?

Or that the correct way for weidu to edit the tlk would be to never reuse existing strings and always create new ones?

 

Both seem more a problem of "didn't think about it at the beginning"

 

EDIT : ah well, the original versions only came with one language IIRC so it probably wasn't even a problem

Pretty much. Let me give you a concrete example from BGEE.

Let's say I make a mod with a small area with a kitchen, to which I add a male creature named "Cook". In English, WeiDU looks in the tlk and sees the existing string "Cook" at 32197. (String 12895 is also "Cook" but WeiDU selects the last matching string.) However, cooks in the French version are "Cuisinière" (32197, female, used by fcook2 e.g.) and "Cuistot" (12895, male, used by mcook) for cooks. So WeiDU either decides to use 32197 on the French version, which isn't correct for French players, or adds a new string to all tlks, which introduces redundancy (at best) or bugs (at worst).

lynx is correct in that this can be somewhat mitigated by modders--since "Cook" is an existing string I should be using a direct string reference in my installer (in this case, 12895) rather than introducing the name like it's a new string.

[AL|EN]

13 hours ago, jmerry said:

The source of legitimate complication is that other languages don't do that "make backup copies of everything" step by default. The "don't back anything up" state that you have to deliberately invoke with a special modifier in WeiDU is normal in other languages.

13 hours ago, subtledoctor said:

Just that any doofus like me can, with Weidu, get the benefit of that without even trying. Whereas, with another language I would have to intentionally set that up, and 1) hopefully I don’t forget, 2) hopefully it’s not too much extra effort, and 3) hopefully I don’t screw it up.

That’s a lot of hopefully!

Even if the WeiDU has build-in backup, I see no difference between:

1. Install weidu mod by launching "Setup-Mod1 --yes" (state of the game files: 1)
2. Install weidu mod by launching "Setup-Mod2 --yes" (state of the game files: 2)
3. Uninstall the Weidu mod by launching "Setup-MyMod2 --uninstall" (state of the game files: 1)

and

1. install weidu mod by launching "Setup-Mod1 --yes",  the state of the game files is saved by an external thing aka MyBackupTool (state of the game files: 1)
2. install a mod using any tool/mod framework (state of the game files: 2)
3. restore game files via MyBackupTool -RestoreState 1 (state of the game files: 1)

This way, you can use pretty much anything to modify game files and still have the ability to 'uninstall mods', no matter how they were made.

[suy]

On 3/17/2024 at 9:47 AM, DavidW said:

But it's important to note the limitations of this: without a LOT of extra work, the LUA code could not interact with dialog.tlk, so strings could not be set;

Why would it be a lot of extra work? The external script can easily just add to the TLK file(s). Is is because of the backup? I have to admit that I don't see how weidu does backups of the dialog.tlk. I only have found copies of it in dlcmerger's installation. For the rest, I just see a bunch of "tlkpath" files which are one line long text files with just the path to the dialog.tlk file.

[lynx]

I think he meant the string extraction and other niceties, not the trivial thing of adding or changing strings directly in the tlk.

I'm surprised this time nobody suggested using an existing version control system yet.

[argent77]

2 hours ago, suy said:

Why would it be a lot of extra work? The external script can easily just add to the TLK file(s). Is is because of the backup?

WeiDU caches strings (and other stuff) internally for performance reasons. Reading or modifying the dialog.tlk externally while a mod installation is in progress may not work as intended.

[RoyalProtector]

On 3/16/2024 at 11:38 PM, lynx said:

A few extra functions are shipped with it, but the closest thing to an assortment of other functions and libraries is:

Not to derail the discussion, but has someone made some addon for any text editors to code in WeiDu? Talking mostly about syntax highlighting, I'm not expecting intellisense.

[mickabouille]

> I'm surprised this time nobody suggested using an existing version control system yet.

I thought about it once.

I even tested it with git, expecting it to blow up.

I was pleasantly surprised that it seemed to hold up well, even with big chunks of binary files (which are not specifically a strong point for git).

But then I decided I needed to exclude backup directories to have something interesting and... I didn't push further after that.

Note that mods that extract backup (and work) dirs outside theeir mod dir help with that.

[Sam.]

42 minutes ago, RoyalProtector said:

Not to derail the discussion, but has someone made some addon for any text editors to code in WeiDu? Talking mostly about syntax highlighting, I'm not expecting intellisense.

WeiDU Highlighter for Notepad++

VScode support for WeiDU syntaxes

 

 

 

[morpheus562]

1 hour ago, RoyalProtector said:

Not to derail the discussion, but has someone made some addon for any text editors to code in WeiDu? Talking mostly about syntax highlighting, I'm not expecting intellisense.

I posted a basic linter for sublimetext to work with weidu and bcs scripts. That should be here somewhere on the forums.

[marco_costa]

1 hour ago, mickabouille said:

Note that mods that extract backup (and work) dirs outside theeir mod dir help with that.

This is the kind of stuff that would be amazing to have added to WeiDU as a setting, namely override the backup directory to force immutability of mod installation directories.

IMHO having the backups be relationally associated with a mod installation files instead of the copy of the game being modded is straight up a design error.

But once more, ocaml scares me

[RoyalProtector]

1 hour ago, Sam. said:

VScode support for WeiDU syntaxes

That's the winner for me. Thanks.

Edited March 18 by RoyalProtector

[lynx]

2 hours ago, mickabouille said:

But then I decided I needed to exclude backup directories to have something interesting and... I didn't push further after that.

Note that mods that extract backup (and work) dirs outside theeir mod dir help with that.

Why bother with excluding backup dirs, just to save some space? And since the name is always the same, you could just add it to the exclude list, so the problem goes away automatically.

SCMs worked well for me too, but I'm not a megamodder, so it was mainly to ensure base (vanilla) state easily.

[DavidW]

2 hours ago, marco_costa said:

IMHO having the backups be relationally associated with a mod installation files instead of the copy of the game being modded is straight up a design error.

I have been saying so for years, and mostly people seem convinced. But of course that's a mod design issue, not about WEIDU per se.

[mickabouille]

> Why bother with excluding backup dirs, just to save some space? And since the name is always the same, you could just add it to the exclude list, so the problem goes away automatically.

True, now you're saying that's true

I didn't know much about weidu at the time, all I saw was these directories with content I knew little about and that kept growing the more components you installed.

But mostly I got distracted by new shiny things and lost interest.