Jump to content


Mod metadata source - brainstorming

31 replies to this topic

#31 Mike1072

  • Gibberling Poobah
  • 2484 posts
  • Gender:Male
  • Location:Canada

Posted 20 September 2018 - 05:40 PM

@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 <modname>.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.

#32 ALIENQuake

  • Modders
  • 609 posts
  • Gender:Male
  • Location:Poland

Posted 20 September 2018 - 06:44 PM

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. 

Reply to this topic


1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users