Print

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

[Button]

I was able to merge the plant and advciv one's fairly easily.  However, the direforge and plantfix modified the same area of permitted reactions of some types of drinks.

Did you happen to see if they were the same/similar modifications? I know at least one mod, which I think had Forge in the name, was going to include/expand upon the plant fixes.


By the way, what do you guys think about mods that are essentially bundles of small tweaks? Would it be helpful to users to separate them a tweak at a time, or do you think that would overwhelm with too much choice & all the tweaks should be bundled together?

Without a mod loading tool bundling seems to be the clear winner, but with a whole list to select from it might be better to include more modularity?


I'll break apart/format some of my personal mods into small feature-set mods for trying out the tools on, particularly with regards to creature variations so we can see how much of a problem that's going to be.


What are y'all's thoughts on applying graphics packs to the resulting raw monstrosity? (And I use the term affectionately). Are mods going to have to be included in graphics'd versions in order to be used with a tileset; will graphics packs be treated like just another mod, merged in at the end; or will there be special handling for graphics packs?

[King Mir]

By the way, what do you guys think about mods that are essentially bundles of small tweaks? Would it be helpful to users to separate them a tweak at a time, or do you think that would overwhelm with too much choice & all the tweaks should be bundled together?

Without a mod loading tool bundling seems to be the clear winner, but with a whole list to select from it might be better to include more modularity?

I think this would depend on the mod. Tweaks that have the same objective probably should be bundled. But unrelated tweaks, may be better off separated.

What are y'all's thoughts on applying graphics packs to the resulting raw monstrosity? (And I use the term affectionately). Are mods going to have to be included in graphics'd versions in order to be used with a tileset; will graphics packs be treated like just another mod, merged in at the end; or will there be special handling for graphics packs?

Ideally graphics will be treated like any other mod, meaning mods should be applied to vanilla, and the Mod Starter Pack would merge the mod with the graphics. It remains to be seen how practical that is.

[PeridexisErrant]

Awesome!   It looks like we're onto something 

@Thistleknot: 
Is that a working multimerge?  Wow. 
Now there's the just the comparatively simple tasks of implementing the flatten and merge functions in Python, rejecting failed merges, and then opening it up!  (Seriously, if the logic is confirmed to work that's a massive step forward)

@Button:
I think that given the novelty of easy patch based loading we might as well err on the side of many tiny patches for once - just to see what that's like!  Medium term, I can imagine that some things might amalgamate a little; to take the example of Accelerated DF it might want to divide materials into 'Generic creatures mod' and 'Generic stone and wood mod', but splitting blood from leather from shell etc would be too much. 

What are y'all's thoughts on applying graphics packs to the resulting raw monstrosity? (And I use the term affectionately). Are mods going to have to be included in graphics'd versions in order to be used with a tileset; will graphics packs be treated like just another mod, merged in at the end; or will there be special handling for graphics packs?

Ideally graphics will be treated like any other mod, meaning mods should be applied to vanilla, and the Mod Starter Pack would merge the mod with the graphics. It remains to be seen how practical that is.

Due to practical concerns, I'd lean the other way - treat graphics as a special case and assume that we're using ASCII with [graphics:no]; note that tilesets are still compatible, just not graphics. 

Some graphics packs are based on standard raws and others aren't.  This is historically to free up the tiles for accented letters for other things, but with the Text will be Text plugin that could be reversed - which would mean that the raw folder could be left entirely alone by graphics packs.  They also have to mess around with the /data folder a lot, and if we can avoid needing to touch that we probably should - separation of concerns to avoid causing yet more conflicts.  I'm aware that this limits the range of compatible mods somewhat, but I don't see encouraging a return to the baseline standard as a terrible position to take; and we can always extend later. 

[King Mir]

What are y'all's thoughts on applying graphics packs to the resulting raw monstrosity? (And I use the term affectionately). Are mods going to have to be included in graphics'd versions in order to be used with a tileset; will graphics packs be treated like just another mod, merged in at the end; or will there be special handling for graphics packs?

Ideally graphics will be treated like any other mod, meaning mods should be applied to vanilla, and the Mod Starter Pack would merge the mod with the graphics. It remains to be seen how practical that is.

Due to practical concerns, I'd lean the other way - treat graphics as a special case and assume that we're using ASCII with [graphics:no]; note that tilesets are still compatible, just not graphics. 

Some graphics packs are based on standard raws and others aren't.  This is historically to free up the tiles for accented letters for other things, but with the Text will be Text plugin that could be reversed - which would mean that the raw folder could be left entirely alone by graphics packs.  They also have to mess around with the /data folder a lot, and if we can avoid needing to touch that we probably should - separation of concerns to avoid causing yet more conflicts.  I'm aware that this limits the range of compatible mods somewhat, but I don't see encouraging a return to the baseline standard as a terrible position to take; and we can always extend later.

Graphics packs can change raws quite a bit. A quick look at Phoebus's shows that creature tiles, language files, inorganic stones, and plant files are all changed by the pack.

Graphics packs may need to be special cases, but ignoring them completely would not allow mods to work with graphics, which is a big problem.

[PeridexisErrant]

Graphics packs can change raws quite a bit. A quick look at Phoebus's shows that creature tiles, language files, inorganic stones, and plant files are all changed by the pack.

Graphics packs may need to be special cases, but ignoring them completely would not allow mods to work with graphics, which is a big problem.

As far as I'm aware this is mostly changes related to replacing tiles for accented letters with walls, floors, trees, and so on.  The CLA graphics pack I believe has a single change from vanilla raws, and still plenty of creatures. 

Basic graphics processing can probably be added within the existing framework, though I assume we'll need a non-diff compare logic for image files (messy but not hard).  I'd do that at the same general stage we apply the first round of upgrades, like avoiding flattening / destroying the book title files. 

More advanced logic might be required later, but I favour just asking graphics people to go old school + TwbT instead of modifying the raws.  There are hundreds of tile sets (which don't require graphics), thousands of mods, and maybe ten major graphics packs. 

As usual, it's not that I don't like the idea - here I even think we really need to be able to handle graphics before 2.0 - I just think we don't have the rest nailed down enough yet for it to be useful. 

[thistleknot]

Gfx should be easy. Just do a diff between ASCII n a gfx mod. And apply it to a 3rd party mod.

[PeridexisErrant]

Gfx should be easy. Just do a diff between ASCII n a gfx mod. And apply it to a 3rd party mod.
 

> non-text files
> important stuff outside the raw folder

But yeah, as long as it's last in the load order that should work. 
A manifest should probably include whether it's graphics or not, so we can enforce last-on graphics merging in known cases. 

[Pidgeot]

Basic graphics processing can probably be added within the existing framework, though I assume we'll need a non-diff compare logic for image files (messy but not hard).  I'd do that at the same general stage we apply the first round of upgrades, like avoiding flattening / destroying the book title files. 

Don't graphics packs normally only *add* image files, not change them? Unless they change existing file, you really just need to copy over those extra PNGs (and if we want to store them in a single patch file, we could always do something like using Base64 to store the entire file in a plain-text format).

There's certainly a use-case for providing individual tiles to be replaced, but simple image copying should get us pretty far, I'd think, with or without TwbT.

[PeridexisErrant]

Yes, we shouldn't ever have to modify image files, just add and remove them. Given that we're comparing to vanilla DF anyway the only graphics files are the examples, and we could probably justify a special case to discard those.

Adding the image to a text diff hadn't occurred to me, but could be useful. Maybe we do want to cover the data folder as well as the raw folder!

[thistleknot]

Guys guys guys. I'll update w a Phoebus patch. It ... Should.... Do the binary files as well. Idk. That may require manual copying... But the creature tiles hopefully will be taken care of via patch file.

[Button]

Don't graphics packs normally only *add* image files, not change them? Unless they change existing file, you really just need to copy over those extra PNGs (and if we want to store them in a single patch file, we could always do something like using Base64 to store the entire file in a plain-text format).

There's certainly a use-case for providing individual tiles to be replaced, but simple image copying should get us pretty far, I'd think, with or without TwbT.

Phoebus, which is what I use, changes most of the vermin & plant tiles as well in the raws. I'm.... not sure why? But yeah.

Separating my stuff out into diffable modular mods is ongoing, and also a pain in the butt, but I should have a couple potential-conflict mods that I know for a fact work together later today.

[thistleknot]

Phoebus-Direforge.

I don't know why, but the phoebus fonts have screwy ascii fonts EVERYTIME I try to merge phoebus with another mod.  The names of dwarf's come up with weird symbols.

It merged anyways though!

https://github.com/thistleknot/df_40_09_Flattened/tree/40-09_Phoebus_Direforged

If anything, due to github NOT COPYING binary files.  I'd start with phoebus 40_09 as a base, and extract these files over.

Here's some of the merge conflicts I get with plant and direforge
http://imgur.com/Rjvo7RL

[Dirst]

In a graphics pack, the majority of raw changes are altering display tiles and replacing accented characters in the language files.  The latter frees up a lot of space in the tileset to allow more variety in the former.

Two quick notes:

1. We can't assume someone is running TWBT, especially if we aren't going to assume DFHack is installed.

2. Graphics files in /data tend not to collide... though personally I find the Starter Pack's habit of wiping out my font.tff file a little annoying.  A diff-from-vanilla based off of a graphics pack should exclude things like the font and cursor because those weren't changed.  The ticklish bit is applying a diff to the init file since it's not in the raw or data folder.

That said, the same logic should be able to apply graphics packs like any other mod, though I'd recommend applying them last.  That could be suggested/recommended/coerced through the optional manifest file.  I'd go one further and bring along a Stonesense folder since it would be ignored if that tool isn't installed.  I'm not aware of any mods that play with Soundsense, but if there are then it ought to get similar treatment.

[Button]

Phoebus-Direforge.

I don't know why, but the phoebus fonts have screwy ascii fonts EVERYTIME I try to merge phoebus with another mod.  The names of dwarf's come up with weird symbols.

That's odd, it really should be the other way around. Unless the original language files are being prioritized?

Also, are you sure the normal and phoebus raws are using the same encoding scheme? Could be something to do with that.

Here's some of the merge conflicts I get with plant and direforge
http://imgur.com/Rjvo7RL

Oh, those should be able to merge well enough together one after the other. I mean, from a logic perspective. Obviously merge tools tend to be... a little simplistic.

[King Mir]

Changes to d_init.txt and init.txt may need to be treated specially. Maybe just let graphics modify them, then post-process the files with user settings in a script.