krane: a cross-platform anim.bin/build.bin decompiler

[simplex]

I have written a anim.bin/build.bin decompiler, uploaded as part of the ktools. It turns the game's animations and builds into a Spriter project, where they can be edited and converted back to the game's format using the mod tools.

It also doubles as a tool for marking atlases, shading the regions which get clipped by the game, to ease atlas editing.

Alongside the cross-platform source release, I also included precompiled Windows binaries, for convenience.

[chromiumboy]

Wow, that sounds excellent! I look forward to playing around with it!

[simplex]

Wow, that sounds excellent! I look forward to playing around with it!

That's good to know. I hope you (and the modding community as a whole) will find this useful.

[DeathDisciple]

Amazing, I'm sure I'll be (ab)using this in the future

 

I have a kinda-unrelated question, which version of imagemagick did you use to link to mingw (if you did)? Cause those two never worked nicely for me in the past.

[simplex]

Amazing, I'm sure I'll be (ab)using this in the future

 

I have a kinda-unrelated question, which version of imagemagick did you use to link to mingw (if you did)? Cause those two never worked nicely for me in the past.

I didn't try to compile the ktools with MinGW. The tested scenarios were gmake/gcc under Linux, VS2010 under Windows and gmake/XCode under OSX (this last case being tested by @debugman18).

Though I did cross-compile ktech to Windows from Linux using MinGW in the past, so it should be possible. The major inconvenience is that the standard, installable Windows ImageMagick releases are compiled with VS, and thus incompatible with a MinGW application (especially a C++ one, due to differences in name mangling). There is a precompiled binary release for MinGW (look under "Unix Binary Release"; and ImageMagick may be compiled from source with MinGW, which I did back then when cross-compiling), but since it's not installable I'm not sure there's an easy way for CMake to find it automatically. I may need to expose an option for the user to manually specify the paths to ImageMagick's include and link directories.

[DeathDisciple]

I didn't try to compile the ktools with MinGW. The tested scenarios were gmake/gcc under Linux, VS2010 under Windows and gmake/XCode under OSX (this last case being tested by @debugman18).

Though I did cross-compile ktech to Windows from Linux using MinGW in the past, so it should be possible. The major inconvenience is that the standard, installable Windows ImageMagick releases are compiled with VS, and thus incompatible with a MinGW application (especially a C++ one, due to differences in name mangling). There is a precompiled binary release for MinGW (look under "Unix Binary Release"; and ImageMagick may be compiled from source with MinGW, which I did back then when cross-compiling), but since it's not installable I'm not sure there's an easy way for CMake to find it automatically. I may need to expose an option for the user to manually specify the paths to ImageMagick's include and link directories.

 

The reason I asked for a version is because 6.8.9.0 does not compile on mingw (at least not for me, throwing compile time errors), so I had to dig 6.8.8-10 sources to actually build it on msys/mingw on windows. Trying to link over their unix mingw binaries work but running it that way is throwing an error that suggests libraries are built with different compiler/memory model.

 

And yeah cmake -G "MSYS Makefiles" tries to link over windows imagemagick installation libraries, but after all you have to do to make imagemagick and delegate libraries (notoriously either missing or outdated or not being detected on default mingw installation) it's hardly gonna be the biggest issue. Still, I'm not sure what you mean by 'not installable'? make install threw it properly into /local/include /local/lib etc, can't cmake somehow check normal library paths and such for them? I've no idea, just guessing..

 

Oh and I turned -mwindows to -mconsole so I can actually see output, and there's extra strsafe.h in posix.hpp

 

(runs away dodging tomatos and rotten eggs >.>)

[simplex]

The reason I asked for a version is because 6.8.9.0 does not compile on mingw (at least not for me, throwing compile time errors), so I had to dig 6.8.8-10 sources to actually build it on msys/mingw on windows. Trying to link over their unix mingw binaries work but running it that way is throwing an error that suggests libraries are built with different compiler/memory model.

Well, you can safely use version 6.8.8 (or older), there aren't any dependencies on new features. Did 6.8.8-10 compile cleanly by a simple "./configure && make"?

And yeah cmake -G "MSYS Makefiles" tries to link over windows imagemagick installation libraries, but after all you have to do to make imagemagick and delegate libraries (notoriously either missing or outdated or not being detected on default mingw installation) it's hardly gonna be the biggest issue. Still, I'm not sure what you mean by 'not installable'? make install threw it properly into /local/include /local/lib etc, can't cmake somehow check normal library paths and such for them? I've no idea, just guessing..

The only required delegate library is libpng. Did you have to manually and separately install it?

And by "not installable" I meant the binary MinGW release has no Makefile or any other automatic means of installation. When installing it from source you can install it, of course.

CMake should be searching the standard paths. Provided it's not finding a Visual Studio version of ImageMagick before, the MinGW one should be properly found.

[DeathDisciple]

Well, you can safely use version 6.8.8 (or older), there aren't any dependencies on new features. Did 6.8.8-10 compile cleanly by a simple "./configure && make"?

Yes

 

The only required delegate library is libpng. Did you have to manually and separately install it?

 

I tried getting binary from gnuwin but it wouldn't detect it for some reason (and it was outdated anyway). Might've been a version problem, funny part is, jpeg tiff and some others were working as delegates from binaries just not what I really needed to work Then I got sources for libpng-1.6.10 but they wouldn't configure because it wouldn't detect zlib (which mingw does/should ship with...), built zlib 1.28 manually and replaced with that, after which it finally built proper.

 

 

CMake should be searching the standard paths. Provided it's not finding a Visual Studio version of ImageMagick before, the MinGW one should be properly found.

 

Hah, that's why, I did install VS binary release too, not a usual use-case I guess. Not an issue then.

[NikMik]

Sorry 'bout posting this on oth the download page and this, but I thought I'd post here with more info.

 

So, I tried using the .exe first because I suck at things, but it comes up with:

G:\My folder/ TEXTool\ktools\krane.exe: Required argument missing: INPUT-PATHUsage: G:\My folder/ TEXTool\ktools\krane.exe [OPTION]... [--] <INPUT-PATH>...<OUTPUT-DIR>Try 'G:\My folder/ TEXTool\ktools\krane.exe --help' for more information.

and then closes after about a second. Took me 5 tries to actually get a screenshot so I could read it.

There's nothing really about the .exe apart from the commands, so I'm not sure if I do need things from the source.

 

 

I have ImageMagick and Cmake, but soon as I hit "configure" on Cmake it becomes unclickable without just going 

Error in configuration settings.

And I, knowing nothing more than lua and some basic other stuff, just went "Damnit" and am now asking here.

 

I'm not sure if there is something I'm missing, because I do have a problem where I need every single little detail or else I'm as stuck as a shoe on a powerline. Damnit, Dyslexia.

[simplex]

I tried getting binary from gnuwin but it wouldn't detect it for some reason (and it was outdated anyway). Might've been a version problem, funny part is, jpeg tiff and some others were working as delegates from binaries just not what I really needed to work Then I got sources for libpng-1.6.10 but they wouldn't configure because it wouldn't detect zlib (which mingw does/should ship with...), built zlib 1.28 manually and replaced with that, after which it finally built proper.

That's way more trouble than I'd like a Windows user to go through for compiling it . MSys needs a package manager...

I'm glad you got it working, though. I updated the README to better account for the steps needed to compile it under MinGW. But, if I may ask, was there any particular reason why you preferred to compile the ktools yourself, instead of using the Windows binary release I posted?

 

Hah, that's why, I did install VS binary release too, not a usual use-case I guess. Not an issue then.

The VS binary release (the versions with an installer) sets a registry entry pointing to the path of the library. CMake first checks for this registry entry, and if it's there that's what it uses to find the library. Only if it is not found will it probe standard directories for ImageMagick.

---

 

Sorry 'bout posting this on oth the download page and this, but I thought I'd post here with more info.

So, I tried using the .exe first because I suck at things, but it comes up with:

G:\My folder/ TEXTool\ktools\krane.exe: Required argument missing: INPUT-PATHUsage: G:\My folder/ TEXTool\ktools\krane.exe [OPTION]... [--] <INPUT-PATH>...<OUTPUT-DIR>Try 'G:\My folder/ TEXTool\ktools\krane.exe --help' for more information.

and then closes after about a second. Took me 5 tries to actually get a screenshot so I could read it.

That's what it's supposed to do . It's a command-line tool, so it won't fire up any GUI. You should open cmd.exe, type in (or paste) the path to krane.exe, followed by the path to the input folder (where the build.bin, anim.bin and atlas-0.tex are), followed by the path to the output folder (where the Spriter project will be placed). If any path has spaces in it, it should be surrounded by double quotes.

Did you check the usage examples in the README?

 

There's nothing really about the .exe apart from the commands, so I'm not sure if I do need things from the source.

I have ImageMagick and Cmake, but soon as I hit "configure" on Cmake it becomes unclickable without just going

Error in configuration settings.

And I, knowing nothing more than lua and some basic other stuff, just went "Damnit" and am now asking here.

I'm not sure if there is something I'm missing, because I do have a problem where I need every single little detail or else I'm as stuck as a shoe on a powerline. Damnit, Dyslexia.

You don't need to do anything with the source, no. But I'm curious about your CMake error, did it print anything else besides "Error in configuration settings."?

[DeathDisciple]

That's way more trouble than I'd like a Windows user to go through for compiling it . MSys needs a package manager...

I'm glad you got it working, though. I updated the README to better account for the steps needed to compile it under MinGW. But, if I may ask, was there any particular reason why you preferred to compile the ktools yourself, instead of using the Windows binary release I posted?

 

It's not the first time I have to jump through hoops for imagemagick mingw issues, tho it's been a while and I had gotten out of loop with the whole thing. It's also possible my installation is messy, like I said I should not have needed to manually install zlib at all. And tbh it does have sort of a package manager in a way of mingw-get but that doesn't really help when the libraries are not available on whatever repo it's connecting to to begin with.

 

A price to pay for lightweight-ness I guess. Or perhaps I should've went with mingw64 fork (if you can call it that) instead of default one.. as I said before, I'm out of loop.

 

As to why rebuild, *shrugs* your fault for posting a repo... guess I was bored enough, why use prebuilt stuff when you can build it yourself. At some point in space and time it might become useful, or maybe I'm just a master of waste of time. At least I don't have to wait for x timeouts on klei download page until it starts working

[NikMik]

That's what it's supposed to do . It's a command-line tool, so it won't fire up any GUI. You should open cmd.exe, type in (or paste) the path to krane.exe, followed by the path to the input folder (where the build.bin, anim.bin and atlas-0.tex are), followed by the path to the output folder (where the Spriter project will be placed). If any path has spaces in it, it should be surrounded by double quotes.

Did you check the usage examples in the README?

 

You don't need to do anything with the source, no. But I'm curious about your CMake error, did it print anything else besides "Error in configuration settings."?

Ahhh, I see. Again.... Damnit, Dyslexia. I feel dummer than a foam dummy that fell down the stairs into a pit of flaming cacti.

 

And nope. Nothing but that. I probably just screwed up so bad it didn't know what to do.

[simplex]

It's not the first time I have to jump through hoops for imagemagick mingw issues, tho it's been a while and I had gotten out of loop with the whole thing. It's also possible my installation is messy, like I said I should not have needed to manually install zlib at all. And tbh it does have sort of a package manager in a way of mingw-get but that doesn't really help when the libraries are not available on whatever repo it's connecting to to begin with.

 

A price to pay for lightweight-ness I guess. Or perhaps I should've went with mingw64 fork (if you can call it that) instead of default one.. as I said before, I'm out of loop.

ImageMagick is a very standard library in the *nix world, so MinGW really should have it as a package... it's a shame it doesn't.

 

As to why rebuild, *shrugs* your fault for posting a repo... guess I was bored enough, why use prebuilt stuff when you can build it yourself. At some point in space and time it might become useful, or maybe I'm just a master of waste of time. At least I don't have to wait for x timeouts on klei download page until it starts working

Oh, I understand. I do prefer compiling things myself, just... just not on Windows. Maybe I just don't have much experience with it, but I find compilation of software under Windows to be way too messy and clumsy.

---

Ahhh, I see. Again.... Damnit, Dyslexia. I feel dummer than a foam dummy that fell down the stairs into a pit of flaming cacti.

Let me know if you have further issues.

[DeathDisciple]

I'm having an issue with certain files ending up with spriter objects that start from the middle of the timeline, that is, do not exist at key 0 of main timeline. I was trying to crack what's with the generating_cave 'eating' some pieces of atlas for no reason, if you want to see exact thing I'm talking about.

 

Part of it is spriter issue really, cause if you introduce an object at key different than 0, when you save that file in spriter it will not generate the 'initialization' line (that seems to be needed by modtools to have the start position of the object, if you look at key=0 it's the only key in mainline that has absolute pivots and stuff).

 

I suck at explaining so I'll try copy pasting the exact thing that happens. A wall enters scene at key 18 as this

<object_ref id="0" name="wall" abs_x="0" abs_y="0" abs_pivot_x="0.545248" abs_pivot_y="0.578216" abs_angle="0" abs_scale_x="1" abs_scale_y="1" abs_a="1" timeline="2" key="0" z_index="0" />

but if i open and save file in spriter it turns into

<object_ref id="0" timeline="2" key="0" z_index="0"/>

which still works fine in spriter but makes such object spawn in the middle of the screen instead ingame.

 

Second thing is, even if I do have such object only from middle of timeline, it seems it still shows from key0 ingame anyway, as animation.xml shows frame idx=0

<element name="wall" layername="timeline_2" frame="0" z_index="32" m_a="1.000020" m_b="0.000000" m_c="0.000000" m_d="1.000030" m_tx="186.553009" m_ty="-240.503204"/>

I'm not sure what to suggest, one option would be to do a post pass on decompiler and add a key0 to all objects/timelines that start in the middle of main timeline, with exact same data as the first frame for said objects has now, but with alpha 0 - abs_a="0" on mainline start seems to be good enough for modtools to start the object at the proper time, while still getting the 'start' data, without touching any middle keys, as well as making it 'disappear' where it should (when there are no object-refs to it in mainline). It does make spriter open it as alpha<>0 due to default curve being linear, so might need curve_type="instant" on object's timeline start to prevent it - can't think of a case like this where that would not be a right  thing to do anyway...

[simplex]

I'm having an issue with certain files ending up with spriter objects that start from the middle of the timeline, that is, do not exist at key 0 of main timeline. I was trying to crack what's with the generating_cave 'eating' some pieces of atlas for no reason, if you want to see exact thing I'm talking about.

 

Part of it is spriter issue really, cause if you introduce an object at key different than 0, when you save that file in spriter it will not generate the 'initialization' line (that seems to be needed by modtools to have the start position of the object, if you look at key=0 it's the only key in mainline that has absolute pivots and stuff).

Actually this "intialization" line doesn't seem to be used by Spriter b5 at all. The information it actually uses is what's in the objects within timeline keys. I believe Spriter only leaves that information on the 0 mainline key to keep backwards compatibility with applications processing Spriter files. But, on the other hand, this is what the modtools use.

 

Second thing is, even if I do have such object only from middle of timeline, it seems it still shows from key0 ingame anyway, as animation.xml shows frame idx=0

<element name="wall" layername="timeline_2" frame="0" z_index="32" m_a="1.000020" m_b="0.000000" m_c="0.000000" m_d="1.000030" m_tx="186.553009" m_ty="-240.503204"/>

While I hadn't seen that first hand, I was pretty sure this issue would indeed happen. The scml compiler in the mod tools does assume all objects appear from key 0, and I didn't see any way to fix it which didn't involve substantial rewriting of the mod tools. Sigh, I'll see what I can do, even though I really dislike working on the scml compiler of the mod tools; there's no structured data, it just passes along a huge amount of flat arrays, with some arrays taking values indicating the starting index to check another array from, other arrays taking values indicating the "length" of value ranges in other arrays corresponding to the object with an id used as the index in this first array... it's a huge mess, which I try to stay clear from whenever I can (at this point, I'd rather rewrite the scml compiler in the mod tools from scratch).

 

I'm not sure what to suggest, one option would be to do a post pass on decompiler and add a key0 to all objects/timelines that start in the middle of main timeline, with exact same data as the first frame for said objects has now, but with alpha 0 - abs_a="0" on mainline start seems to be good enough for modtools to start the object at the proper time, while still getting the 'start' data, without touching any middle keys, as well as making it 'disappear' where it should (when there are no object-refs to it in mainline). It does make spriter open it as alpha<>0 due to default curve being linear, so might need curve_type="instant" on object's timeline start to prevent it - can't think of a case like this where that would not be a right  thing to do anyway...

Does the abs_a work for you? Because, unless there's some cross-platform inconsistency in Spriter, as I mentioned all "abs_" values in object references are simply ignored, and this includes abs_a. Setting a reference to have abs_a="0" has no effect on my end: it remains fully opaque in Spriter. The modtools do look at this value, though, discarding frame elements with abs_a less than 0.5, so a dummy frame one millisecond before the actual frame with abs_a equal 0 should work, though this would be a very hackish solution which I'd rather avoid (but compared to the prospect of dealing with the modtools code I just might do it ).

[DeathDisciple]

Actually this "intialization" line doesn't seem to be used by Spriter b5 at all. The information it actually uses is what's in the objects within timeline keys. I believe Spriter only leaves that information on the 0 mainline key to keep backwards compatibility with applications processing Spriter files. But, on the other hand, this is what the modtools use.

 

While I hadn't seen that first hand, I was pretty sure this issue would indeed happen. The scml compiler in the mod tools does assume all objects appear from key 0, and I didn't see any way to fix it which didn't involve substantial rewriting of the mod tools. Sigh, I'll see what I can do, even though I really dislike working on the scml compiler of the mod tools; there's no structured data, it just passes along a huge amount of flat arrays, with some arrays taking values indicating the starting index to check another array from, other arrays taking values indicating the "length" of value ranges in other arrays corresponding to the object with an id used as the index in this first array... it's a huge mess, which I try to stay clear from whenever I can (at this point, I'd rather rewrite the scml compiler in the mod tools from scratch).

 

I know exactly what you're talking about, I... I will constrain myself from commenting, the people that had displeasure to work with me can confirm how many times I screamed that exact conclusion...

 

 

Does the abs_a work for you? Because, unless there's some cross-platform inconsistency in Spriter, as I mentioned all "abs_" values in object references are simply ignored, and this includes abs_a. Setting a reference to have abs_a="0" has no effect on my end: it remains fully opaque in Spriter. The modtools do look at this value, though, discarding frame elements with abs_a less than 0.5, so a dummy frame one millisecond before the actual frame with abs_a equal 0 should work, though this would be a very hackish solution which I'd rather avoid (but compared to the prospect of dealing with the modtools code I just might do it ).

 

Hmm I guess that might be the reason why it didnt set alpha to 0 on key0 proper, but I was sure it was something like 15% on one of the objects... I guess I misinterpreted its behavior.

 

As I mentioned above, putting dummy anywhere except at mainline <key id="0"> will make spriter just remove the initialization from object-ref, altogether with abs_a=0, and modtools need it at key id="0" anyway. Adding a dummy at object's timeline and referencing that dummy at 0 frame, which would be pretty much what I ended up doing, but putting it at -1ms from actual start.... would that confuse spriter or make it remove said key from mainline due to it not having time=0?

 

A bit of a pain to manually add something into13k lines file when the stupid thing requires all indices to be in perfect order...

[simplex]

As I mentioned above, putting dummy anywhere except at mainline <key id="0"> will make spriter just remove the initialization from object-ref, altogether with abs_a=0, and modtools need it at key id="0" anyway. Adding a dummy at object's timeline and referencing that dummy at 0 frame, which would be pretty much what I ended up doing, but putting it at -1ms from actual start.... would that confuse spriter or make it remove said key from mainline due to it not having time=0?

I don't know if it'd confuse Spriter, I'll have to try it. But still, I'll see if I can fix it in the mod tools end, since a valid Spriter file should be able to be converted without resorting to workarounds.

Hopefully I'll also be able to make it fetch the transformation data from the right place. That's a bit tricker because the modtools are using a library (SCMLpp) to parse the scml file, and that's the library's behaviour (which is outdated, not just on this but also on spin handling, for example).

And by the way, do you know C++?

[DeathDisciple]

I don't know if it'd confuse Spriter, I'll have to try it. But still, I'll see if I can fix it in the mod tools end, since a valid Spriter file should be able to be converted without resorting to workarounds.

Hopefully I'll also be able to make it fetch the transformation data from the right place. That's a bit tricker because the modtools are using a library (SCMLpp) to parse the scml file, and that's the library's behaviour (which is outdated, not just on this but also on spin handling, for example).

And by the way, do you know C++?

 

Hmm https://code.google.com/p/scml-pp/source/list guess there goes my question if it has updated version huh.

 

And yeah I know c++, it would take me some time to get out of Java-lazy-mode I guess tho, it's been a while.

[simplex]

@DeathDisciple

Was generating_cave decompiling correctly for you at all? I tried it and I was getting botched images like this:

I did find out what the issue was and fixed locally, but I wonder how on earth you didn't get this as well (it was caused by not resetting a clipping mask prior to flipping and rescaling an image).

[DeathDisciple]

Hah when did I say it didn't? When I saw it tho I ran --check-animation-fidelity and got a bunch of complaints there, so I suspected that's the cause - being that original atlas was being used in a weird way, sometimes cutting in for no obvious reason, it didnt surprise me -and didn't exactly care about the image stuff cause I was about to change it anyway. And after replacing with files I wanted ran into more serious issues so I just ignored/forgot about that whole thing.

 

But, it was decompiling properly, since it ran in spriter after image fixup just as expected.

[simplex]

Hah when did I say it didn't? When I saw it tho I ran --check-animation-fidelity and got a bunch of complaints there, so I suspected that's the cause - being that original atlas was being used in a weird way, sometimes cutting in for no obvious reason, it didnt surprise me -and didn't exactly care about the image stuff cause I was about to change it anyway. And after replacing with files I wanted ran into more serious issues so I just ignored/forgot about that whole thing.

 

But, it was decompiling properly, since it ran in spriter after image fixup just as expected.

--check-animation-fidelity will check for geometrical distortions (try decompiling and deerclops build/anims and look at its arms to see what I'm talking about ). This was an unrelated bug (which I'm glad this discussion helped me spot).

---

 

I don't think I fully understand krane's usefulness. Then again, I'm not familiar with spriter projects. It looks like krane only decompiles so is it for importing Don't Starve's sprite assets into other games that utilize spriter projects?

I'm pretty sure Klei wouldn't be OK with their animations being used in other games .

krane's usefulness is to allow editing existing animations, and to give more freedom in atlas editing (since under direct editing you can't go much beyond the borders of what's already drawn, otherwise it'll get clipped). The resulting Spriter project can then be modified (or left untouched, with only the images being modified) and compiled back into the game's format using the mod tools (which I ported to Linux and Mac ages ago).

 

I like the prospects of --mark-atlases but it still needs an atlas-0.tex file, even though the readme says, "When this option is given, only a build file should be given as input".

When I run:

$ krane --mark-atlases ./build.bin ./

I get:

ERROR: the path `./atlas-0.tex' does not exist.

Is this a bug or is the build file only part of the atlas? On the same topic, can krane be used in some way to edit the atlas? Using already existing, uneditable atlases is very restricting so krane seems promising in this way.

To mark an atlas it needs both the build and the atlas. The atlas holds, well, the actual image, while the build specifies the regions from it which are used. So the build determines the shading, while the atlas determines the image which will be shaded.

When shading atlases, krane just takes the build file as direct input (i.e., as a command line parameter) because the build file specifies the atlases it uses (it's usually just one atlas, named atlas-0.tex, but a build can have any number of atlases, each with an arbitrary name). krane determines which atlases to load by inspecting the build.bin file, and it assumes these atlases are in the same directory as build.bin (which wasn't the case in the example you posted).

 

I also like that I can rename the builds without using wine but it says it needs the anim.bin file. What happens if there is no related anim.bin file? I also can't rename the build without a tex/png file, which is a minor annoyance but is the tex/png file necessary for renaming builds?

That's because it currently only outputs a Spriter project (and not a renamed build.bin), and for that it needs a build, its atlases and at least one animation. I haven't implemented binary output yet (and it's not a priority, since it's a lot of typing for little gain). If all you want is a cross-platform build renamer, I wrote a Perl script doing exactly that (click on "Raw", save the page and make it executable).

 

I hope this doesn't come across as hyper critical. Your work is always greatly appreciated and I can't wait to see how far this tool can go. I'm just having trouble grasping it's current purpose.

No problem, you didn't sound hypercritical .

[mouse]

Sorry about posting on the download page. I forgot klei's website automatically makes related forums. It's been a while since I posted any of my new mods here(ugh, more work I have to do later).

 

I'm pretty sure Klei wouldn't be OK with their animations being used in other games .

lol Yeah I didn't think so either. Klei seems like a pretty cool company for being so mod friendly with DS and all that but I didn't know if they were that cool about it.

 

The resulting Spriter project can then be modified (or left untouched, with only the images being modified) and compiled back into the game's format using the mod tools (which I ported to Linux and Mac ages ago).

I think that's the part I'm not understanding. Spriter generates the build.bin/anim.bin files? Or do they come from some where else? Unless I've been using ktech wrong, I don't think it can generate them. I'm into whatever can edit the build file's atlas regions but it seems like I'm missing a piece of the puzzle here.

 

If all you want is a cross-platform build renamer, I wrote a Perl script doing exactly that (click on "Raw", save the page and make it executable).

That sounds great. I'll have to give that a try. Especially since I just found out that build files edited with matt's build renamer(version 1.0(yeah I'm sure there are new versions but when something works, you tend to stick with it)) under wine create segmentation fault errors in krane.

 

No problem, you didn't sound hypercritical .

Good, I have a tendency to be blunt and other people have a tendency to get mad when I'm blunt. Emotions are for the weak!

[simplex]

Sorry about posting on the download page. I forgot klei's website automatically makes related forums. It's been a while since I posted any of my new mods here(ugh, more work I have to do later).

Actually... it doesn't . Back in the day, there was a subforum for mod releases and we released mods by creating a thread for it (I prefer the new Downloads system in most things, but the old system was much better for getting feedback and simply discussing the mod). I created this thread to announce the project's release and to concentrate its discussion.

 

I think that's the part I'm not understanding. Spriter generates the build.bin/anim.bin files? Or do they come from some where else? Unless I've been using ktech wrong, I don't think it can generate them. I'm into whatever can edit the build file's atlas regions but it seems like I'm missing a piece of the puzzle here.

You'd use the mod tools. Specifically, there's a scml compiler in the mod tools (called "scml") which turns a Spriter project into an animation zip (with a build.bin, an anim.bin and the atlases in TEX format). The Linux and Mac versions use ktech for TEX compression, but that's all it does here.

 

That sounds great. I'll have to give that a try. Especially since I just found out that build files edited with matt's build renamer(version 1.0(yeah I'm sure there are new versions but when something works, you tend to stick with it)) under wine create segmentation fault errors in krane.

Matt's build renamer strips the hash table at the end of the build.bin file, for some ungodly reason. The game can use the build.bin without it, but krane can't possibly turn it into a Spriter project in that case (I'd have to invert a hash function for that). But krane was supposed to throw an exception if the hash table was missing, not segfault (I wrote it with this in mind, since I've known about this for a long time); thanks for letting me know.

[mouse]

Actually... it doesn't . Back in the day, there was a subforum for mod releases and we released mods by creating a thread for it (I prefer the new Downloads system in most things, but the old system was much better for getting feedback and simply discussing the mod). I created this thread to announce the project's release and to concentrate its discussion.

Hmm well there was a time when it did. For my first upload, I made the mistake of starting a thread first only to find another thread was started when the download page was created. Honestly, it seems redundant to me but to each their own.

 

You'd use the mod tools. Specifically, there's a scml compiler in the mod tools (called "scml") which turns a Spriter project into an animation zip (with a build.bin, an anim.bin and the atlases in TEX format). The Linux and Mac versions use ktech for TEX compression, but that's all it does here.

Ah ha! There's the missing puzzle piece. Is scml supposed to compile during the configure and make process? I don't see any executable for it(although I see the source files) and the readme only makes one mention of it. And that's as part of a flag for krane, which as you said is just a decompiler.

 

Matt's build renamer strips the hash table at the end of the build.bin file, for some ungodly reason. The game can use the build.bin without it, but krane can't possibly turn it into a Spriter project in that case (I'd have to invert a hash function for that). But krane was supposed to throw an exception if the hash table was missing, not segfault (I wrote it with this in mind, since I've known about this for a long time); thanks for letting me know.

I could be wrong. I know I saw it somewhere during my tinkering but I also saw something about the hash table too. Everything I tried resulted in either a hash table, seg fault, or missing anim/build/atlas error. But I was trying it with stuff either found in, or derived from data/anim, like wilson and fire and modded stuff. So I could have been using it wrong.

[simplex]

Hmm well there was a time when it did. For my first upload, I made the mistake of starting a thread first only to find another thread was started when the download page was created. Honestly, it seems redundant to me but to each their own.

Oh, right. I forgot there was a separate interface for uploading the mods, and then the threads (which we'd then cross-reference with links).

Ah ha! There's the missing puzzle piece. Is scml supposed to compile during the configure and make process? I don't see any executable for it(although I see the source files) and the readme only makes one mention of it. And that's as part of a flag for krane, which as you said is just a decompiler.

The scml compiler is not a part of the ktools. It's a part of the mod tools, here. I find the scml compiler a bit messy to use, because it was written to be called by the autocompiler, but well... it works.