Jump to content

r40k2011

Supporter
  • Posts

    5
  • Joined

  • Last visited

Nexus Mods Profile

About r40k2011

r40k2011's Achievements

Newbie

Newbie (1/14)

  • First Post
  • Week One Done
  • One Month Later
  • One Year In
  • Conversation Starter

Recent Badges

0

Reputation

  1. In response to post #11579498. I agree, the only way to do things right is to specialize things. Implementation of planned features on current technology stack is a huge amount of work - and finished software will still lose to universal and tested linux package systems. Creating a GUI wrapper on top of CLI tools is more designer's job than coder's.
  2. Wrye Bash still more feature-complete than NNM. But if i would start developing this kind of software from scratch i would just reimplement gentoo linux repository and package system. There's practically no limit for what you can do with custom build scripts. You can create rules like "compress all *.dds files in category texture/landscape according to my configuration file" or "run ReProccer every time new items installed with mod". Modders would specify mods conflicting with their one in package files without needing end-users to look in description for that info. Or specify localizations, compatibility patches and optional mod features to build conditionally - in gentoo there's USE flags in which you specify features you want to be installed. Like, if you build STEP, you set USE="+core -gameplay' and it would install only core STEP mods without gameplay mods. And most importantly, mod authors could specify the load order declaratively, like "after <some esp>" - that would make tool like BOSS obsolete, because maintaining a database that large without sql-goodies must be a real pain. Also it would be nice to enforce some release quality requirements for mods on repository endpoint and automated testing for modders' uploaded packages.
  3. I wonder if there is some api for getting mod and getting file download link? I'd like to keep stable mod lists in files and automate downloads for files listed in it.
  4. Not a problem. Package manager must allow user to force installation of a package without its dependencies. It also must ask user before installing or removing anything. Every package manager on linux does that.
  5. I agree. As installation process varies from mod to mod, ebuild-like installation scripts would come handy. This way has following advantages: - Installation and data separation: it allows you to combine files from different mods like Texture Pack Combiner does. - Dependencies and prerequisites management. - Optionals management: instead of listing related mods like translations or compatibility patches on description page, mod author could specify them as optionals in ebuild file. - Small size, text format. - Rich infrastructure of text editing related tools: editors, version control, indexing. - Each ebuild could be supplied with various metainfo that allows to detect mod conflicts or improve search We also need a mod authoring framework to handle mod publishing process. But to make use of this framework, mod community should develop standards of mod publishing - requirements like mod directory structure, presence of certain files, and so on.
×
×
  • Create New...