Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

Vanilla DF 40.x

Still playing Masterwork for DF 34.x

Both equally.

Both, mostly the new vanilla.

Both, mostly Masterwork.

[Samarkand]

Mod starter pack sounds good. How will you decide what mods to put in?

Any mods that will work and that I have permission to. I can legitimately include pretty much anything; all I need is a sufficiently robust creature variation system to patch stuff in to creatures just in case everything is modified. I could probably also program in better categories to the mod manager to make it less hackish and more like legit categories (filtering, mutual exclusivity, prerequisites etc.)

I'm super excited!

[Meph]

Dont forget tilesets and utilities. They are one of the reason people like MDF and the Starter Pack so much, it comes with all that comfort pre-installed.

[fricy]

Mod starter pack sounds good. How will you decide what mods to put in?

Bribes of course!

Any mods that will work and that I have permission to. I can legitimately include pretty much anything; all I need is a sufficiently robust creature variation system to patch stuff in to creatures just in case everything is modified. I could probably also program in better categories to the mod manager to make it less hackish and more like legit categories (filtering, mutual exclusivity, prerequisites etc.)

Perquisites and filtering is a very good idea. I was thinking two mutually exclusive categories, to make it a bit more sane: total conversions and a mini mod collection.
And any mod manager need to be cross-platform imho, there are two candidates for development at the moment:
PyLNP
Dricus's Java launcher

But before you start coding: Keep in mind that if we start adding mods the generated saves will not be compatible, so a batch apply graphics/mods whatever will break them if done the old way. Handling of the save games and the general workflow needs to be redesigned, and we'll need a /save config file to tell the mod manager what mods are installed, what graphics, init settings, etc.

And another thought: Anyone would have problem with collecting user data? I'm all for knowing which graphics pack is actually used, and collecting statistics about mod usage would be useful too.

[fricy]

Mod starter pack sounds good. How will you decide what mods to put in?

/intentional double post
I gave it some thought, and I think this can work:
First organize a central mod repo on github/dfhack/mods. Any modder can submit their contribution as long as its on a public github repo and conforms to the standards. The starter pack/mod packs pull from this repo.
Next step is to collect user data, preferably play hours or fort age, maybe number of adventurers, if it doesn't work then the number of mod installations, but that's shaky ground, because it's not that representative, and can be used in a hacky way if someone wants to push their mod to the top.
From this data we could generate nice charts for our pleasure, and use it to prune the mod list every two months or so, drop the least used ones and add new ones. Requiring a public repo for submission would solve the problem when a mod is dropped from the pack, but some user still needs the files, and'd make it possible for the user to try out mods that are not (yet) in the pack. Plus autoupdate which is one of my whims.

[Putnam]

I'm already using Warmist's DFHack built-in mod manager. Due to this, the collection can be kept relatively small and just be placed into any sufficiently vanilla with DFHack install (Peredexis starter pack, for example) without issue.

The modified mod manager script might have to come packaged, but all things considered that might not be necessary by the 0.40 release of DFhack.

[Angle]

Don't drop mods unless thery're no longer compatible. Eve if somethings not popular, it's still worth keeping around.

[thistleknot]

so I'm busy remerging accelerated mod using github.

I've learned a few new tricks, github kind of makes things easier.  Tbh it's like that 3rd party tool that merge's mods, but I trust github a little bit more due to the way it handle's conflicts and marks them.

Anyways, it sure would be nice if there was a way to generate patch files

then apply them in reverse to get mods at a common denominator level (say remove phoebus from accelerated mod 34_11, and remove phoebus from 40_06.  So you have a base difference between 40_06 and 34_11 accelerated.

I can't use ascii for this purpose due to the new tile #'s that phoebus set's.

Idk, just an idea.

**Update**:
I was able to use github to extract versions, then use winmerge to create a contextual diff, and apply patches, and just keep the successful patched files, those with rejects, I would go one by one. Cut out about half the work.  Although, the idea of reverse applying patches (something that IS possible with patch), might be able to resolve a lot of failed patching.

[fricy]

Don't drop mods unless thery're no longer compatible. Eve if somethings not popular, it's still worth keeping around.

Dropping mods will be necessary IF the list gets too long, that's how it is.
Too much information can be as bad as too little, if you present a cluttered list then it's the same as not providing a list at all... Ever heard of TL;DR? People are lazy, and you have to design around that.
I'm proposing the public github repo as a requirement as a solution to this: even if the mod is dropped from the pack, there's nothing keeping you from adding it back to your private list, only it won't be distributed any more by the pack author. Even better, the user data collection could tell us if there's a mod that's becoming popular, but not yet in the pack, or if a dropped mod is indeed played at all.

I'm already using Warmist's DFHack built-in mod manager. Due to this, the collection can be kept relatively small and just be placed into any sufficiently vanilla with DFHack install (Peredexis starter pack, for example) without issue.

Yeah, I'm not sure the built in mod-manager is the way to go: It'd need diff-merge capabilities and compatibility checks built into dfhack if things get hot, and you need to take into account that most of the users will want to apply graphics packs too, which I was thinking would need to be the the at the last of the mod-install workflow.
Elaborating on this: what we discussed in the PyLNP thread is a merge together approach: There's only the default set of raws distributed with the pack, and every mod/ graphics set would only exist as a set of patches that the launcher merges "on the fly" before worldgen. Kind of like the rubble approach, maybe done differently, I don't know, that's for the modders and the coders to decide.
But as I understand things, the workflow with this approach'd be to patch ascii with the mods, and then apply the tileset, but if you are using the mod-manager you need to have launched DF already, at which point you need to relaunch the game for a new tileset. Correct me please if I'm wrong. Maybe TWBT can do this.

And also: it's a kind of text-only interface, which is ok for lot's of people, especially the IT guys, but they are the ones that has no problem with installing stuff anyway. This is for expanding that user base.
So for now: my 2c is to go with a "fancy" interface and make it as streamlined as possible.
/welcome thistleknot

[Meph]

and I am just sitting here, writing my raws...

Good luck guys.

I would advise to use a fancy graphical interface with mouse support and tool tips and all that. Presentation, as I mentioned several times above,is among the most important things for a mod.

[Angle]

Just add some good sorting algorithms. So you can look up mods by popularity, by size, by keyword, etc.

[Meph]

popularity would require some form of data collection. size is not really something you can determine, since even small raw changes might have massive effects on gameplay. Keywords, yes, if modders add enough of those.

The main issue I see is updating. You will depend on the author of every mod and every utlitiy and every script to update it, once a new version is out.

[fricy]

popularity would require some form of data collection. size is not really something you can determine, since even small raw changes might have massive effects on gameplay. Keywords, yes, if modders add enough of those.

Data collection can be done with dfhack, just have it log the play hours of a fort and we'll need to store the list of mods in a world anyway somewhere, so we can have that info too. Then the launcher submit this information to a database of your choice - suggestions are welcome. Not every user will opt-in of course, but even then the information collected this way will help determining which mod to include. Or feature: we can have the cake and eat it too, if we have a reduced list based on popularity maintained by the pack authors, and a full list that you can pull if you're looking for something different.

The main issue I see is updating. You will depend on the author of every mod and every utlitiy and every script to update it, once a new version is out.

Hence my github approach: If you want the mod in the pack put it on github. The maintainer of the pack pulls the changes, and pushes them to the users. Or the launcher pulls the updates from the repos. Scripts will need to go next to the save anyway. Then remerge the raws based on the updates. Easy in theory.
The problem is with the rules of merging these changes into saves. There will be updates that break save compatibility, and there will be updates that don't. The mod manager will need to know which can be merged and which change needs a new world. This will be tricky, and Putnam's expertise will be absolutely needed for pulling this off.
Also: just realized that there will be script conflicts too, so it's high time they get some standardized versioning system in place, so we at least know which script is newer when two mini-mods wants to install the same script.

[Putnam]

The DFHack mod manager is written in Lua. I or Warmist could do diff-patching, filtering etc. Without too much trouble, I'd think. Heck, even dupe protection.

I can work in Python. PyLNP is the obvious next choice after mod-manager. The main problem is that mod-manager allows for easy additions--just throw some raws in there and an init.lua with only a few minor adjustments per mod and you have a new mod added, no need to add anythimg to the mod manager to support it except in maybe some extreme circumstances.

[Meph]

Save compabitle it will never be. Too many changes require a worldgen, and deleting things might corrupt your save. I dont think that the launcher should access the saves at all. Only exception could possibly be tilesets, but you already mentioned the issues with that. Its the one reason why Masterwork doesnt have this feature... I cant change tilesets in saved games, because I dont know which settings a player used when he generated it.

Easy in theory. => For the user, or for the modders? Because there are a selected few who use github, who have some sort of coding background/knowdledge. The overwhelming majority of modders does not use github, they simply use notepad and dffd.

[fricy]

Its the one reason why Masterwork doesnt have this feature... I cant change tilesets in saved games, because I dont know which settings a player used when he generated it.

Why not store the settings in a config file next to the raws upon launch? If the user gens a world the config gets copied to the save raws. Next launch if the user wants to change graphics read the config and generate new raws with the saved settings on a per save basis. I don't see the problem with this, except of course when you have made save corrupting updates, but that can be determined before making the update.

Easy in theory. => For the user, or for the modders? Because there are a selected few who use github, who have some sort of coding background/knowdledge. The overwhelming majority of modders does not use github, they simply use notepad and dffd

I know of your aversions to github, but:
a, it's free to use
b, it's not an IDE, not for writing the raws/code, just a version control system. Set it up once, tell which folder stores your work, then after you closed notepad start the github gui, or if you prefer command line and push your changes. That's it, +1 minute maximum. Even easier than .zipping the mod and uploading to dffd. Merging is only needed if more people work on a project, and there are conflicting changes. Then every mod can be linked as a submodule into a public repo that's kept up to date automatically or with minimal oversight.

I can work in Python. PyLNP is the obvious next choice after mod-manager. The main problem is that mod-manager allows for easy additions--just throw some raws in there and an init.lua with only a few minor adjustments per mod and you have a new mod added, no need to add anything to the mod manager to support it except in maybe some extreme circumstances.

I'd prefer PyLNP for the better presentation capabilities, but I see no reason why we should drop warmist's format if you think it could work.
EDIT: One more reason for PyLNP: some of these "mods" will be as simple as enabling a plugin, like diggininvaders. Can that be done from the mod-manger? It definitely needs to be among mod settings, no reason to put one in the launcher the other into the game, that just leads to confusion.