Print

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

[Urist McTeellox]

@Urist McTeellox: Ahhh... I wanted to do work on the next release based on this patched version (because it already includes many things I want to fix anyway), but got stuck up on comparing tileset-raws with each other, testing dfhack things with r4, then downloading the plump-helmet men, wokring on Flymes animated weapons, downloading Roses big fantasy mod and dissecting it... and now its 4o'clock in the morning already, and I have produced exactly nothing.

I am *so* sorry that the tile-sets weren't in sync. This is why I should write test-cases for the tools I write.

Everything should be fixed now; there are new zips up for your pleasure.

On the topic of tilesets, am I correct that the only things which should differ between them are display-related attributes, like colours and tiles? For example, I've noticed in some tilesets ostriches are war-trainable, but in others they aren't. I can write code to look for differences between tilesets to make sure they're harmonised, which should reduce a lot of potential bugs with them getting out in the future.  (In an ideal world, I'd actually like the graphics raws to be automatically generated given the master raws and how entities should display in each tileset, since that means they can't get out of sync by hand-editing.)

~ T

[cainiao]

I think keeping only one base raw and various graphic patch scripts would be great, for simplicity and upgrade availability.

[Billy Jack]

lol

And here I was messaging Meph that I could write a script to make the necessary tile changes to the master RAWs.  Looks like everyone is thinking the same thing.

But it looks like GIT can do it easier than anyone throwing a script together to do it.

You da man, Urist!

Gonna test out the new download that you have to change the tilesets and see if my changes worked out.  I don't expect anything wrong, judging by the patchlog.

[thistleknot]

I know I'm not a main contributor.  But i've always been a pusher of patches (ever since building on the exec patches... I'm glad to see this kind of thing roll out.  It helps the mod community.

I would be one to watch the bug thread, and hand implement them, it's nice to see someone actually commit a git repository to them!

Update:
I think this post should have a link to
https://github.com/pjf/masterwork-dwarf-fortress

as it can be confusing to see where the last commit occured.  As I have to take your .zip link and truncate it to get to the source folder and see the last commit change (when comparing with comments on this thread).

[Urist McTeellox]

So, I wrote some code to find tileset inconsistencies. It's not the smartest piece of code written, but it should find all the ways in which the tileset raws have differed from the master ones. If it spots a change which only appears to relate to display tiles, then it's not shown in this output.

The results are rather long, but I've put the results online. Note that these are of *all* the tilesets, so it's quite long. You can tell which tileset is being examined by looking at the headers. Here we can see it's the 'creature_birds.txt' file in the ASCII graphics set:

Code: [Select]

--- /home/pjf/cygwin/pjf/cvs/MWDF/Dwarf Fortress/raw/objects/creature_birds.txt 2013-11-15 17:00:22.189730463 +1100
+++ /home/pjf/cygwin/pjf/cvs/MWDF/MasterworkDwarfFortress/graphics/ASCII/raw/objects/creature_birds.txt 2013-11-15 17:00:22.241730462 +1100

With each individual change, lines beginning with '-' are in the main raw files, and '+' are in the tileset specific files. Those starting with neither a plus nor a minus are the same in both files, and are provided for context. These diffs are based upon the head ( bffff6e ) of my master branch. I did that rather than the 4c branch because I've already done some harmonisation between tilesets .

The diff utility isn't smart enough to understand how much context should be given, so right now one may have to look at the original files to see which entity the changes relate to. However we can see from a glance that there are, for example, lots of differences regarding populations and cluster sizes.

Given this information I can harmonise the tilesets with the master tileset if desired. That would retain all the display-only information (which is not shown in these diffs), but otherwise change things to work the same way. We'll separate out cases where display information is mixed with functional changes for human attention, or at least a more intelligent change-control script.   I haven't yet looked through the changes extensively to tell if such a change would be wise, but I'm guessing we probably will want to do some level of harmonisation.

Obviously once our tilesets are harmonised, we can more easily check them to see if they ever get out of sync (or move to auto-generated tileset files, if that's desired).

~ T

[Urist McTeellox]

I think this post should have a link to
https://github.com/pjf/masterwork-dwarf-fortress

Wait, don't I? It should be the first link under 'Contributing' in the top post...

You da man, Urist!

D'aww, thank you! <3

Allow soap to be made from Hide Root oil.  plant_standard.txt

I was confused by that for a moment until I looked at the post on the actual forum (rather than in email) and noticed the parts in bold. Shall add it to my queue of things to do.

~ T

[Meph]

There are two ways to ease this tileset issue:

Either a code that changed all sets at once when you do a raw change. (which is proposed here quite a lot)

OR

Getting rid of the different sets. If the GUI, the VB Settings.exe that I include wouldnt replace the files with different files, but instead only opens the files and replaces the tilenumbers... than it would mean only one set of raws. In the long run this would be a lot easier, but I have no idea how to write this.

Not that I'd have any idea how to write the other code, since I am no programmer... not sure if all of you knew that. ^^

@Urist McTeellox: Quick work, amazing. I write a bugreport, go to bed, get up, everything fixed. Its weird... what happened? Suddenly I report bugs, and other people fix them? I remember it to be the other way around.

(Hey, I dont want to spoil the party, but the patchlog from the Master Branch says 7 hours ago, fixed tileset inconsistencies, the attributes... while the unified branch says authored 6 hours ago, "Distribute simpler leather patches across all tilesets."... so... ehm... Maybe I misunderstand how Git works, but it seems you had these 2 things that were missing in the tileset versions, and fixed one in each set... if they apply to both sets, just ignore me.)

[Urist McTeellox]

Either a code that changed all sets at once when you do a raw change. (which is proposed here quite a lot)

Oops, already wrote a version of this. That's why I've been able to harmonise changes so quickly. If you're working from git, then the patch-graphics-from-master.pl script will take any changes you've made (but not yet committed) and apply them to all the applicable graphics directories. It requires both perl and git to function. (If you're installing Perl, then I'm fond of dwimperl.)

Right now it has to run it manually, which I'm not fond of. In theory, one can write a pre-commit hook to detect when it needs to run, and fire it automatically. If anything goes wrong, then it's turned over to a human for assessment.

Getting rid of the different sets. If the GUI, the VB Settings.exe that I include wouldnt replace the files with different files, but instead only opens the files and replaces the tilenumbers... than it would mean only one set of raws. In the long run this would be a lot easier, but I have no idea how to write this.

There's also option 3, which is to have a single set of raws, and have code that generates the graphics files before release. Settings.exe would remain the same. The big question for either of these solutions (graphics raws produced by Settings.exe or templating engine) is how do we represent that data in a human-friendly format?

@Urist McTeellox: Quick work, amazing. I write a bugreport, go to bed, get up, everything fixed. Its weird... what happened? Suddenly I report bugs, and other people fix them? I remember it to be the other way around.

It's nice, isn't it? Most of my "successful projects" these days are simply me curating and integrating changes from other people...

(Hey, I dont want to spoil the party, but the patchlog from the Master Branch says 7 hours ago, fixed tileset inconsistencies, the attributes... while the unified branch says authored 6 hours ago, "Distribute simpler leather patches across all tilesets."... so... ehm... Maybe I misunderstand how Git works, but it seems you had these 2 things that were missing in the tileset versions, and fixed one in each set... if they apply to both sets, just ignore me.)

Unified is master, with 'experimental' branches applied to it (dfhack and simpler leather). So everything you see in 'master' should also show up in 'unified'. Depending upon how they've been merged, the extra experimental branches may show up in different spots in the history. Currently the development tree looks like this. (You can hover and click on commits to see changes.)

The 'find tileset inconsistencies' patch is this code which goes through all the tilesets and looks for places where they're potentially out-of-sync (mentioned a couple of posts up). I haven't merged it into the unified branch simply because it's not an end-user visible change. (Don't worry, it'll get merged eventually.)

I'm not sure if that answers your question; if it didn't, let me know.

~ T

[Meph]

Yeah, more trouble. ^^

It shows an error message as soon as it starts, in a textbox, ??OVMethodInterposeLinkBase@DFhack@@QAE@PAVirtual_Identity@HPAX1H@Z wasnt found in the DLL SDL.dll.

All I can do it press OK, and then DF starts, and DFhack starts... Its an errormessage by dfhack... maybe because of insolors string dump patcher, or the bin patches on the exe? Are you guys getting this as well?

[Putnam]

It's an outdated plugin. Remove cls from dfhack.init and it should say which.

[Billy Jack]

The only DFHack error I'm getting is about stockflow.plug.dll.

Nothing about SDL.dll

[Meph]

Well, I dont know, I dont care.  (Its back to r3 for now, because I simply dont have the time. My next trip starts tomorrow.)

[Urist McTeellox]

Integrating 4d into my repo now (it's already in the upstream branch). Since Billy Jack's leather mods are now in upstream, they're going to be merged into my master branch before I integrate. This means unified will only have the new DFHack as its experimental feature.

~ T

[Urist McTeellox]

4d is now integrated.

* 'master' and 'unified' branches are now based upon the 4d release.
* master still has Putnam's new itemsyndrome script, since he assures me it's r3 friendly.
* 'simpler-leather' is integrated into upstream, and so has been merged with master.
* 'unified' is now master (4d) + DFHack (and any patches we have, of course).
* Any MWDF-patch-*.zip files assume you're unzipping them over the top of a 4d release now.
* Top posts on this thread updated.

~ T

[Putnam]

I never assured you that that particular itemsyndrome is r3 compatible; in fact, if you would have asked, I would have said that it's completely and utterly incompatible with r3 and would require a complete rewrite.