Jump to content

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


AL|EN

Recommended Posts

@Mike1072 Thanks for suggestion but it looks like you are to bound to BWS

1. No, not true

2. Doesn't matter

3. No, not true

 

No need for database/cache metadata. The .ini scheme is much better from the bigger picture(simple copy without adding "-metadata"), not from single mod and I'm happy that it's not a problem anymore.

Guess I'll have to take your word for it.

Link to comment

Just to be incredibly contrarian about this, Zeitgeist will support INI over my dead body*. It's not a suitable format for abstracted editing, for lack of a better term (that is, parsing it, presenting it with abstracted controls, say GUI widgets, allowing the user to change values within predefined bounds and doing something useful with the results); JSON's where it's at (the offshoots are less widely supported and are thus less qualified). Hell, even XML is better. The only way INI works if it's like today, where the user essentially opens text files in editors and change values at ver own risk. I'm not the dictator here; people can use whatever they like and build whatever ecosystems they like, but don't expect me to not be difficult about it.

 

*My being alive or dead is probably not relevant; INI would be unsupportable, regardless.

 

On the wider point of why metadata shouldn't be stored in the TP2, it's because having to run WeiDU every time you wanted to get to the information is terrible and unreasonable (and having to implement a TP2 parser in your program would be ridiculous) and WeiDU has not use for it, itself. Aside from having to have WeiDU available, in the right version, there are the considerations of needing to run a, possibly non-blocking, inferior process interactively, or at the least needing to run an inferior process and then having to read from whatever file to which you directed the process' output. Having the information in a widely supported standard format is the way to go; with a little luck, whatever tool/language you are using has native support for the format, and away you go. The unfortunate downside is that if you want per-component metadata, you have to duplicate and maintain the component structure in a second file.

The ini format is suitable for mod metadata. Modder doesn't need to learn about JSON at all for things like mod name, author, description and simple url. The configuration sould be stored in another file anyway (because of the updatemod>overwrite settings problem) so it can have JSON format for those who will need it. But for simple o/1 or true/false options, I think ini will also be fine. So why not support for both ini and JSON?

 

I think we all agree about 'data inside tp2' as a dead end.

Link to comment

Example for Tweaks Anthology:

 

Metadata from setup-cdtweaks.ini (match tp2 name)

[Metadata]
# Full name of the mod, without version number
Name = Mod Example - Optional Features

# Author name or nick, don't use email address
Author = AL|EN

# Short description of the mod, main goals, features etc
Description = This mod is a guide how to use optional 'Project Infinity' features.

# # Web address of mod HomePage
HomePage = http://www.example.com

#  Web address of mod dedicated forum or forum thread 
Forum = http://www.example.com/forums/categories/...

# if you use Github.com (preferred hosting site), please use simple github.com/AccountOrOrgName/RepositoryName.   
# If you use other hosting sites, please check requirements and put direct download link.
Download = https://github.com/AccountOrOrgName/ModExample-OptionalFeatures

# Requirements for other hosting sites:
# - forum attachments won't work because the download links will be changed when you update mod package
# - mod package should be downloaded using 'wget' commandline tool: wget.exe --no-check-certificate 'link'
# - it's possible to preform file size check using 'wget' commandline tool: wget.exe --no-check-certificate --spider 'link'
# - links do not expire after 30 or more days without download ( speeedyshare, mediafire etc has forced expiration dates)
# - hosting site won't require user interaction or captcha ( googledrive, mediafire etc require user interaction)
# - hosting site don't advertise any kind of adware/crapware etc

Presentation: https://imgur.com/a/FWs3U8f

 

ojqzEG2.png

 

 

Notice that Version and Readme path are taken from tp2. What do you think?

Edited by AL|EN
Link to comment

I don’t understand the “lynxlynx” bit.

Just read this pages info. Aka: "Microservice to find the latest or latest (pre)release version of a mod hosted on GitHub

It will automatically redirect to the desired archive. Defaults to archived code of the latest proper release."

Link to comment

Maybe bold the keys to help distinguish them from their values?

 

 

Maybe bold the keys to help distinguish them from their values?

Sound idea.

 

Done. Also the mod name has version at the TreeView.

 

Regarding lynx 'modhub':

 

I will definitely try to implement such functions directly in my tool so modders could just simply put

Download = https://github.com/Gibberlings3/Tweaks-Anthology

and that's it :thumbsup:

Edited by ALIENQuake
Link to comment
2 hours ago, DavidW said:

I don't understand the question.

(I also don't see why the "setup-" is causing you problems. Presumably it's easy enough just to do what WEIDU does and check both setup-mymod and plain mymod.)

Well, if we assume I am correct, which I might not is: There's a few mods that don't carry their own weidu.exe's, and so dealing with multiple search options when dealing with weidu mods that have ways to exists outside the usual bounds brings havok to automation outside the weidu coding. Yeah, see the BWS overwrites ALL the setup-modname.exe's with it's own if it finds x. Which as well might be the setup-*modname.tp2 in modfolder, or outside it~. 

And ~the outside files can be moved inside by general COPY command if so desired, which will then make everyone of those match a single design. And you won't have 2700 loose files in the game folder. They are all on their own neet folders. Which can then be removed by assumed easy to make command line. 

Also, there's then an option to use the weidu.exe as is to run all the .tp2's without multiple copies of itself.

Edited by Jarno Mikkola
Link to comment

 

8 hours ago, DavidW said:

I don't understand the question.

(I also don't see why the "setup-" is causing you problems. Presumably it's easy enough just to do what WEIDU does and check both setup-mymod and plain mymod.)

Weidu treat tp2 basename of setup-mymod and mymod as the same. But my mod installer app is not weidu so when I match mymod + .ini, it doesn't match for setup-mymod tp2 basename. I can add "detect mymod.ini and setup-mymod.ini but it makes the algorithm ineffective because it has to process 2x more detection checks at one step. Next, I would have to preform 2x more detection for mod config files etc.

If you expect that it would match, I can make such compromise but I really concern about performance when application is trying to scan 100+ mods.

Link to comment
1 hour ago, lynx said:

Why change any checks, it's just one regex to remove the setup- prefix if it's present.

How ? Aka, as you said it to be easy, give use the universally compatible code then... yes, I have low enough self-esteem to ask this.

Edited by Jarno Mikkola
Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...