Bay 12 Games Forum

I have no problem with the mechanics presented, though I'm a bit curious how this would play out among NPCs.  Dwarves value craftsmanship and Elves are immortal, so in worldgen and off-site pretty much everything Dwarven or Elven is going to be really high quality.  Goblins might all be wearing crap.  So far, so good.

Now we have an Overseer telling his craftsdwarf to just bang out some stuff quickly before the caravan comes.  His OCD starts twitching at every little imperfection that he doesn't have time to fix, but his sense of duty sustains him through it.

This has Unhappy Thoughts written all over it for creatures that value craftsmanship highly.  For goods like rushed armor that stay in the fort, it could become debilitating as he sees his crappy handiwork marching through the halls. He'll want nothing more than to take some time making proper armor and replacing all of that embarrassing stuff.

I'm bringing this thread back from the dead.

I know rawexplorer does it, but does anyone have any command line scripting-fu abilities that can help us use something like sed and regular expressions to alphabetize a set of raws based on their [object:id] [id:instance] instance's?

Update:
Well, RawExplorer author just got back to me and told me to be wary of object order dependencies.

So alphabetizing might be out of the question for some things...

Well, within an object the order can be vitally important (bodypart needs to be declared before it can be given an attack, etc.).  Across objects, I think the only serious dependencies are on creature variations like giant versions and animal men.  I could be wrong on that, but this solution would handle any known dependencies:

The game loads the raws in alphabetical order using the internal name on the first line.  A convention of putting variations in a later file than base creatures would automagically guarantee that dependencies are fulfilled.  For example:

creature_subterranean
creature_subterranean_variations

creature_myawesomemod
creature_myawesomemod_variations

So I made a nice monster, basically a better fighting, flying, smaller cave dragon. I used the cave dragon RAW as a basis, but changed it some. But I want my mountain dragon to look the same as the cave dragon. How do I achieve this?

If you want them to look identical, find out what graphic is being applied in your raw/graphics folder.

I think it's this one

graphics_magnut_next_underground

[OBJECT:GRAPHICS]

[TILE_PAGE:MAGNUT_NU]
[FILE:magnut/next_underground.png]
[TILE_DIM:16:16]
[PAGE_DIM:6:8]

(snip)

[CREATURE_GRAPHICS:CAVE_DRAGON]
[DEFAULT:MAGNUT_NU:2:6:AS_IS:DEFAULT]
[CHILD:MAGNUT_NU:3:6:AS_IS:DEFAULT]

(snip)

Make your own text file such as graphics_stagnatsoul.txt with that same header and that one CREATURE_GRAPHICS entry edited to use your creature's ID.  The AS_IS tells the game to use the colors in the graphic file (rather than the colors you assign in the CREATURE raws).  You can experiment with ADD_COLOR and tweaking your CREATURE to see how ugly the results are.

Alphabetizing
I've been pondering this idea on how to alphabetize raws to address the issue of TC mods or mods that completely reorder the contents of the files.

It may be possible with regular expressions (sed, or python, or grep), but unfortunately, the solution I'm thinking of involves breaking comments that are listed right before an object would be broken apart from the next object... so, I'd rather just remove comments than try to parse them using some batch script.

A multi-line match for regular expressions should be able to scoop up everything between tags and associate it with the next valid tag.  The special cases are (1) the header up to the [OBJECT:FOO] token, (2) header comments after [OBJECT:FOO] but before the first [FOO:BAR] and (3) comments at the end of the file.  (1) and (3) should be easy.  We just have to pick a standard for (2), is it associated with the header or the first object?

PTW

Quote from: Dirst on August 19, 2014, 11:37:14 am

This still doesn't do a good job with re-ordering things.  To get that, you'd probably have to nuke the vanilla file completely and replace it using a different filename.  The launcher would detect that one mod's changes got deleted by another, but absent some advanced raw-aware logic it just isn't possible to merge the two.  That advanced logic comes... later.

We've been talking about this in the abstract, but is there a test case of two mods that we'd like to be able to merge with one doing complex reordering, and the other adding or removing stuff? At the very least we need to make sure that we properly detect that the mods can't be naively merged.

Spacefox did a lot of tidying up inside the gem raws in DF2012, but since the vanilla raws are now tidier I'm not seeing the same kind of re-organizing.  Still could use the 2012 versions a test case.

As to what Button was saying about the merge conflict:

http://www.bay12forums.com/smf/index.php?topic=142295.msg5586461#msg5586461

Quote

"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."

The fact that we could have just "added those lines on top of each other" means that could be an option to present the user.

I think the reason that happened is because one mod added 1 line, and the other mod added say 5 lines to the same spot.  Both mods/patches read the original location of that FILE AS BLANK.  Since we are only ever merging two mods at a time, since VANILLA is always our base.  If both lines expected a blank spot (can be read from patch file), and they found something there (in the case of merge conflicts).  It's safe to assume that we CAN ADD BOTH PATCHES, ONE ON TOP OF THE OTHER.

Actually, you know... now that I think about it.  Our base files don't have blank spots.  So what's happening is... their is a token mismatch.  At that point we can introduce logic on how to deal with token mismatches.  It's probably one mod realizing another mod wrote to that spot.

This is the problem I was trying to fix a bunch of posts ago by doing two passes.  Slip in bookmarks where each change is supposed to occur secure in the knowledge that no lines will actually move, then perform the actual changes at those bookmarks which could move things around quite a bit.

This still doesn't do a good job with re-ordering things.  To get that, you'd probably have to nuke the vanilla file completely and replace it using a different filename.  The launcher would detect that one mod's changes got deleted by another, but absent some advanced raw-aware logic it just isn't possible to merge the two.  That advanced logic comes... later.

I agree with GavJ, though I'm not sure what you mean by X% accuracy.

What I meant about pre-embark information is based entirely on prospect's behavior.  It gives different numbers pre- and post-embark (and the former are marked as estimates).  Since it's a cheat tool, I can only assume the lack of detail is because fine details aren't set in stone until you embark.

When reporting generic layer information, it should come with summaries based on accurate math using blind projections (that is, based on the raws, not any specific knowledge of that particular site).