Jump to content

Photo

Mod metadata source - brainstorming


31 replies to this topic

#16 ALIENQuake

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

Posted 19 September 2018 - 09:53 AM

What do you need to convince me of? I'm neutral as to whether you need multiple metadata files or just one - going from "metadata.ini" to "xx-metadata.ini" was your idea. I'm also fine if you want to read metadata out of mymod.ini provided there is a completely unambiguous way to designate it as metadata that won't lead to false positives - your suggestion of using .ini section headers is less hacky than my ideas.

I was under impression that you want to keep stratagems.ini filename regardless of the headers. I would prefer to have <modname>.ini + headers. I made few commits which reflect those changes, please take look and tell me if you are fine with them.

 

I don't think I'd seen "store the metadata in the tp2" mentioned before, but I'm strongly against it - code/data separation, please.

 

Same here, I was also a fan of having them stored outside of tp2 as soon as the concept of metadata files was on board so don't worry.



#17 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 19 September 2018 - 10:37 AM

Yes, I want to keep stratagems.ini, and more importantly I don't want any tool reading mymod.ini under the default assumption it's metadata or user configuration options given the false-positive risk. I don't mind metadata living in mymod.ini if it's clearly and unambiguously flagged as such via a section header or similar.

#18 ALIENQuake

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

Posted 19 September 2018 - 01:37 PM

But <mymod>.ini means stratagems.ini or do you mean literally "mymod.ini"?



#19 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 19 September 2018 - 01:55 PM

No, I mean stratagems.ini.

I think we're at cross purposes? I've said all along that you are welcome to read metadata out of stratagems.ini, or anything else you like, provided that there is some explicit, safe mechanism to guarantee there are no false positives. I don't care if that's because you only read from "metadata.ini", or because you only read from files with a commented-out "this is metadata" section, or because you're reading <mymod>.ini but you're only processing ini entries in a section with 

[autoinstaller_metadata]

or something in its section header.



#20 ALIENQuake

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

Posted 19 September 2018 - 02:26 PM

I've reverted previous commits and made another one, looks better? Right, so you don't mind to keep advanced settings (they won't be show to players) inside stratagems.ini combined with mod metadata?


Edited by ALIENQuake, 19 September 2018 - 02:26 PM.


#21 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 19 September 2018 - 03:44 PM

Sorry - what are you making commits to?

What matters to me is that things in <mymod>.ini don't get processed unless they are clearly marked for processing. Beyond that, I don't much mind.

#22 ALIENQuake

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

Posted 20 September 2018 - 01:04 AM

I've made few commits to SCS master branch to show you how it would look like, then I revert them, then I created a PR with changes I would like to see, but if I put metadata on top, READ_2DA_ENTRY_FORMER will fail to read ini. Is there any standard way to overcome this? This was my initial reason to move "variable number" 2DA data outside of stratagems.ini and put it into settings.ini.


Edited by ALIENQuake, 20 September 2018 - 03:15 AM.


#23 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 20 September 2018 - 06:11 AM

I can change the function SCS uses to read ini files easily enough to work around that.

#24 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 20 September 2018 - 06:54 AM

I've made few commits to SCS master branch to show you how it would look like, then I revert them, then I created a PR with changes I would like to see, but if I put metadata on top, READ_2DA_ENTRY_FORMER will fail to read ini. Is there any standard way to overcome this? This was my initial reason to move "variable number" 2DA data outside of stratagems.ini and put it into settings.ini.

OK, I was slow reading this - you're making changes to the master SCS branch?

 

Please don't do that. 

 

SCS is not a collaborative project, and I don't want anyone who isn't me changing its code, beyond bugfixes and language updates (and even then, I'd rather do it myself). 



#25 ALIENQuake

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

Posted 20 September 2018 - 07:02 AM

Got it, that's why I revert them and put them into separate branch + PR - if you accept such addition (you can even modify them before accepting), you can simply accept PR, the changes will land into master branch etc. If for any reason, you don't like them or you want to write different code etc, you just decline PR.



#26 DavidW

DavidW
  • Gibberlings
  • 4501 posts
  • Gender:Male

Posted 20 September 2018 - 07:07 AM

Great - much appreciated.



#27 Mike1072

Mike1072
  • Gibberling Poobah
  • 2482 posts
  • Gender:Male
  • Location:Canada

Posted 20 September 2018 - 07:28 AM

Similar to lynx, I don't see how this idea of metdata within mods would solve any problems.

1. You're still going to need to maintain an external list of all the mods, so you know where to pull metadata from.

2. There will always be mods that have no metadata or incorrect / out-of-date metadata. If you discover this, then the only way to fix it is to update the mod (which modders may not do immediately).

3. There's no way to load the metadata without downloading the mods.

So in essence, you'd still need an external database to store the mod URLs and cache the metadata (to avoid redownloading all the mods every time). And you'd still have to figure out whether you wanted to do anything special for mods whose metadata is known to be wrong.

Those issues aside, there's really no need for the metadata file to match the name of the mod. And if you know there are mods that already store installation settings in that file, you definitely should choose a different filename for storing the metadata.

#28 subtledoctor

subtledoctor
  • Modders
  • 2731 posts
  • Gender:Male

Posted 20 September 2018 - 03:44 PM

I think the idea is, the installer will have some backup behavior to scrape data from mods if the metadata file is not present - so for instance, you might see "spell_rev" and "item_rev" in the list of mods. But for modders who are active and want to take steps to make their mod more presentable in the tool, they don't have to contribute anything or collaborate with the tool maintainer; they can simply add some metadata to their own mod. The installer will then recognize and parse it.

I think the point here is, rather than the installer author demanding compliance with his needs, let's get some modders to talk about how hey might agree to do it in a way that is easy and convenient. Then AL|EN can design the tool to accommodate it. And if the metadata comforms to a clear standard, then presumably any future tools (Zeitgeist etc.) can also make use of the pre-existing metadata.

Makes sense to me.

Faiths & Powers: Spell spheres and kit pack for priests and paladins
Might & Guile: Tweaks and kits for warriors and rogues
Scales of Balance: Game tweaks and rule overhauls
NPC_EE: More options for NPCs in BGEE, SoD, & BG2EE


#29 ALIENQuake

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

Posted 20 September 2018 - 04:42 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/json 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. 

 

@subtledoctor

I think that there isn't more to discuss, I've coded it as <modname>.ini/json + [Mod] file header with better named keywords  :thumbsup:


Edited by ALIENQuake, 21 September 2018 - 12:08 PM.


#30 Wisp

Wisp
  • Modders
  • 1135 posts
  • Gender:Male

Posted 20 September 2018 - 05:24 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.





Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users