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.

[thistleknot]

I had some hope for this program

https://code.google.com/p/google-diff-match-patch/

if it can do what it promises to, it could resolve a lot of conflicts when doing [mod] patches auto-magically.

My main issue with patching, is I can't seem to get an interactive setup for viewing the patch differences (such as with kdiff3, or winmerge's ability to see them side by side).  So, I export to a reject file, and the reject file was missing all header file info, it was useful pretty much.

[fricy]

I had some hope for this program
https://code.google.com/p/google-diff-match-patch/
if it can do what it promises to, it could resolve a lot of conflicts when doing [mod] patches auto-magically.

Thx, I'll take a look.

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.

Ok, I can see one problem: when the user has generated two or more worlds with different settings, and the df/raws and the region/raws won't match. That can be solved by alerting the user, asking feedback which save he/she wants to play, and maybe archiving the other save folder somewhere until the user needs it.

[Angle]

I had thought it doesn't matter if the raws match, cause the region raws override the others? I've genned multiple masterwork worlds with different settings and had it work fine.

[Meph]

I had thought it doesn't matter if the raws match, cause the region raws override the others? I've genned multiple masterwork worlds with different settings and had it work fine.

You are creating new folders, so no problem. Fricy was talking about adding changes to already made worlds.

[Angle]

Ah, yeah that's difficult.

[Putnam]

What's with all the github xtuff? Obviously I'm using it, I use it exclusively for mods now (I hate 40 MB uploads...)

[fricy]

I had thought it doesn't matter if the raws match, cause the region raws override the others? I've genned multiple masterwork worlds with different settings and had it work fine.

You are creating new folders, so no problem. Fricy was talking about adding changes to already made worlds.

Yeah, I may be misunderstanding how data/raws and region/raws interact. So far I thought they have to be identical for everything to work correctly. Is this not the case? What kind of difference is tolerated by the game? Is it only needed for the graphics?

What's with all the github xtuff? Obviously I'm using it, I use it exclusively for mods now (I hate 40 MB uploads...)

Spoiler: Mod manager flowchart (click to show/hide)

Here's the system I envisioned: Everything in this flowchart (except the bottom level) is organized via github submodule/subtree linking, so updates should propagate to the user automatically or with minimum maintainer interaction.
This model would simplify package maintenance, keep the mods/graphic pack in sync across platforms, keep the end user always up-to-date without needing to download the same old 100mb .zip from dffd, and then run upgrade scripts or copy save games. As a side effect it'd also lower the bandwidth usage of ddfd, which may result in lower cost for Toady as well.

The central mod/graphics repo should be modareted/trimmed/pruned so the new players are not overwhelmed by options, but there should be a way for the advanced users or the pack maintainers to add mods to their repo/local install if it's missing from the central repo. (see minimod 5 and 6 on the chart)
DFFD would still be needed, the github license agreement advises against using the service for general distribution. An update services like in the flowchart would be within service terms however.
So please criticize, tell me if it could work, or what kind of obvious flaws I'm missing.

[Meph]

Obvious flaws: Most mods are made for specific tilesets. If modders add plants, vermin, inorganics that occur naturally, grasses, trees or tools, they have a tile mapped to them in the raws.

I may be misunderstanding how data/raws and region/raws interact.

There is no data/raws folder. Everything in the data folder is save-unrelated, it will stay across tilesets. Which might cause a problem if you have Save1, generated with Masterwork and the Masterwork tileset, and Save2, playing Genesis with the Ironhand tileset. Because your data folder can only have 1 tileset at a time, and the game doesnt realize to which save it fits. So people that just played their Genesis fort, then load their older Masterwork fort will suddenly look at broken ironhand graphics, because the raws in the save are configured for another tileset.

If your mod starter pack offer 5 tilesets, but includes a mod that has only been written for 1, you will face a choice: Do the other 4 tileset versions yourself, which is a lot of work for every mod. Or add them with the note "this only looks good with tileset X", which leads to lots of combinations of mods that dont look good together.

The save updating: You are correct, the raws have to be the same. I think I misunderstood you, about adding mods to already existing saves. Thats mostly not possible. Altering previous content yes, but adding new stuff, no.

You will also do some manual refitting, for example the embark profiles. If 2 mods include them, and they are just called "team X does this" and "embark with low economy" and "starter group with pickaxe", then people dont know for which race and mod they are. So no matter how good the script-merging is, same things have to be done by hand, like adding "(Genesis, Sylvan-Civ) Starter group with pickaxe" to it.

Mods that include the same named objects, with different IDs are also important. If both MDF and Genesis introduces a platearmor set, the scripts will add both, because they have different IDs. But players ingame will only see the name, so their forges and stockpiles and stocks... they will have two identical entries called "platearmor" and "platearmor" and they wont know which is which.

[fricy]

Obvious flaws: Most mods are made for specific tilesets. If modders add plants, vermin, inorganics that occur naturally, grasses, trees or tools, they have a tile mapped to them in the raws.

If the modders only add stuff (compared to eg. vanilla ironhand) that can be dealt with. If they change things, or diverge from the basic phoebeus, yeah that's not good.
I think 98% success can be achived by changing the raw generation flow to: ASCII -> patch graphics changes -> patch mod changes (as opposed to the previous idea: ascii -> mod -> graphics) -> I'm talking about raw/objects here, and keep in mind that we don't want to overwrite files, but merge the changes.
As for raw/graphics: what kind of changes are there? These'd be additional sprites and configs, or do the modders modify the existing configs? I'm not sure. But diff-merge could work here too.

Code: [Select]

If your mod starter pack offer 5 tilesets, but includes a mod that has only been written for 1, you will face a choice:
Do the other 4 tileset versions yourself, which is a lot of work for every mod. Or add them with the note
"this only looks good with tileset X", which leads to lots of combinations of mods that dont look good together.
On the other hand, if there's a mod manager that can spare you the time to hand-make 5 raws sets for 5 g.packs, because it can generate you all 5 IF you follow the guidelines (to be discussed...) I think that's a strong enough initiative to use it. Of course there's the obvious problem, when someone creates extra sprites for their mod with a particular style (eg ironhand), but nothing can fix that.

There is no data/raws folder. Everything in the data folder is save-unrelated, it will stay across tilesets.
Which might cause a problem if you have Save1, generated with Masterwork and the Masterwork tileset, and Save2, playing Genesis with the Ironhand tileset.
Because your data folder can only have 1 tileset at a time, and the game doesnt realize to which save it fits. So people that just played their Genesis fort,
then load their older Masterwork fort will suddenly look at broken ironhand graphics, because the raws in the save are configured for another tileset.

Yes, I meant df/raws. So when loading worlds nothing gets loaded from df/raws? Not even df/raws/graphics? Everything comes from region/raws? Just double checking.
Because that's a problem. That's why I proposed previously that the launcher should ask you which save folder you'd like to play, so you can choose the appropriate tileset too.
Another, better solution - which may, or may not be possible- is to use dfhack to "hijack" the folder config.
Proposition: when launching the game everything is loaded as it is now. But when you select a save game a dfhack function "overwrites" the location of the tileset and .init in memory, and loads it from region/art and region/init. After all I've seen mifki do with the rendering, I'd be surprised if this was not possible. If not, we could still ask Toady to change this in the game, it'd be logical to have the tileset next to the save, if the graphics are already there. But that may take a long wait.

Code: [Select]

The save updating: You are correct, the raws have to be the same. I think I misunderstood you, about adding mods to already existing saves.
Thats mostly not possible. Altering previous content yes, but adding new stuff, no.
I think we can skip this, while bug fixing updates could be inserted into existing saves (like correcting bugged reactions) it'd generate a hell of support request when players don't understand while the new entities are not there. Better leave it out, at least for now.

Code: [Select]

You will also do some manual refitting, for example the embark profiles.
/snipPerhaps add a suffix to the profile indicating which mod it was made for? I'm not sure if it's a big problem, you're going to choose the raws anyway, changing the embark profiles and the worldgen settings too looks like a logical extension anyway. Just one more thing to add to the list.

Code: [Select]

Mods that include the same named objects, with different IDs are also important.
/snipMerging Genesis and MDF together is something someone will obviously try and fail. That's a bit extreme example I'm not sure we even need to consider that scenario.
What is realistic is like taking Accelerated mod and adding the MDF Gnomes to it. For eg. If MW is added to the mix I think it should be in a modularized form: rip it apart, so all races are a standalone mod, stronger invaders are another mod and so on, with simplified materials as a prerequisite. Then we can put it together in a different configuration.
But yeah, I can see the problem with conflicting IDs. Sigh.

[Meph]

Yes, I meant df/raws. So when loading worlds nothing gets loaded from df/raws? Not even df/raws/graphics? Everything comes from region/raws? Just double checking.

Everything comes from data/x. Nothing comes from raw/x.

Merging Genesis and MDF together is something someone will obviously try and fail.

Oh, come on. No Masterwork Fallout Genesis of the Rings of forgotten Realms?

As for raw/graphics: what kind of changes are there? These'd be additional sprites and configs, or do the modders modify the existing configs?

Well, for example the CLA tileset adds creature sprites to all vanilla creatures. But obviously modded creatures would look fundamentally different. New nobles alter the existing graphic files as well, both the images and the texts. Lets say I add a psychiatrist, I have to add the image of it to phobues_dwarves.png and graphics_phoebus_dwarves.txt. But if another mod adds another noble to the dwarves, he alters the same files. I am sure the github or diff-whatever-you-are-talking-about can handle the text files, but can they merge images?

In the end, what I am saying is: Whoever moderates that project will have to alter the mods slightly by hand to make them fit together better.

[fricy]

Well, for example the CLA tileset adds creature sprites to all vanilla creatures. But obviously modded creatures would look fundamentally different. New nobles alter the existing graphic files as well, both the images and the texts. Lets say I add a psychiatrist, I have to add the image of it to phobues_dwarves.png and graphics_phoebus_dwarves.txt. But if another mod adds another noble to the dwarves, he alters the same files. I am sure the github or diff-whatever-you-are-talking-about can handle the text files, but can they merge images?
In the end, what I am saying is: Whoever moderates that project will have to alter the mods slightly by hand to make them fit together better.

In that case the obvious guideline is to add any new sprites to your_very_cool_mod.txt and your_very_cool_mod.png, and if there's a conflict delete the conflicting creature from graphics_phoebus_dwarves.txt. That could be handled easily.

Oh, come on. No Masterwork Fallout Genesis of the Rings of forgotten Realms?

I'm too old for figuring that out. And I'm not THAT old really. I think the possibility of merging together two total conversions can be ruled out. That's just crazy, I'll be happy if we can pull this off.

[Meph]

you misunderstood the first one. Its not a new creature, its a new sprite for an existing creature... it has to be in the same file. And the file is dictated by tileset used, not by the mod. But I think its a minor, and purely hypothetical issue atm.

[PeridexisErrant]

Wow, long thread to catch up on. 

As for Reddit:  I'm a mod there.  We felt was inappropriate to list MW but not other mods; with another reorganisation here we now list the modding forum, and the boards for releases and MW.  I do see it as a problem when people recommend MW for the FPS - seriously, try Accelerated or Essential DF - but there's not much we can do in more general problems of omission.  I think the solution mostly has to be more visibility and ease-of-use for other mods, which is what I really want to have a go at.

More generally: 

I've wanted to include optional mods in the starter pack for ages.  Stuff like the broken arrow mod (before the recent fixes), accelerated DF, modest mod, etc; all would be a nice complement to the pack.  More content focussed mods would also be cool.  The biggest problem is that mods and graphics require some skill to merge, and it's a non-trivial task to automate it - putting a GUI on top is relatively easy.  My strong proposal for an approach is to go for something standard and cross platform, extend it rather than replacing it, and start small then expand the scope once we have something working. 

This is basically either PyLNP, or Dricus' launcher.  I'd prefer the former for dependency minimisation and because I can read Python, but it's not a big deal either way.  Communities which can code have a bad habit of just making a new thing when they're not happy with the current one; it's great for the people involved and sucks for users. 

Both content mods and graphics mods would need to be focussed on a narrow scope, to avoid clashes.  Graphics now have exciting possibilities in returning to ASCII raws and using TwbT to extend beyond that; it would go further than the current system graphically, work better with other mods (especially in a patch system), and still work acceptably without DFHack.  Many minor mods could probably move to a patch system without drama, major mods or total conversions would be more difficult - I would start with the practical and then see where we are.  Imagine something like the way mods are loaded in Skyrim:  you could list the available mods including graphics, drag the selected ones into a load order, and have it flag the selection green (no clashes), orange (some mods overwrite each other / load order matters), or red (resolve clashes manually).  This would allow including all kinds of interesting combinations - including major mods, with fewer extra things - and naturally encourage experimentation. 

I don't know enough about how graphics are handled, but it would be great if we could pull them out to a single file that listed what tile to use for what thing or creature.  We should also ask Toady about using regionX/data/* more, as it would enable much more fluid switching between mods or a large and small fort (etc), and it's not much harder to keep the core stuff in sync across folders with a launcher - we already do for onload.init and a bunch of other things.

[Meph]

I fully agree with what he said.

Take the LNP or starter pack launcher, add a large selection of minor mods. Make some nice-ish manual with some screenshots, something that shows them well. Release it, wait for feedback. If positive, add more mods. If you stay with simple things like new workshops, its as simple as toggling the entry in the entity file that permits it, it only changes one line of code, similar to how the AQUIFER tag is toggled with the launcher at the moment.

[palu]

A launcher you might want to look at is the Manila Dwarf Fortress Launcher, seems to be designed for just this. Don't know if the source is available, but you could at least take some ideas.