[Code] A Thread On Lambdas And Other Epsilons

[simplex]

@simplex

 

Moved from candyland.

 

So running premake4 gmake produces this:

Target OS not specified. Assuming it's the host OS.which "unzip" &>/dev/nullmkdir -p "../build"/usr/bin/unzipmkdir -p "../build/dont_starve/mods"unzip -q -o "../pkg/tst/wand.zip" -d "../build/dont_starve/mods"mkdir -p "../build/linux/mod_tools"cp -rT "../pkg/cmn/mod_tools" "../build/linux/mod_tools"mkdir -p "../build/linux/mod_tools/buildtools/linux/Python27"cp -rT "../pkg/unix/Python27" "../build/linux/mod_tools/buildtools/linux/Python27"mkdir -p "../build/linux/mod_tools"cp -rT "../pkg/unix/mod_tools" "../build/linux/mod_tools"Building configurations...Running action 'gmake'...Generating ../build/proj/Makefile...Generating ../build/proj/scml.make...Generating ../build/proj/png.make...Generating ../build/proj/autocompiler.make...Generating ../build/proj/modtoollib.make...Done.

The difference now is there is a "proj" folder in the build folder, which has some make files in it.

 

There's still no "scml" or "png" scripts in my build/linux/mod_tools directory.

 

Actually, I got it. I went into the proj folder and ran make and it seemed to do the trick.

Yes, premake only generates build files, it doesn't build anything itself (it's like the "configure" step in compilation, except that premake has close to 0 configuration capabilities). This has always been how the mod tools were compiled (not by my choice, this is a Klei heritage), how were you compiling them before?

And anyway, did "make exported" do the trick for you now?

[debugman18]

Yes, premake only generates build files, it doesn't build anything itself (it's like the "configure" step in compilation, except that premake has close to 0 configuration capabilities). This has always been how the mod tools were compiled (not by my choice, this is a Klei heritage), how were you compiling them before?

And anyway, did "make exported" do the trick for you now?

 

I'm not sure, I might have gone through a similar process before.

 

And nope, for some reason make is acting strange for me (which is weird, because it worked for images previously, I'm no sure if it does still, but images aren't the concern right now). A did a "make --warn-undefined-variables" to see if there was something going on, and I got this output.

debaggu@debaggu:~/UpAndAway$ make --warn-undefined-variablesmake -C anim allmake[1]: Entering directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/anim'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'Makefile:45: warning: undefined variable `ADD_ANIM_DEPENDENCY'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/anim'make -C images allmake[1]: Entering directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/images'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/images'make -C levels allmake[1]: Entering directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/levels'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/levels'make -C exported allmake[1]: Entering directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/exported'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'Makefile:59: warning: undefined variable `ADD_BUILD_RULE'make[1]: Nothing to be done for `all'.make[1]: Leaving directory `/home/debaggu/.steam/steam/SteamApps/common/dont_starve/mods/UpAndAway/exported'

[simplex]

I'm not sure, I might have gone through a similar process before.

 

And nope, for some reason make is acting strange for me (which is weird, because it worked for images previously, I'm no sure if it does still, but images aren't the concern right now). A did a "make --warn-undefined-variables" to see if there was something going on, and I got this output.

Sure, this output is expected. As I mentioned before, you're giving make the "-C" flag, and it won't work like that. You're not supposed to use the Makefiles in anim/, images/, etc. You're supposed to use the Makefile in the base mod folder. I set up targets for each folder. You should be typing

$ make anim

or

$ make images

or

$ make levels

or

$ make exported

without the -C flag.

Alternatively, you could simply type

$ make

and it will build whatever needs building in each directory.

The nested Makefiles are called recursively by the base one. Using them directly is like calling a function without passing the necessary parameters.

[debugman18]

Sure, this output is expected. As I mentioned before, you're giving make the "-C" flag, and it won't work like that. You're not supposed to use the Makefiles in anim/, images/, etc. You're supposed to use the Makefile in the base mod folder. I set up targets for each folder. You should be typing

$ make anim

or

$ make images

or

$ make levels

or

$ make exported

without the -C flag.

Alternatively, you could simply type

$ make

and it will build whatever needs building in each directory.

The nested Makefiles are called recursively by the base one. Using them directly is like calling a function without passing the necessary parameters.

 

 

Actually, no, I'm not using the -C flag at all. The only reason I used it at all is because I saw it being used in output and wanted to see if using it directly would give an error. You can even see my command typed as so above:

debaggu@debaggu:~/UpAndAway$ make --warn-undefined-variables

I'm not sure why make itself insists on using it in this case, though.

[simplex]

Actually, no, I'm not using the -C flag at all. The only reason I used it at all is because I saw it being used in output and wanted to see if using it directly would give an error. You can even see my command typed as so above:

debaggu@debaggu:~/UpAndAway$ make --warn-undefined-variables

Oh, sorry, I should've paid more attention to it.

 

I'm not sure why make itself insists on using it in this case, though.

Make itself should use it, the "make -C" just shouldn't be called directly.

But the undefined errors are quite strange. Could you post the output of "make --version"? And could you post your config.mk?

[simplex]

krane progress!

I present you the sliced up science machine:

researchlab.zip

Each subfolder is an animation symbol. For each subfolder, each image is the part of the atlas corresponding to an animation symbol frame*. The whole triangulation thing is taken care of, so images won't "bleed out" into others when they don't each neatly fit into rectangles .

Now all that's left is the actual creation of the scml file.

* An animation symbol frame is simply one of its "forms", with an associated duration in case a progression of them is shown. This is not the same as an animation frame (being roughly equivalent to a Spriter object). In the science machine case the only animation symbol with more than one frame is machine_FX.

EDIT: Heh. I made a whole remark about animation symbol frames not being the same as animation frames but yet I had written "animation frame" instead of "animation symbol frame".

[debugman18]

krane progress!

I present you the sliced up science machine:

researchlab.zip

Each subfolder is an animation symbol. For each subfolder, each image is the part of the atlas corresponding to an animation symbol frame*. The whole triangulation thing is taken care of, so images won't "bleed out" into others when they don't each neatly fit into rectangles .

Now all that's left is the actual creation of the scml file.

* An animation symbol frame is simply one of its "forms", with an associated duration in case a progression of them is shown. This is not the same as an animation frame (being roughly equivalent to a Spriter object). In the science machine case the only animation symbol with more than one frame is machine_FX.

EDIT: Heh. I made a whole remark about animation symbol frames not being the same as animation frames but yet I had written "animation frame" instead of "animation symbol frame".

 

Nice! It's interesting to see the parts that make these things up. Looks like krane is trucking along.

 

As for the issue with make, running make --version produces this output:

GNU Make 3.81Copyright (C) 2006  Free Software Foundation, Inc.This is free software; see the source for copying conditions.There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR APARTICULAR PURPOSE.This program built for x86_64-pc-linux-gnu

And my config.mk was discussed already, you had told me to remove the dollar sign.

 

[simplex]

And my config.mk was discussed already, you had told me to remove the dollar sign.

I know it was discussed already, but could you post its current contents? It's the only variable part in the system.

And could you try running this Makefile (save it as a file named "Makefile" in any directory, cd to that directory and run "make"):

define SOME_VAR =SOME VALUEendef.PHONY: dummydummy:	echo "$(SOME_VAR)"

[debugman18]

I know it was discussed already, but could you post its current contents? It's the only variable part in the system.

And could you try running this Makefile (save it as a file named "Makefile" in any directory, cd to that directory and run "make"):

define SOME_VAR =SOME VALUEendef.PHONY: dummydummy:	echo "$(SOME_VAR)"

 

Sure. Here's the output of the Makefile:

echo ""

That's including the second blank line.

 

Edit: And if I do --warn-undefined-variables it tells me:

Makefile:8: warning: undefined variable `SOME_VAR'

My config.mk looks like this:

export SCML_COMPILER=/home/debaggu/ds_mod_tools/build/linux/mod_tools/scm

Maybe I need to reinstall make? (Although that seems silly...)

[simplex]

Sure. Here's the output of the Makefile:

echo ""

That's including the second blank line.

 

Edit: And if I do --warn-undefined-variables it tells me:

Makefile:8: warning: undefined variable `SOME_VAR'

My config.mk looks like this:

export SCML_COMPILER=/home/debaggu/ds_mod_tools/build/linux/mod_tools/scm

Maybe I need to reinstall make? (Although that seems silly...)

The expected output was

echo "SOME VALUE"SOME VALUE

It seems your Make version doesn't support multi-line variable definitions. That... would make it hard to implement some of the features I'm using. Splitting things into multiple lines isn't just a matter of readability, since Make processing is line-oriented. Damn you Debian . That's what I meant by not liking Debian, it uses too outdated (but very thoroughly tested) software. It's great for servers, and other things that require utmost stability, but I wouldn't use it in my home PC, since I find it too frustrating to lag behind in software updates.

See if this tweaked version of the above Makefile works. Apparently this is an older syntax for defining multiline variables (though it still works under newer versions; my version is 4.0, by the way).

define SOME_VARSOME VALUEendef.PHONY: dummydummy:	echo "$(SOME_VAR)"

(the only change was removing the equality sign after the "define SOME_VAR")

[debugman18]

The expected output was

echo "SOME VALUE"SOME VALUE

It seems your Make version doesn't support multi-line variable definitions. That... would make it hard to implement some of the features I'm using. Splitting things into multiple lines isn't just a matter of readability, since Make processing is line-oriented. Damn you Debian . That's what I meant by not liking Debian, it uses too outdated (but very thoroughly tested) software. It's great for servers, and other things that require utmost stability, but I wouldn't use it in my home PC, since I find it too frustrating to lag behind in software updates.

See if this tweaked version of the above Makefile works. Apparently this is an older syntax for defining multiline variables (though it still works under newer versions; my version is 4.0, by the way).

define SOME_VARSOME VALUEendef.PHONY: dummydummy:	echo "$(SOME_VAR)"

(the only change was removing the equality sign after the "define SOME_VAR")

 

 

That did the trick.

 

And I didn't know debian would have these kinds of issues. Although, I'm liking debian quite a lot. Having to compile things and stuff like that have got me really getting used to terminal. I launched Windows the other day to see how different it feeled, and the results were not pretty. I honestly can't stand it now.

[simplex]

That did the trick.

Great, I'm glad I can fix it byjust removing one character instead of having to rethink whole chunks system .

I'll push the fix in a minute or two.

And I didn't know debian would have these kinds of issues. Although, I'm liking debian quite a lot. Having to compile things and stuff like that have got me really getting used to terminal. I launched Windows the other day to see how different it felted, and the results were not pretty. I honestly can't stand it now.

It's not an issue in an absolute sense, but a way to handle the system software. With Debian it is very difficult for a system update to break anything, and you don't need to spend much time (if at all) in system maintenance. But of course, users are always a few versions behind in the software they use, unless they compile the newer versions themselves. On the other extreme, there are rolling release distros like Arch Linux and Gentoo, which don't even have versions, being just that mutable thing constantly getting updated (with software reaching the users usually within a day of their official release). But of course, there's a much greater chance of an update breaking things, since with such a short release cycle incompatibility among packages may very well go unnoticed. I certainly wouldn't recommend a rolling release distro as a first one, since it takes some experience with Linux to solve the issues which may pop up.

And I feel the same way about using Windows. Unless I'm simply double-clicking a game shortcut, I can only use Windows by firing up Cygwin .

[simplex]

Well, this is... something. I think. Perhaps.

But I'm aware objects are being duplicated (just on the left pane you can see three machine_leg's). This is not a bug, I just haven't implemented the deduplication yet.

[simplex]

There, much better:

Now the build is being properly exported. Animations themselves are still not (only the initial frame of each animation is properly shown), but I know what the issue is. And there's still the deduplication to take care of. But otherwise it's essentially done.

(and pretty fast, it's taking me 0.35 seconds to load and export the science machine build/anims and the symbol frame images, most of which is spent decompressing the tex atlas)

[debugman18]

There, much better:

Now the build is being properly exported. Animations themselves are still not (only the initial frame of each animation is properly shown), but I know what the issue is. And there's still the deduplication to take care of. But otherwise it's essentially done.

(and pretty fast, it's taking me 0.35 seconds to load and export the science machine build/anims and the symbol frame images, most of which is spent decompressing the tex atlas)

 

So at the risk of not understanding the answer, I'm curious as to why the duplication happens when exporting.

[simplex]

So at the risk of not understanding the answer, I'm curious as to why the duplication happens when exporting.

The short answer is: because animation symbol frames are not the same as animation frames. They're in fact orthogonal concepts. An animation frame belongs to a animation, and is the unit of the animation's time progression, and consists of the collection of which animation symbol frames should be shown. An animation symbol frame, on the other hand, belongs to the build, and consists of a starting time, a duration, an image and a specification of what geometrical transformations to apply to this image (translation, rotation and scaling). An animation symbol frame have a duration of at least one animation frame, but it may be more than that. And that's what's causing the duplication: currently, if an animation symbol frame lasts more than one animation frame, instead of reusing it I'm creating one copy of it for each animation frame (each copy having its duration set to one animation frame).

Handling correctly the relationship between animation frames and animation symbol frames is all that's left to do. It's the cause of both the duplication and of the animations not being properly played.

[simplex]

@debugman18

The animation conversion is essentially done. Animations play correctly in Spriter and all that:

researchlab.zip

But unfortunately (and believe me when I say I tried all I could think of) I don't believe there's a way to strictly preserve the vanilla animation symbols. That's because the scml converter in the mod tools turns Spriter timetables into animation symbols, but Spriter only allows one object per timetable. So (even though the duplication issue has been solved) things that appear more than once simultaneously must be split into different animation symbols; for example, each leg of the science machine becomes a separate symbol.

And there's still an issue with scaling to take care of. When converting the animations back into the game with the mod tools, the end result gets scaled down, but the translations/pivots do not. So it looks completely off

if you pay attention to it, you'll see everything is where it should if it were not for the downscaling of the parts. They also move like they should if they had their full size. But with the downscaling it's absolutely wrong. I've heard of people having issues with the mod tools screwing up their anims by downscaling, do you have any info on that (especially on what is done to fix it)?

[debugman18]

@debugman18

The animation conversion is essentially done. Animations play correctly in Spriter and all that:

researchlab.zip

But unfortunately (and believe me when I say I tried all I could think of) I don't believe there's a way to strictly preserve the vanilla animation symbols. That's because the scml converter in the mod tools turns Spriter timetables into animation symbols, but Spriter only allows one object per timetable. So (even though the duplication issue has been solved) things that appear more than once simultaneously must be split into different animation symbols; for example, each leg of the science machine becomes a separate symbol.

And there's still an issue with scaling to take care of. When converting the animations back into the game with the mod tools, the end result gets scaled down, but the translations/pivots do not. So it looks completely off

if you pay attention to it, you'll see everything is where it should if it were not for the downscaling of the parts. They also move like they should if they had their full size. But with the downscaling it's absolutely wrong. I've heard of people having issues with the mod tools screwing up their anims by downscaling, do you have any info on that (especially on what is done to fix it)?

 

I just do a 3x setscale on those things. (That's really only with single images, I'm not sure how it effects entire animations.) I'm really not sure why it does it, I think somebody mentioned it still happened even if they increased the image sizes themselves.

[simplex]

I just do a 3x setscale on those things. (That's really only with single images, I'm not sure how it effects entire animations.) I'm really not sure why it does it, I think somebody mentioned it still happened even if they increased the image sizes themselves.

So... no clues on when and why this issue happens? :/

[debugman18]

So... no clues on when and why this issue happens? :/

 

I can do some experimenting later, and see what I can come up with.

[simplex]

I can do some experimenting later, and see what I can come up with.

Oh, don't worry, I'm sure U&A would benefit from your time. It shouldn't be too hard to figure out how to go about it from the code (certainly much easier than by trial and error), I was just hoping this was already well known.

[simplex]

@debugman18

@squeek

@TheDanaAddams

The core functionality of krane (the build.bin/anim.bin to scml converter) is done, except for the scml exporter in the mod tools screwing up the pivots (this might be related to "calculate proper pivots" being in Cheerio's TODO.md list for the mod tools ). Everything works correctly in Spriter, but when converting back to the game anything involving a rotation gets screwed up due to the wrong pivots (I fixed the scaling issue, though). If you know of other people having this kind of issue when exporting their Spriter animations to DS (and preferably what they do to tackle it) that'd be greatly appreciated.

This is the converted Science Machine:

researchlab.zip

[simplex]

God damn it... I spent hours trying to figure out why the tallbird egg conversion wasn't working (it used the wrong sprite for each anim). I hacked and slashed through the krane code, the scml compiler in the mod tools, the Python scripts in the mod tools, and nothing explained it.

Then I finally realised it was because U&A was enabled . We're reincluding the tallbird egg bank in golden_egg.zip, and the animations in it are incompatible* with a reconverted tallbird egg (which needs to use its own reconverted anims).

* The issue is that in DS builds, a build frame can have a duration of more than one animation frame. But since Spriter doesn't have such a concept, so the scml compiler in the mod tools sets all build frame durations to 1. This causes incompatibility with the old anims, since they'll pick the wrong frame. In this case, the tallbird egg has one build frame of length 2, and the contraction of this length to 1 was causing the anims in the golden egg's anim.bin to pick the "next" sprite instead of the correct one. But I'll see if I can manage to find a way to preserve compatibility, after I manage to fix the pivot issue (the tallbird egg was meant as a test subject for that, but I ended up having to put all my time into figuring out this unrelated issue).

[debugman18]

God damn it... I spent hours trying to figure out why the tallbird egg conversion wasn't working (it used the wrong sprite for each anim). I hacked and slashed through the krane code, the scml compiler in the mod tools, the Python scripts in the mod tools, and nothing explained it.

Then I finally realised it was because U&A was enabled . We're reincluding the tallbird egg bank in golden_egg.zip, and the animations in it are incompatible* with a reconverted tallbird egg (which needs to use its own reconverted anims).

* The issue is that in DS builds, a build frame can have a duration of more than one animation frame. But since Spriter doesn't have such a concept, so the scml compiler in the mod tools sets all build frame durations to 1. This causes incompatibility with the old anims, since they'll pick the wrong frame. In this case, the tallbird egg has one build frame of length 2, and the contraction of this length to 1 was causing the anims in the golden egg's anim.bin to pick the "next" sprite instead of the correct one. But I'll see if I can manage to find a way to preserve compatibility.

 

Oof.

 

I can't see compatibility being a necessity (since it's most often going to be used for creating new animations from existing ones, or for adding onto and replacing vanilla ones) but I guess when you factor in various mods it could cause problems.

 

Sounds like krane is going well though. Did you ever nail down that pivot bug?

[simplex]

Oof.

 

I can't see compatibility being a necessity (since it's most often going to be used for creating new animations from existing ones, or for adding onto and replacing vanilla ones) but I guess when you factor in various mods it could cause problems.

Compatibility with vanilla anims would be handy, to avoid requiring reconversion of all animations in the chosen bank. But not a fundamental thing. And it shouldn't affect mod intercompatibility (in fact, requiring a renamed bank would prevent that).

 

Sounds like krane is going well though. Did you ever nail down that pivot bug?

Nope, see my edit. The tallbird's egg original purpose was precisely helping with that, since it's simpler and has a subtler motion. Though the reconverted tallbird egg had a knack for doing backflips frantically instead of slowly swinging from side to side .

Did no one have pivot issues when converting from Spriter to DS? It hasn't been easy trying to figure out how the animations can work correctly in Spriter but fail on reconversion.