Bay 12 Games Forum

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.

The building raws are, quite frankly, rather obtuse, and I don't fully undersrand them myself fully.

Well I do have some guano, eye of newt and quicksilver... so I'm ready for any black magic necessary.

Is there an example of an included 3x3 workshop that uses 9 different tiles?  I should be able to clone that at the worst.  The Still has 9 different tiles in the main interface, though that doesn't necessarily translate to the Stonesense equivalent.

Two dwarves throw a third dwarf at the bad guy? Back-to-back axe buddies?)

Nobody tosses a Dwarf!

Quote from: Dyret on August 18, 2014, 01:53:07 pm

Ï don't believe any food rots once stored, unless Masterwork has done something with that.

Trouble is, I don't have any way to store it. They won't put it into barrels or pots - I'm assuming because they don't have the capacity for it?

Just imaging a Dwarf in a chef's hat trying to balance a plate with 6015 cakes stacked one atop the other.  One of the militia comes by and puts a hand on the third-to-bottom one.  "These look tasty.  Have you ever heard of a game named Jenga?"

Quote

A manifest file (which is planned) can list dependencies, and it could also list known semantic conflicts like the one you mentioned.  Such a manifest entry could specify whether the mod is completely incompatible, or there is a required load order.

It's planned? Haven't seen it on this thread. As far as manifest files, PE said just the other day that:

Quote from: PeridexisErrant on August 17, 2014, 09:28:37 pm

I am strongly opposed to anything which would require a more complicated input than folders of changed raws, as outlined in OP.  This is because I feel having a simple, usable, standard format is very important for adoption from both users and modders.  If it becomes common to have a readme.txt and configuration.xml - to hold info such as author, name, homepage, base DF version, etc in the latter case - it would be good to use that information but their absence must be handled gracefully.

Which would seem to imply no manifest file required. If planning is going on/that requirement has been reversed elsewhere, I'll shut up and let you work, since I don't want to butt in when I don't have all the information.

A manifest is the third point on the OP, though I did overstate it a bit by implying it was a definite feature when it's just being looked at.

I do differ with PE a bit because I think asking the modder to document known incompatibilities isn't much of a burden.  If we get around to a stretch goal of using that manifest file to check for mod updates, it will ripple out to the users with minimal effort.  The thorny issue is what to do if the tool discovers an active game has a newly discovered conflict.

Warning:
You are using RampageMod v1.08 and Zootastic v2.0, and an incompatibility between these mods has been identified.

Severity:
Minor

The problem:
Both of these mods affect several mundane animals in different ways.  The combination of mods does not cause an error, but it does affect the game balance that each mod is attempting to achieve.

Recommended actions:
It is recommended that you take one of the following actions.
(1) Ensure that Zootastic is loaded before RampageMod.
(2) Update to RampageMod v1.09.
Unfortunately, none of the above changes can be applied to active game.  We apologize for the inconvenience.

Quote from: hermes on August 17, 2014, 08:32:21 pm

... Which is exactly why I'd go the route of Valdemar's stuff.  First flatten everything, then read/index all the objects/entities into structures, then do the diff patch generation on an object by object basis.  It's basically the same thing but with with the added bonus of the program being able to say explicitly what objects were deleted, what's been added and so on.  You have two levels of differences - the objects present difference, and the difference between equatable objects themselves.  The process to resolve conflicts becomes much more mechanical then, rather than holding hands up and saying, "well, it doesn't work and we don't know why".

In case 1 you'd know that the added lines of B would at least be in the correct object, and if the program was smart it could drop those lines in right after the correct preceding line.

In case 2 you'd know in what object the conflict arose and could prompt the user with relevant information.

This way would make this basic stuff easier, and open the door for more advanced stuff like making connections throughout the raws to entirely remove problem objects.  The two pass method Dirst suggests is essentially the same thing but done in a roundabout way.

The diff patch stuff is a good start and totally necessary, but IMO it'd be pointless to do this without going the route of interrogating the raws in a raw-language manner.  PE said he was adverse to an "advanced mod loader", which I understand... But I feel this way is the minimum, not an advanced feature.

I'm with Hermes.

IMO a tool that can only load a single minor mod is trivial, because most minor mods are set up to just overwrite the vanilla folder. If you want a mod loader that can load one mod at a time, it doesn't need all this logic - just a vanilla raw directory, a bunch of minor mod raw directories, and the ability to select which minor mod you want to load on top of the vanilla raw directory in the application raw folder. To load one mod, there's no need to diff. So I assume you want something that can load more than one set of raws... but merging multiple mods through diff would be a nightmare. The dupes alone... Not to mention the really problematic part of merging, creature variations.

For example, the vampires-drink-booze-fix I have uses creature variations to replace humanoids' blood with BLOOD2 or ICHOR2, which is default blood with a syndrome. Diff wouldn't find any problems loading the boozefix alongside another mod that did something to blood, but trying to load a creature with modifications to BLOOD after BLOOD has already been replaced with BLOOD2 (and so no longer exists in the creature definition)? There's no way to find those kinds of conflicts without loading raws.

Thistleknot is working on a more robust merge tool, and there's also Rubble.

PeridexisErrant is aiming for a simple way to sample mods, and for a pre-1.0 it's perfectly fine for it to be one mod at a time.  I believe that a useable tool should be able to handle some simple merging, like putting two mod's worth of PERMITTED_REACTIONs into the same entity_default.txt file, or modifying one creature when a creature before it in the same file had a line added/removed.  In this regime, two mods are in conflict only in the narrow sense that they attempt to modify the same vanilla tag.  That could be an insta-fail or a last-in-wins depending on settings, especially since load order is user-definable.

A manifest file (which is planned) can list dependencies, and it could also list known semantic conflicts like the one you mentioned.  Such a manifest entry could specify whether the mod is completely incompatible, or there is a required load order.  That presents comprehensible guidance to the player while minimizing the complexity (i.e., no recursive searches through the raws to locate unused tissues).

That should be correct.  Just don't make the mistake of setting the caste probability to 0 because that won't prevent the caste from being born.  I believe the game treats 0 as 1 in this case, but whatever it does doesn't eliminate the possibility altogether.

It treats a 0 as a 100, which is also the default for any caste without a population ratio.

.The two pass method Dirst suggests is essentially the same thing but done in a roundabout way.

I had a feeling that about five minutes thought by a dabbling coder wasn't going to overtake an entire open source community.  Glad that someone has already optimized that idea.