[Code] A Thread On Lambdas And Other Epsilons

[simplex]

@debugman18

 

OOOOOH, I think I know what the issue is, and it's not about pivots at all. The scml compiler in the mod tools is not doing tweening correctly for angles. When calculating "intemediate states", it's always interpolating along the same direction.

I made the tallbird egg anims 20 times slower to get a clear picture of what was going on, and played the "idle_cold" anim in the reconverted anims. The egg literally did 360 degree flips instead of swinging from one direction to the other. This is because the scml compiler is interpolating angles along the large arc, not the small one .

EDIT: Actually, this is not a bug in the scml compiler. There's a spriter parameter controlling the direction of the interpolation, which I'm not properly setting. I wonder how the animations worked in Spriter, though...

[debugman18]

@debugman18

 

OOOOOH, I think I know what the issue is, and it's not about pivots at all. The scml compiler in the mod tools is not doing tweening correctly for angles. When calculating "intemediate states", it's always interpolating along the same direction.

I made the tallbird egg anims 20 times slower to get a clear picture of what was going on, and played the "idle_cold" anim in the reconverted anims. The egg literally did 360 degree flips instead of swinging from one direction to the other. This is because the scml compiler is interpolating angles along the large arc, not the small one .

EDIT: Actually, this is not a bug in the scml compiler. There's a spriter parameter controlling the direction of the interpolation, which I'm not properly setting. I wonder how the animations worked in Spriter, though...

 

It likely has to do with the way that Don't Starve is actually reading the animations.

[simplex]

@debugman18

@squeek

@TheDanaAddams

I was right (in my last post). The rotation bug (which wasn't about pivots at all) has been fixed, so now the generated Spriter project gets correctly converted back by the scml compiler of the mod tools. The core functionality of krane is done, all that's left is designing the command line interface, making usage more flexible, etc. Though usage will greatly benefit from these additions, it is already useable. Currently it takes two argument: the first is an input directory, with a build.bin, anim.bin and atlas-0.tex; the second is the output directory (which is created if it doesn't exist) where the scml file and and the subfolder with the images are placed. The code is at GitHub (it has been for a while, I just hadn't announced it due to the remaining bugs to tackle).

But I did put in some fixes in the scml compiler of the mod tools. I made it handle the rotation spin properly (it was using the value of the start frame, where it should be using that of the end frame), and I made it handle pivots properly. On that last part, I'm not sure that was the full extent of what Cheerio meant with "calculate pivots properly" in his TODO, but I think it is (I haven't crossed it off the TODO, though). What I fixed on the pivot handling is that they were being incorporated in the animations, where they should be a part of the build; since Cheerio mentioned swappable builds as a reason for fixing the pivots, and they are directly affected by that (unlike most cases, for which this should have no visible effect), I think that's what he meant. The latest version of the mod tools is required for compiling the converted anims back into the game.

I'd post the properly converted science machine if the forum weren't bugging out on me (it's giving me a blank page for "More Reply Options").

EDIT: The forum decided to agree with me, so here it is:

researchlab.zip

[debugman18]

@debugman18

@squeek

@TheDanaAddams

I was right (in my last post). The rotation bug (which wasn't about pivots at all) has been fixed, so now the generated Spriter project gets correctly converted back by the scml compiler of the mod tools. The core functionality of krane is done, all that's left is designing the command line interface, making usage more flexible, etc. Though usage will greatly benefit from these additions, it is already useable. Currently it takes two argument: the first is an input directory, with a build.bin, anim.bin and atlas-0.tex; the second is the output directory (which is created if it doesn't exist) where the scml file and and the subfolder with the images are placed. The code is at GitHub (it has been for a while, I just hadn't announced it due to the remaining bugs to tackle).

I'd post the properly converted science machine if the forum weren't bugging out on me (it's giving me a blank page for "More Reply Options").

 

Sweet! I'll check it out right now. How should I go about compiling?

[simplex]

Sweet! I'll check it out right now. How should I go about compiling?

./configure && make

This will compile both ktech and krane.

[debugman18]

./configure && make

This will compile both ktech and krane.

 

 

Unfortunately it seems I'm running into an error:

 

debaggu@debaggu:~/ktools$ ./configure && make-- The CXX compiler identification is GNU 4.8.2-- Check for working CXX compiler: /usr/bin/c++-- Check for working CXX compiler: /usr/bin/c++ -- works-- Detecting CXX compiler ABI info-- Detecting CXX compiler ABI info - done-- The C compiler identification is GNU 4.8.2-- Check for working C compiler: /usr/bin/cc-- Check for working C compiler: /usr/bin/cc -- works-- Detecting C compiler ABI info-- Detecting C compiler ABI info - done-- Looking for sys/types.h-- Looking for sys/types.h - found-- Looking for stdint.h-- Looking for stdint.h - found-- Looking for stddef.h-- Looking for stddef.h - found-- Check size of int32_t-- Check size of int32_t - done-- Check size of int64_t-- Check size of int64_t - done-- Check size of intmax_t-- Check size of intmax_t - done-- Check size of size_t-- Check size of size_t - done-- Check size of ssize_t-- Check size of ssize_t - done-- Check size of uint16_t-- Check size of uint16_t - done-- Check size of uint32_t-- Check size of uint32_t - done-- Check size of uint64_t-- Check size of uint64_t - done-- Check size of uintmax_t-- Check size of uintmax_t - done-- Check size of intptr_t-- Check size of intptr_t - done-- Check size of uintptr_t-- Check size of uintptr_t - done-- target changed from "" to "auto"-- Detected CPU: penryn-- Sadly the Penryn architecture exists in variants with SSE4.1 and without SSE4.1.-- SSE4.1: disabled (auto-detected from this computer's CPU flags)-- Performing Test check_cxx_compiler_flag__march_penryn-- Performing Test check_cxx_compiler_flag__march_penryn - Failed-- Performing Test check_cxx_compiler_flag__march_core2-- Performing Test check_cxx_compiler_flag__march_core2 - Success-- Performing Test check_cxx_compiler_flag__msse2-- Performing Test check_cxx_compiler_flag__msse2 - Success-- Performing Test check_cxx_compiler_flag__msse3-- Performing Test check_cxx_compiler_flag__msse3 - Success-- Looking for pmmintrin.h-- Looking for pmmintrin.h - found-- Performing Test check_cxx_compiler_flag__mssse3-- Performing Test check_cxx_compiler_flag__mssse3 - Success-- Looking for tmmintrin.h-- Looking for tmmintrin.h - found-- Performing Test check_cxx_compiler_flag__mno_sse4_1-- Performing Test check_cxx_compiler_flag__mno_sse4_1 - Success-- Performing Test check_cxx_compiler_flag__mno_sse4_2-- Performing Test check_cxx_compiler_flag__mno_sse4_2 - Success-- Performing Test check_cxx_compiler_flag__mno_sse4a-- Performing Test check_cxx_compiler_flag__mno_sse4a - Success-- Performing Test check_cxx_compiler_flag__mno_avx-- Performing Test check_cxx_compiler_flag__mno_avx - Success-- Performing Test check_cxx_compiler_flag__mno_xop-- Performing Test check_cxx_compiler_flag__mno_xop - Success-- Performing Test check_cxx_compiler_flag__mno_fma4-- Performing Test check_cxx_compiler_flag__mno_fma4 - Success-- Performing Test check_cxx_compiler_flag__mno_avx2-- Performing Test check_cxx_compiler_flag__mno_avx2 - SuccessCMake Error at lib/CMakeLists.txt:8 (add_subdirectory):  The source directory    /home/debaggu/ktools/lib/pugixml  does not contain a CMakeLists.txt file.-- Found ImageMagick: /usr/lib/x86_64-linux-gnu/libMagick++.so (found version "6.7.7-10")-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")-- checking for module 'Magick++'--   found Magick++, version 6.7.7-- Looking for floor in m-- Looking for floor in m - found-- Looking for C++ include cstddef-- Looking for C++ include cstddef - found-- Looking for inttypes.h-- Looking for inttypes.h - found-- Looking for C++ include strstream-- Looking for C++ include strstream - found-- Looking for C++ include strstream.h-- Looking for C++ include strstream.h - not found-- Looking for C++ include sstream-- Looking for C++ include sstream - found-- Check size of long long-- Check size of long long - done-- Looking for snprintf-- Looking for snprintf - found-- Check size of mode_t-- Check size of mode_t - done-- Performing Test HAVE_RESTRICT-- Performing Test HAVE_RESTRICT - Failed-- Performing Test HAVE___RESTRICT-- Performing Test HAVE___RESTRICT - Success-- Configuring incomplete, errors occurred!See also "/home/debaggu/ktools/CMakeFiles/CMakeOutput.log". 

 

http://pastebin.com/p1iu72y9

[simplex]

Unfortunately it seems I'm running into an error:

Sorry, I had forgotten to commit a file. It should be good now.

[debugman18]

Sorry, I had forgotten to commit a file. It should be good now.

 

Yup, perfect.

 

I converted the mossling spin animation (and I've successfully used the images to create a new whirlwind animation independent of it) but during the conversion it told me that the idle anim had a duplicate, so it didn't convert all of the way.

 

Error: Duplicate anim 'idle' in bank 'mossling'

[simplex]

Yup, perfect.

 

I converted the mossling spin animation (and I've successfully used the images to create a new whirlwind animation independent of it) but during the conversion it told me that the idle anim had a duplicate, so it didn't convert all of the way.

 

Error: Duplicate anim 'idle' in bank 'mossling'

Thanks for picking up on that. I am handling animations within a bank as a map from their names to the anim (think of a Lua table using anim names as keys), but animations with a direction (up, down, side, etc.) may occur more than once, corresponding to different directions. I pushed a fix, and am now using the animation's "full" name as key (idle_up, idle_down, etc.).

But how did you run into the issue, in the first place? The spin_loop animation is in mossling_actions.zip, where there is no conflict. Currently the way to do te conversion would be to first unzip the mossling_angry_build.zip and then overwrite the anim.bin with the one in mossling_actions.zip. Internally krane does have support for loading anims from several anim.bin files and merging it all in a single Spriter project, but there's no interface for it yet.

EDIT: Oh, sorry, there is one animation with multiple directions in mossling_actions.zip ("atk"). And the fix I had just pushed was wrong (it was overwriting animations with the same direction). I just pushed a proper fix.

[debugman18]

Thanks for picking up on that. I am handling animations within a bank as a map from their names to the anim (think of a Lua table using anim names as keys), but animations with a direction (up, down, side, etc.) may occur more than once, corresponding to different directions. I pushed a fix, and am now using the animation's "full" name as key (idle_up, idle_down, etc.).

But how did you run into the issue, in the first place? The spin_loop animation is in mossling_actions.zip, where there is no conflict. Currently the way to do te conversion would be to first unzip the mossling_angry_build.zip and then overwrite the anim.bin with the one in mossling_actions.zip. Internally krane does have support for loading anims from several anim.bin files and merging it all in a single Spriter project, but there's no interface for it yet.

 

I converted the existing whirlwind animation over, since it uses a vanilla bank (and the build shouldn't matter much, I think?). Would that have mattered?

[simplex]

I converted the existing whirlwind animation over, since it uses a vanilla bank (and the build shouldn't matter much, I think?). Would that have mattered?

See my edit.

And no, the build doesn't matter. But since we were using the mossling_angry_build, it might be useful to take it as a base and then replace its images (removing those we don't need); that's assuming we'll redo the build, of course, because if not we can just take the resulting anim.bin and plug it into whirlwind.zip (changing the bank name in whirlwind.lua to match the new one).

By the way, I converted the mossling_angry_build to scml and then back again with the mod tools, and two atlases were generated with different parts of the image: atlas-0.tex and atlas-1.tex. That's because mossling_angry_build has many images and I'm undoing the 1/3 scaling to the atlas, so it didn't fit into just one (I could keep the 1/3 scaling, though, that's really just a design choice). I'm just mentioning this because krane wouldn't be able to handle a build with more than one atlas, since I have to figure out how the current atlas of each image is specified.

[debugman18]

@simplex

 

I really hate to bother you about it, but the scml converter is acting up. I pulled the changes from git, and did:

premake4 gmake

then went into the proj folder and did:

make

and everything seemed to compiled fine. However, when I use the converter, it screws up the animations. For instance, reconverting the tornado atlas (I figured it would be cleaner than using the mossling ones), it only showed the first frame, but moved it around as if it were all of them. The octocopter, for instance, was slightly buggy on compilation. They have proper bounding boxes, though, except in the case of the wrecked octocopter (it uses the death animation of the octocopter).

 

Here's a screen of the screwy octocopter:

 

[simplex]

@simplex

 

I really hate to bother you about it, but the scml converter is acting up. I pulled the changes from git, and did:

premake4 gmake

then went into the proj folder and did:

make

and everything seemed to compiled fine. However, when I use the converter, it screws up the animations. For instance, reconverting the tornado atlas (I figured it would be cleaner than using the mossling ones), it only showed the first frame, but moved it around as if it were all of them. The octocopter, for instance, was slightly buggy on compilation. They have proper bounding boxes, though, except in the case of the wrecked octocopter (it uses the death animation of the octocopter).

 

Here's a screen of the screwy octocopter:

It looks like the new pivot handling is buggy. I temporarily reverted it until the issue is fixed. Try again with the last commit, the issues should be gone.

And don't hesitate to bother me with this kind of stuff .

[debugman18]

It looks like the new pivot handling is buggy. I temporarily reverted it until the issue is fixed. Try again with the last commit, the issues should be gone.

And don't hesitate to bother me with this kind of stuff .

 

Okay, so I pushed the vanilla friendly whirlwind, but there's still the same issue with it. (The octocopter is normal again, though.)

 

I'm not sure why it's doing that, since in Spriter, it works perfectly fine.

[simplex]

Okay, so I pushed the vanilla friendly whirlwind, but there's still the same issue with it. (The octocopter is normal again, though.)

 

I'm not sure why it's doing that, since in Spriter, it works perfectly fine.

I'll take a look at it. There might be some other issue (like the spin one) to get reconversion to the game working right.

EDIT: Did you push everything in the whirlwind dir? Because Spriter crashes when I try to open the scml complaining about a missing (image) file.

[debugman18]

I'll take a look at it. There might be some other issue (like the spin one) to get reconversion to the game working right.

EDIT: Did you push everything in the whirlwind dir? Because Spriter crashes when I try to open the scml complaining about a missing (image) file.

 

Just uploaded the missing images. Although, they shouldn't be referenced anywhere, because they're not used at all.

[simplex]

Just uploaded the missing images. Although, they shouldn't be referenced anywhere, because they're not used at all.

Spriter is picky. The crash was caused by there being no folder with id 0 in the save file. I fixed it by renaming folder 2 to 1, and 1 to 0. But I did get the same issue when converting them back into the game. The scml compiler in the mod tools is doing something wrong. It's not using the right file references, just picking the file id 0 for every frame. I'll see if I can find out the issue with it, though I hate dealing with that code.

[simplex]

@debugman18

Yup, it was a bug in the mod tools, I just pushed a fix. Sigh, I really hope I won't have to deal with that code again.

The thing is each object* in Spriter is represented by a timeline. A timeline is a succession of keys, where each key stores a starting time and information about which image to use and the transformations applied to it at that instant in time (scaling, rotation and translation). The scml compiler was checking information on a per key basis for the geometrical transformations, but not for which image to use. For that, it was simply taking whatever image the first key used, so it was locked to the first frame. The keys in a timeline usually don't switch images, just varying in their geometrical properties, so we hadn't seen this issue before. But here this was a big issue.

* Though the use of the term "object" might cause confusion when reading a scml file, because the keyword "object" denotes instead the contents of a single key. Spriter terminology is confusing. If you want more detailed info, I believe this is the best reference, even though it's out of date.

[simplex]

@debugman18

By the way, how did you end up with the previous, crashy whirlwind scml? Did you simply remove the folder/files from within the Spriter interface, or did you do something else?

Since this is not the first time removal of files from a project causes issues, I'm wondering if this happens due to misuse or if it is a Spriter bug (possibly specific to version b5).

[debugman18]

@debugman18

By the way, how did you end up with the previous, crashy whirlwind scml? Did you simply remove the folder/files from within the Spriter interface, or did you do something else?

Since this is not the first time removal of files from a project causes issues, I'm wondering if this happens due to misuse or if it is a Spriter bug (possibly specific to version b5).

 

I removed the folders containing unused images while it was open in Spriter, then I saved it like that. It shouldn't have caused issues, but I guess it did. (I read on the Spriter forums that that would work.)

[simplex]

I removed the folders containing unused images while it was open in Spriter, then I saved it like that. It shouldn't have caused issues, but I guess it did. (I read on the Spriter forums that that would work.)

I'm not being able to do this. I tried deleting folders with Spriter open (after removing the animations using them, just in case), and while the folders were removed from Spriter's interface, they remain in the save file. They were removed from your savefile, though, so we're doing something different (since I'm also using version b5).

[debugman18]

I'm not being able to do this. I tried deleting folders with Spriter open (after removing the animations using them, just in case), and while the folders were removed from Spriter's interface, they remain in the save file. They were removed from your savefile, though, so we're doing something different (since I'm also using version b5).

 

Wait, they were removed from the save file? Okay, that was a scml I was testing out that I must've forgotten to revert. The same issue occurred with the other version though.

[simplex]

Wait, they were removed from the save file? Okay, that was a scml I was testing out that I must've forgotten to revert. The same issue occurred with the other version though.

They were, that's why the crash happened. Spriter assumes all ids (in particular folder and file ids) are consecutive numbers starting from 0. But in the savefile you gave me the folder ids started from 1. So the fix was just renaming folder ids (the extra images were not necessary).

But it'd be good to have a proper way to remove folder/files, since otherwise the scml compiler in the mod tools will create a bloated build for no reason (and it probably will fail if there are missing images).

But yes, the locked sprite issue was not related to that. As I mentioned, this was caused by a buggy behaviour in the scml compiler which is now fixed.

[simplex]

@debugman18

I implemented a basic command-line interface in krane. I also implemented support for converting builds with multiple atlases.

Unless you (or someone else reading this) finds a bug in it, a forum release should be in order soon.

[debugman18]

@debugman18

I implemented a basic command-line interface in krane. I also implemented support for converting builds with multiple atlases.

Unless you (or someone else reading this) finds a bug in it, a forum release should be in order soon.

 

Awesome! I may be able to get it running on my mac, but I'm not sure how well that will go.

 

I've been trying to implement a multiple-ingredient recipe and I'm having trouble with it. Could you enlighten me? I've tried passing the ingredient parameter as a table, but that's not working. I looked at brewing.lua, but it doesn't seem to reference having multiple ingredients.