label [Tutorial] How to properly handle mod component dependencies

[AL|EN]

That's fair. Having to wait extra time for component reinstallation can be a PITA. Let's see if something can be done about it.

[subtledoctor]

On 3/2/2024 at 1:32 PM, Incrementis said:

As far as I know, LABEL is the preferred method, because You wrote:

“LABEL is a better DESIGNATED…”

This leads me to believe that DESIGNATED is not necessary for completely new mods.

LABEL is better than DESIGNATED for the specific purpose mentioned in this thread relating to inter-mod dependency interactions.

DESIGNATED is still useful for other things. As a very simple example, if you don't use DESIGNATED numbers, Weidu will apply its own component numbers as it installs them. This is important: not using DESIGNATED component numbers does not mean components don't have numbers. So if your mod has three components and someone installs the first and third, their Weidu.log will show something like:

yourmod.tp2 #0
yourmod.tp2 #2

If you add another component later, and due to install order issues it has to go before the last one, then the same two components would thereafter show up in logs as:

yourmod.tp2 #0
yourmod.tp2 #3

Again a very simplistic example, but someone looking at a troubleshooting thread years later and seeing that weidu.log might think the thread is talking about different components than it really is.

Using DESIGNATED gives you control over component numbers. The numbering is completely arbitrary so you can go 1000, 2000, etc. and add new ones in between later if it comes to that. Control over such things is never bad, and there is really no reason not use both DESIGNATED and LABEL, apart from the trivial increase in effort of writing one simple line in the .tp2 file. (Setting aside performance issues mentioned by DavidW, which I guess can be a reason to avoid LABEL, but only in pretty rare cases.)

[AL|EN]

On 3/6/2024 at 3:21 PM, suy said:

You are also sending a clear message to users: you care less about them.

Don't get me wrong. Your previous message made me consider making a small program that wraps weidu and can accept installing something by label name (I'd make it cross platform, open source, and hopefully easy to use, etc., so it can spread usage of LABEL for more people, not just me). But given that weidu.log only stores component numbers, not using designated component numbers at all, and given David's findings on the bad performance of LABEL, this all points to a promising future for the labels, maybe, but a pretty limited present. This needs work on weidu's side. Note also that the JSON output is marked as experimental, so it's another problem to spread its usage.

PI has been doing what you describe for quite some time without problems. JSON output has been used for more than 5 years and there was only one bugfix, it's hardly 'experimental'. The slowdowns occur only for one, developer-related case having a mod with 150+ components, it's not noticeable for end-users. Not everything has to be done on the weidu side as weidu lacks a 'global' (using one, centralized directory/list of mods that can be used for installation) way of dealing with mods. Not to say that the work is easy and you would have to do workarounds for things that weidu doesn't provide out-of-the-box, but IMHO, you are too focused on problems instead of solutions.

[AL|EN]

On 3/2/2024 at 9:38 PM, CamDawg said:

The claim is that it frees us from the tyranny of fixing a DESIGNATED value, which is nonsensical, as that's the whole point of DESIGNATED. It's like arguing that by using DESIGNATED it frees us to change LABELs, an equally nonsensical proposal.

DESIGNATED was created so that mods with multiple components (e.g. Tweaks) could present the components in a sensible order in the installer without causing massive compatibility headaches down the line. Prior to DESIGNATED, WeiDU simply numbered components itself starting with 0, so if you wanted to add components they had to be at the end of existing ones. Tweaks is barely manageable as it is; I want you to imagine the horrific mess it would be if it was organized in a purely chronological order of the components by creation date. With fixed DESIGNATED values I can freely add components where I think they fit in the order, move them around, or do whatever without making David and other modders having to constantly shift around their compatibility checks.

AL|EN's doing a little not-so-subtle lobbying here: no one is using LABELs to check against other components--at least not yet, and this paradigm shift was proposed three years ago. Keeping your component numbers DESIGNATED is more important, and I don't foresee that changing any time soon.

This isn't to say that LABELs aren't useful: they very much are, and you should use them, and they'll become even more useful is we ever get a new version of WeiDU with the proposed changes to LABEL handling. I'm simply clarifying that DESIGNATED is still relevant and not to be discarded, and that changing a DESIGNATED value is exceptionally bad practice.

While there is an appreciation for using LABELs at the end, I fear that the 'nonsense part' is where most people will be turned off, without reading to the end.

The claim is true if you take into consideration the compatibility checks: if your mod uses LABEL for compatibility check, or if an external mod would rewrite its checks to use LABEL, the modder is free to change the DESIGNATED value without breaking other mods, simply as that. There are no claims that 'LABEL can replace DESIGNATED in terms of the order of the components".

The majority of the mods have 1-5 components; often they use DESIGNATED 0, DESIGNATED 1, DESIGNATED 2 ... etc. Those mods could remove DESIGNATED and nothing would happen at all. The purely chronological order is fine for those, so in fact, simply adding LABELs is enough for serving WeiDU compatibility checks (both internally and externally) and PI 'save mod choices' features. There's no need for DESIGNATED if it doesn't add any value.

Changing a DESIGNATED value is an exceptionally bad practice, but there is a technical reason to do it, and if you weren't lucky enough to start with best practices for them, you are inevitably forced to change them at some point.

While the adoption of LABEL for compatibility checks is slow, there are a few mods that use them, with hopes of more to come.

On 3/2/2024 at 9:38 PM, CamDawg said:

... proposed changes to LABEL handling ...

Having the ability for LABELs to control the order of the components would be a nice addition. We can even extend the @suy proposal: let the WeiDU backup system use the label to be more reliable. Where can I read more about the proposed improvements for LABEL, just to avoid duplicating requests?

Edited March 12 by AL|EN
Ctrl+Enter

[CamDawg]

7 hours ago, AL|EN said:

the modder is free to change the DESIGNATED value without breaking other mods, simply as that

There's no upside to changing the component number of a mod once it's released, only downside, and that's true regardless of whether LABELs are being used. There's no queue of modders desperately wanting to change component numbers, being held at bay only by downstream compatibility concerns.

There are several good use cases and benefits for using LABELs. This is not one of them.

[suy]

12 hours ago, AL|EN said:

PI has been doing what you describe for quite some time without problems.

Not everyone uses PI. If I'm wishing for better LABEL support inside weidu, it's because it would be universal to everyone. If one wants to prioritize the experience of installing with PI only, then that's fine. But this is where my remark about caring less about (some) users comes from.

12 hours ago, AL|EN said:

JSON output has been used for more than 5 years and there was only one bugfix, it's hardly 'experimental'.

You know why I said that. Moments after I wrote it, you submitted a PR to remove that bit from the text that weidu outputs to the console as help. Also, the option is not documented in the readme (which would not harm), and it's output mixes weidu's usual informational messages ("[weidu] WeiDU version 24900", etc), with the JSON output. It would help to be only the JSON, as it requires less parsing, and could be more efficient. If Fredrik considers it enough tested to remove the "experimental" note, so be it.

I can't tell much more about the JSON output, as I've not used it enough. I just can say that sometimes I see a wrong tree of the mod components in Zeitgeist, but if no one has seen such thing in WIT or PI, then it's of course not a weidu issue, but a bug in Zeitgeist's display.

[DavidW]

On 3/12/2024 at 3:05 PM, CamDawg said:

There's no upside to changing the component number of a mod once it's released, only downside, and that's true regardless of whether LABELs are being used. There's no queue of modders desperately wanting to change component numbers, being held at bay only by downstream compatibility concerns.

To be fair, I have had occasional edge-case issues when I've had sequential mod components with non-increasing DESIGNATED values, and have very occasionally renumbered for that reason.

[AL|EN]

On 3/6/2024 at 9:37 PM, DavidW said:

Those numbers look broadly compatible with my own observations: a slowdown of about 30-60 seconds at the very start of running the mod, and subsequent slowdowns at the start of every component. The 2.5 minute slowdown for SCS is if anything worse than I recall (but then the architecture of SCS has changed a bit since then).

That might be tolerable for end users (though a 10% slowdown for SCS is not nothing in a mod which already takes far too long to install) but they are intolerable for development, in the quite literal sense that I put LABELs in some years ago, couldn't tolerate the slowdowns, and took them out again.

I have done more testing, LABEL slowdown (pocketplane.net), provided an easy-to-use Testing Suite and offered help if Wisp wanted to do some experiments. It seems that the dummy tp2 has slowdowns also because of LAF. I'm hoping for Wisp to pick up this again.