projectinfinity Mod metadata - providing mod full name, description, readme files/links, download/update links

[jastey]

If I do not want to change the name of the tp2 for old mods because I fear compatibility problems, how should I name the .ini with the metadata?

So, the tp2 is setup-modname.tp2, but the ini should be modname.ini? EDIT: ok, in the amber ini it states

Quote

# File name: it must be the same as tp2 name

so I guess it should be setup-modname.ini for my example.

[AL|EN]

@jasteyYou can remove "setup-" without worrying about any kind of problems, weidu code was updated to handle this properly. I don't know, maybe other modder feedback regarding this would change you mind? But you can also skip 'setup-' for ini file and it will work. For such minor thing a compromise between "weidu way" and "PI way" is desirable.

[jastey]

Thank you for the information! It's good to know the "setup-" is not needed for MOD_IS_INSTALLED and I assume for REQUIRE_COMPONENT, too.

I was a bit hasty with updating Fading Promises, then, but for other mod updates I don't see a reason why not to skip the "setup-" in teh future.

 

[Creepin]

1 hour ago, jastey said:

but for other mod updates I don't see a reason why not to skip the "setup-" in teh future.

What about tradition, and the decent order, and proper way to do things? :( I have not yet reconciled myself with the idea of not placing tp2 in the root folder of the game, and losing "setup-", well that's just unthinkable!

[cmorgan]

I feel your pain, Creepin, but without change the following would not have occurred...

1. Mods at all

2. WeiDU

3. Tutu

4. BGT

5. Mods that go on both Tutu and BGT

... etc.

[Jarno Mikkola]

2 hours ago, cmorgan said:

4. BGT

 

This is wrongly categorized !

Surely you mean BGT-weidu. Cause there isn't a mod today, that is compatible with BGT, when the mod is installed before BGT. Yey... and you know... BGT doesn't need WeiDU.. but BGT-weidu needed both Tutu and WeiDU.

[cmorgan]

Actually, the topic that Creepin was actually focusing on was “change” - to clarify for your point, the list would continue with “BGT installed with WeiDU, EasyTutu, Cross-Platform Variables incorporated into mods to allow the same mod to be installed on top of TuTu|EasyTutu|BGT (BG content only)” etc etc etc - as mods went on top of BGT and on top of TuTu - but the list was already long and the extension meaningless, as are most of my to-wordy posts

How’s about I just TL,DR and say 

“All this stuff and our entire community exists because folks embraced change”.

 

[skellytz]

Planning on adding metadata for individual component descriptions? Might save time switching between PI and mod readme to decide what to install.

[AL|EN]

@skellytzI might but which modder would create two sets of component descriptions (readme + metadata file) for each component?

[jastey]

In the ini, I include description of the individual  components to teh mod description if I think it's important for player decision, but apart from that, I'm assuming the tool can display the components with their names for the player to chose from.

[skellytz]

3 hours ago, AL|EN said:

@skellytzI might but which modder would create two sets of component descriptions (readme + metadata file) for each component?

The individual component descriptions could be entirely optional. If present in the metadata, they would show up in the description window when you click on a component in the mod tree. If not present, the general mod description would be displayed instead.

In most cases, the description would be pretty much the same as in the readme; no need for modders to create different sets. For example, I want to install Tweaks Anthology, but I'm not sure what component "Weapon Animation Tweaks" does. I could go through the readme or simply click on the component in the mod tree for convenience:

Quote

Component description:

By default, spears in BG2 use 33% overhead swings, 33% backhand swings and only 34% thrusting attacks. Wouldn't it make more sense to use the pointy end?

This component adjusts the attack animation balances of various weapons classes: spears, staves, short swords, and one-handed blunt instruments such as clubs and maces. Spears and short swords now primarily use thrusting attacks and staves are more consistent as a class and use more swinging attacks. A handful of clubs and maces were using thrust attacks; they now only use swinging attacks like all other one-handed blunt weapons. This component also changes morningstars to use a mace animation when attacking, instead of the flail-like ball-and-chain animation. Morningstars are depicted in inventory icons and description pictures as being closer to spiked maces. This component will affect all items in the game, including items introduced by mods.

 

 

[AL|EN]

@skellytz

Yep, that's how it could work. But it still require maintaining of two files. And some of the component description require some specific things like tables/images. I'm not against such feature but you have to be aware that modders like when players reads readme files because there are lot of important information there regarding compatibility, install order, etc. So when player will read component description, without reading readme, he might endup with wrong install order/conflicted mods etc ,  then he will fill "bug" report only to get modders response of "readme says that you should install my mod after X and not use it when you also have mod Y..." or something like that. Everything can be done, but not everything is worth it.

Edited February 11, 2019 by AL|EN

[AL|EN]

I've added full suport for 'weidu tp2 README keyword', including localized ones. I've check and  'weidu tp2 README keyword' doesn't support url's - if you will put a link to the website, you will get error that 'File don't exist'.

By modders request, I want to add support for "online readme links". But there are some things to discuss:

1. When you use ini readme, do you expect that %LANGUAGE% variable will work? Or you would simply put several links with different language as part of the link into ini Readme?

2. What if there is tp2 README and ini README? Which one should have precedence? What if the tp2 README has localized entry's and the ini README doesn't? If the ini readme will take precedence, the local localized entry's won't be displayed. Combining values from both of those keywords under some kind of condition would be complicated. Should I simply display all of them, local ones and links to remote ones?

3. What if modder misinterpret the 'ini Readme keyword' and use it to provide relative paths to local readme files?

4. The localized readme file comes from translators, whey won't be able to update the localized readme version because they don't have access to the hosting site. So the online localized readme will be outdated and it it's updating would be up to modder/maintainer, not the translator itself. This doesn't appeal to me, because it means more work for mod author/maintainers.

5. The changelog-part of the localized readme is outdated 90% of the time.

Edited August 5, 2019 by AL|EN

[Sam.]

On 7/31/2019 at 3:48 AM, AL|EN said:

I've added full suport for 'weidu tp2 README keyword', including localized ones. I've check and  'weidu tp2 README keyword' doesn't support url's - if you will put a link to the website, you will get error that 'File don't exist'.

In my TP2 I have:

README ~aurora/aurora-%LANGUAGE%.html~ ~aurora/aurora-english.html~

As an experiment, I have also added small language flags to the top of the Readmes with links to the versions available in other languages.  Example.

I believe using this approach has the following benefits (in no particular order):

• Player is taken directly to the readme in their localization if it exists, or the English one if not.
• If player wishes to read the readme in in a localization other than what they will be playing the mod in, there is secondary access to it (via language flag links).
• Player always has access to copies of the readmes at least as updated as the version of the mod they are playing, regardless of internet connection.  For some, this may be a significant benefit.

On 7/31/2019 at 3:48 AM, AL|EN said:

By modders request, I want to add support for "online readme links". But there are some things to discuss:

1. When you use ini readme, do you expect that %LANGUAGE% variable will work? Or you would simply put several links with different language as part of the link into ini Readme?

If you can make the %LANGUAGE% variable work in the ini, that seems like a much more elegant solution than having different links to each readme and the modder needing to add links as additional localizations become available.

 

On 7/31/2019 at 3:48 AM, AL|EN said:

2. What if there is tp2 README and ini README? Which one should have precedence? What if the tp2 README has localized entry's and the ini README doesn't? If the ini readme will take precedence, the local localized entry's won't be displayed. Combining values from both of those keywords under some kind of condition would be complicated. Should I simply display all of them, local ones and links to remote ones?

Local readmes are at least as up-to-date as the version of the mod they are shipped with.  However, since the online version must, by necessity, be updated before anyone can download a local copy, they may be more up-to-date.  In a perfect scenario, I would say it is best to default to the online version if a) it exists; b) there is an internet connection; and c) it is accessible (through any firewalls and the hosting site is not down).  If the online version can't be reached, drop back to using the local one.  Realistically, tho, this probably isn't overly feasible.

On the other hand, you cover every possibility if you present the user with every link and let them use they one they want (or at least find one that works).

 

On 7/31/2019 at 3:48 AM, AL|EN said:

3. What if modder misinterpret the 'ini Readme keyword' and use it to provide relative paths to local readme files?

Can you check if the path exists as a local file (in which case use that), and if not try it as a URL?

 

On 7/31/2019 at 3:48 AM, AL|EN said:

4. The localized readme file comes from translators, whey won't be able to update the localized readme version because they don't have access to the hosting site. So the online localized readme will be outdated and it it's updating would be up to modder/maintainer, not the translator itself. This doesn't appeal to me, because it means more work for mod author/maintainers.

I'm not sure I understand what you are getting at.  For my mods, new or updated translations usually come to me in forum posts or PMs, and only occasionally as pull requests.  Yes I have to take 10 minutes to add it to the GitHub repo and push the commit, but personally this is preferable to allowing anyone and everyone to update my mods or their readmes.  Are you saying there is an alternative solution that still grants me some semblance of control?

 

On 7/31/2019 at 3:48 AM, AL|EN said:

5. The changelog-part of the localized readme is outdated 90% of the time.

True, but the recent changelog of more and more mods, even in the primary language, is going the route of "see GitHub commit history for full list of recent changes".  I'm not saying it's a perfect solution, but it certainly cuts down on the amount of work for mod maintainers and translators.

Edited August 6, 2019 by Sam.

[AL|EN]

3 hours ago, Sam. said:

I'm not sure I understand what you are getting at.  For my mods, new or updated translations usually come to me in forum posts or PMs, and only occasionally as pull requests.  Yes I have to take 10 minutes to add it to the GitHub repo and push the commit, but personally this is preferable to allowing anyone and everyone to update my mods or their readmes.  Are you saying there is an alternative solution that still grants me some semblance of control?

No, this is good solution. My thoughts was shifted to: if the translators can't update online readme, just forget about it and leave online English translation as the only one. So local translated readmes would be preferable. But I guess it's up to modder.

I see that the best solution would be to simply threat ini Readme as a improved version of the weidu README and display the unique results from both of them. Let's see what I can do.

BTW: Flags are very nice thing.