[Archived] Original Mod Collaboration Thread

[simplex]

My primary concern, though, is just making sure the scale is right in-game, so the sooner someone (most likely Debug xP) can bring it in, and take a screenshot, the sooner I can stop being paranoid about that. =)

Hey, that's OS discrimination! (by Klei)

[debugman18]

I come bearing gifts!

 

I've been hard at work, cutting Lifemare's Beanlet art into the necessary pieces, and assembling it all in Spriter.

Well, good news - I've finally finished the... side view.

 

And I really hope the scale is right - it took me forever to find what felt right, and I'm hoping it comes out properly in-game.

 

The interchangeable parts (faces and "hair") have been set up to properly and seamlessly switch, everything is correctly Z-ordered, pivot points have been set for all pieces, and everything has been aligned.

 

I threw in a little dummy animation that I could slap together without bones, just so it would do something.

My primary concern, though, is just making sure the scale is right in-game, so the sooner someone (most likely Debug xP) can bring it in, and take a screenshot, the sooner I can stop being paranoid about that. =)

 

From here, the next step is to set up the bone structure... and then do it all again for the front and back views.

 

Without further ado:

Beanlets.zip

 

Enjoy!

Okay, so there's an issue with animation importing that I feel should be pointed out. All of the images used in the animations should be put into the root folder, with the scml file. Otherwise, the converter seems to ignore the folders and doesn't build a correct atlas. I moved them myself, though. Maybe klei can add support for folders, as well.

 

[Rabbitfist]

Okay, so there's an issue with animation importing that I feel should be pointed out. All of the images used in the animations should be put into the root folder, with the scml file. Otherwise, the converter seems to ignore the folders and doesn't build a correct atlas. I moved them myself, though. Maybe klei can add support for folders, as well.

 

1. i like how the beanlets looks like

 

2.i have no idea wht i should suggest

[lifemare]

I come bearing gifts!

 

I've been hard at work, cutting Lifemare's Beanlet art into the necessary pieces, and assembling it all in Spriter.

Well, good news - I've finally finished the... side view.

 

And I really hope the scale is right - it took me forever to find what felt right, and I'm hoping it comes out properly in-game.

 

The interchangeable parts (faces and "hair") have been set up to properly and seamlessly switch, everything is correctly Z-ordered, pivot points have been set for all pieces, and everything has been aligned.

 

I threw in a little dummy animation that I could slap together without bones, just so it would do something.

My primary concern, though, is just making sure the scale is right in-game, so the sooner someone (most likely Debug xP) can bring it in, and take a screenshot, the sooner I can stop being paranoid about that. =)

 

From here, the next step is to set up the bone structure... and then do it all again for the front and back views.

 

Without further ado:

Beanlets.zip

 

Enjoy!

 

Outstanding!

You mentioned cutting pieces, i thought i'd covered all the necessary layers... Hope the PSD was a good idea instead of PNGs.

 

Okay, so there's an issue with animation importing that I feel should be pointed out. All of the images used in the animations should be put into the root folder, with the scml file. Otherwise, the converter seems to ignore the folders and doesn't build a correct atlas. I moved them myself, though. Maybe klei can add support for folders, as well.

 

 

First observation is that the details i worked into the art don't work at those dimensions...

And there's a lot of pixelation! It might look a little better if i vectorized everything in Illustrator before exporting to PNG, but it kind of defeats the purpose of having vectors when you save it in a bitmap format...

[simplex]

And there's a lot of pixelation! It might look a little better if i vectorized everything in Illustrator before exporting to PNG, but it kind of defeats the purpose of having vectors when you save it in a bitmap format...

I think that's due to the auto resizing of textures. It seems they are using a linear filter.

And oh, @debugman18, what's the file naming/directory convention for "primitive assets" (such as pngs) inside anim/? I wrote a little Unix buildchain (in ~10 lines of code added to the Makefile) to automate the tex creation and zip packaging (by inspecting build.bin for the build name and using that as the zip name), but what I noticed is that there doesn't seem to be a uniform convention in place (and, for the love of god, keep those spaces away from dir/file names, at least for the directly used ones!).

Any chance I might convince you to adopt a Unix environment (such as Cygwin) so we may use buildchains more extensively to automate tasks? This is not really that important, but... oh well, I just don't know how you can stand the lack of programming power tools in a Windows environment.

The nice thing about makefiles is that you're specifying a set of rules, with a target and a set of dependencies. A rule can be anything (it's usually used to build something, in some sense, but the contents are arbitrary), and it is only run if at least one dependency was modified after the target (and dependencies themselves can be targets with their own dependencies and rules, so if A depends on B and B depends on C, when trying to build A first it will try to build B, and then decide whether A should be built based on modification times). So they're really nice for automating things like that.

Edited September 11, 2013 by simplex

[debugman18]

I think that's due to the auto resizing of textures. It seems they are using a linear filter.

And oh, @debugman18, what's the file naming/directory convention for "primitive assets" (such as pngs) inside anim/? I wrote a little Unix buildchain (in ~10 lines of code added to the Makefile) to automate the tex creation and zip packaging (by inspecting build.bin for the build name and using that as the zip name), but what I noticed is that there doesn't seem to be a uniform convention in place (and, for the love of god, keep those spaces away from dir/file names, at least for the directly used ones!).

Any chance I might convince you to adopt a Unix environment (such as Cygwin) so we may use buildchains more extensively to automate tasks? This is not really that important, but... oh well, I just don't know how you can stand the lack of programming power tools in a Windows environment.

The nice thing about makefiles is that you're specifying a set of rules, with a target and a set of dependencies. A rule can be anything (it's usually used to build something, in some sense, but the contents are arbitrary), and it is only run if at least one dependency was modified after the target (and dependencies themselves can be targets with their own dependencies and rules, so if A depends on B and B depends on C, when trying to build A first it will try to build B, and then decide whether A should be built based on modification times). So they're really nice for automating things like that.

About the spaces in the names, those were simply unzipped as is, from the zips/rars that collaborators have uploaded. I'll try not to use spaces in file and folder names, in the future, though. As for naming conventions, they're really just named whatever the artist/animator named them. Really, the folders inside of /anim aren't being used by me, except to keep track of the various art assets.

 

I've installed Cygwin. Windows does what I require it to do. If I'm doing things with Java, I use Netbeans. If I'm doing things with Lua, I use Notepad++. I'm pretty new to the programming world, so I haven't yet found a need for more powerful tools. I've never taken a class for it, and everything I know about it I've learned through trying things, and reading up on it. I learn best through immersion.

 

I don't quite grasp buildchains, yet, so you may have to explain them to me. From what little I *think* I understand about them, a buildchain uses different resources to make different builds. So you have dependency 'A', and depending on the platform, you add dependency 'B' to make the completed build, for the designated platform? Or am I completely misinterpreting the purpose of a buildchain?

[lifemare]

Cloudcrag is done and already up on Git.

 

 

...but i don't like it. The art needs a stronger contour and less detail.

But i'd say the big issue is the illusion of turf continuity is broken by that fog texture which is only applied to the ground....

 

EDIT: Should probably abandon this idea... what do you say?

Edited September 11, 2013 by lifemare

[Wilbur]

Cloudcrag is done and already up on Git.

 

 

...but i don't like it. The art needs a stronger contour and less detail.

But i'd say the big issue is the illusion of turf continuity is broken by that fog texture which is only applied to the ground....

 

EDIT: Should probably abandon this idea... what do you say?

Hmm.. No, that doesn't really fit there.

[Cheerio]

Okay, so there's an issue with animation importing that I feel should be pointed out. All of the images used in the animations should be put into the root folder, with the scml file. Otherwise, the converter seems to ignore the folders and doesn't build a correct atlas. I moved them myself, though. Maybe klei can add support for folders, as well.

 

The images shouldn't need to be in the root, they just need to be in the same relative place as they were when the Spriter project was created.  So if the images are in a subfolder when working on the Spriter project, then you should be able to move them to the same folder in the mod/exported folder.  I just tried this and it seems to be working fine but give it a try and if you have any problems, just let me know .

[debugman18]

The images shouldn't need to be in the root, they just need to be in the same relative place as they were when the Spriter project was created.  So if the images are in a subfolder when working on the Spriter project, then you should be able to move them to the same folder in the mod/exported folder.  I just tried this and it seems to be working fine but give it a try and if you have any problems, just let me know .

Hmm... It doesn't seem to do it on the first attempt for me, but now it is. I think it's related to the invisible texture bug.

 

Edit: Here is the texture bug (and my way around it) in action.

 

Edited September 11, 2013 by debugman18

[Rabbitfist]

Hmm... It doesn't seem to do it on the first attempt for me, but now it is. I think it's related to the invisible texture bug.

i like the model of the beanlets

 

@lifemare , the clouds are mde good but i agree why you don't like them

[simplex]

About the spaces in the names, those were simply unzipped as is, from the zips/rars that collaborators have uploaded. I'll try not to use spaces in file and folder names, in the future, though. As for naming conventions, they're really just named whatever the artist/animator named them. Really, the folders inside of /anim aren't being used by me, except to keep track of the various art assets.

 

I've installed Cygwin. Windows does what I require it to do. If I'm doing things with Java, I use Netbeans. If I'm doing things with Lua, I use Notepad++. I'm pretty new to the programming world, so I haven't yet found a need for more powerful tools. I've never taken a class for it, and everything I know about it I've learned through trying things, and reading up on it. I learn best through immersion.

 

I don't quite grasp buildchains, yet, so you may have to explain them to me. From what little I *think* I understand about them, a buildchain uses different resources to make different builds. So you have dependency 'A', and depending on the platform, you add dependency 'B' to make the completed build, for the designated platform? Or am I completely misinterpreting the purpose of a buildchain?

I think a better convention would be to use the intended build name as the folder name, so that the build can be automatically renamed if necessary (instead of taking the current build name as the authoritative reference).

Windows does allow proper programming through IDEs, the main issue I have with programming in it is that anything serious needs to be done through IDEs to have some form of support beyond text editing. There are no "system tools" for general purpose tasks. But hey, I started programming under Windows.

A build chain is just a generic software engineering term for a set of programs used in conjunction (in sequence, usually, hence the "chain") to automate "building" some program from a set of primitive elements, such as source code. The concept of building here is quite a general one, which may include compilation (possibly accounting for several platforms), but not necessarily. It's meant as a sequence of programs to "refine" the project in some sense, making maintenance of the project easier.

Especially under Unix systems, the core part of a buildchain is Make, whose main purpose is to track dependencies between what must be built and what's already there, delegating the actual building process to a set of shell commands (which may call other programs/scripts). A shell command is what you'd type in a terminal (such as Cygwin's one). There are several implementation of the Make program (the original Make program was written in 1977), sharing a similar syntax and mode of operation. Under Linux and Mac, the ubiquitous Make program is GNU Make (gmake), which is one of the most full-featured ones. Visual Studio has its own nmake, but it's quite basic and has a quite different syntax than most makes.

A Make program processes a file (called a Makefile) with a set of rules. A rule consists of one target and a list of dependencies (prerequisites), which are recursively built if they also have rules (using the modification time condition I noted before). So Makefiles are ideal to express composition of pieces into a whole, as well as transformation of files (PNG -> TEX conversion would be an example).

For example, in my mods I keep the project information, such as the project's name, the author, the mod api version, etc., as well as the files I intend to distribute in the zip (since I also keep some utilities in the directory that shouldn't be in the release) within a Makefile. I also don't create that dummy filesystem used in wicker manually, I just create the files in the analogue of scripts/upandaway/ and list them in the files I want to distribute. Then, I just type "make", and it builds the missing parts of the dummy filesystem, automatically generates a modinfo.lua, updates the header in modmain.lua to match that information, generates both the user-editable configuration file and the one with default configurations from a template one, generates the actual upload post from a template one (doing things like embedding a sample configuration file it generates from the configuration template) and then packages everything into a zip. So getting the project in a release state after making changes in the code amounts to just typing "make".

A Makefile can also have virtual (they're called phony) targets for general purpose tasks. For example, in the Makefile within our repo I set up a "doc" target that automatically updates the documentation. So I just type "make doc" to regenerate it. It's quite the handy tool, not only for convenience but also because manual tasks are much more error prone.

 

Cloudcrag is done and already up on Git.

...but i don't like it. The art needs a stronger contour and less detail.

But i'd say the big issue is the illusion of turf continuity is broken by that fog texture which is only applied to the ground....

 

EDIT: Should probably abandon this idea... what do you say?

Well... it certainly doesn't blend with the ground. But with a completely flat ground, I don't see how it could. I think they could still be used as "boulder-like" things, treated as actual objects on top of the ground instead of an extension of it.

Edited September 11, 2013 by simplex

[Battal]

I've got my stylus, any terrible art needed right now?

Edited September 11, 2013 by Lord_Battal

[Craig_Perry]

I like that idea. But keep away from Wendy -shakes fist at you-

Nah. Winnie has my hands tied as it is. Also worked on her perks a bit so they're more unique. I've gotten a few things.

Candies and sweets give health instead of draining it. (She can survive off the cloud realm's food better.)

Has extra insulation. (She lives in the cloud realm, she should be used to the cold.)

Can't stand vegetables. (Drains sanity.)

Storm Rams are neutral to her.

fair enough :^P hmm damn don't know much of the other characters, that's a bugger.

 

anything anyone need help with? or are all bases covered? because you are all awesomely organised and seem to have most if not all skill sets covered keep it up!

[Rabbitfist]

I've got my stylus, any terrible art needed right now?

a burning cake for me?

[MilleniumCount]

I've got my stylus, any terrible art needed right now?

Yeah, give us some hellish art! 

 

[Battal]

You're excitement is gonna fade pretty quick...I'm still getting used to drawing like this, and I'm not very good anyways.  Anything specific you need drawn?

[TeoSS69]

Cloudcrag is done and already up on Git.

 

 

 

 

...but i don't like it. The art needs a stronger contour and less detail.

But i'd say the big issue is the illusion of turf continuity is broken by that fog texture which is only applied to the ground....

 

EDIT: Should probably abandon this idea... what do you say?

Have you tried adding contour and see the difference?

[simplex]

Hmm... It doesn't seem to do it on the first attempt for me, but now it is. I think it's related to the invisible texture bug.

 

Edit: Here is the texture bug (and my way around it) in action.

 

This looks like there's just an animation missing from the Moose's asset list.

EDIT: anim/perd_basic.zip was missing. Just included it.

Edited September 11, 2013 by simplex

[ArcticFox789]

The Moose certainly looks...Frankenstein-y.

 

Anyway, certainly looking forward to the Golem. I'll be getting a graphics tablet soon, so I can contribute a bit more 'art' for the Duckraptor, which I plan to start soon.

[simplex]

@debugman18

The Wikipedia article on Make is actually a very nice and short introduction to it.

There's also the GNU Make manual, of course, but since GNU Make has a very extensive set of features it's best used as a reference.

[debugman18]

This looks like there's just an animation missing from the Moose's asset list.

EDIT: anim/perd_basic.zip was missing. Just included it.

Herp. :/

 

I'll also take a look-see at that Make wiki page.

[ArcticFox789]

I know this is a trivial matter really, but with all these additions, do we want a wiki for the players?

 

It's something we discussed for the SuperMod, so I thought I may as well raise it here.

 

Anyway, should we decide to go with it, I'm happy to work on it.

[lifemare]

I think a better convention would be to use the intended build name as the folder name, so that the build can be automatically renamed if necessary (instead of taking the current build name as the authoritative reference).

Windows does allow proper programming through IDEs, the main issue I have with programming in it is that anything serious needs to be done through IDEs to have some form of support beyond text editing. There are no "system tools" for general purpose tasks. But hey, I started programming under Windows.

A build chain is just a generic software engineering term for a set of programs used in conjunction (in sequence, usually, hence the "chain") to automate "building" some program from a set of primitive elements, such as source code. The concept of building here is quite a general one, which may include compilation (possibly accounting for several platforms), but not necessarily. It's meant as a sequence of programs to "refine" the project in some sense, making maintenance of the project easier.

Especially under Unix systems, the core part of a buildchain is Make, whose main purpose is to track dependencies between what must be built and what's already there, delegating the actual building process to a set of shell commands (which may call other programs/scripts). A shell command is what you'd type in a terminal (such as Cygwin's one). There are several implementation of the Make program (the original Make program was written in 1977), sharing a similar syntax and mode of operation. Under Linux and Mac, the ubiquitous Make program is GNU Make (gmake), which is one of the most full-featured ones. Visual Studio has its own nmake, but it's quite basic and has a quite different syntax than most makes.

A Make program processes a file (called a Makefile) with a set of rules. A rule consists of one target and a list of dependencies (prerequisites), which are recursively built if they also have rules (using the modification time condition I noted before). So Makefiles are ideal to express composition of pieces into a whole, as well as transformation of files (PNG -> TEX conversion would be an example).

For example, in my mods I keep the project information, such as the project's name, the author, the mod api version, etc., as well as the files I intend to distribute in the zip (since I also keep some utilities in the directory that shouldn't be in the release) within a Makefile. I also don't create that dummy filesystem used in wicker manually, I just create the files in the analogue of scripts/upandaway/ and list them in the files I want to distribute. Then, I just type "make", and it builds the missing parts of the dummy filesystem, automatically generates a modinfo.lua, updates the header in modmain.lua to match that information, generates both the user-editable configuration file and the one with default configurations from a template one, generates the actual upload post from a template one (doing things like embedding a sample configuration file it generates from the configuration template) and then packages everything into a zip. So getting the project in a release state after making changes in the code amounts to just typing "make".

A Makefile can also have virtual (they're called phony) targets for general purpose tasks. For example, in the Makefile within our repo I set up a "doc" target that automatically updates the documentation. So I just type "make doc" to regenerate it. It's quite the handy tool, not only for convenience but also because manual tasks are much more error prone.

 

Well... it certainly doesn't blend with the ground. But with a completely flat ground, I don't see how it could. I think they could still be used as "boulder-like" things, treated as actual objects on top of the ground instead of an extension of it.

 

Nice insight to your process simplex!

Won't pretend to understand half of that... but that is precisely why i find that post so fascinating.

 

Flatness of the ground could be overcome easily by emulating a slight perspective on the base of the boulders and feathering them like i did. But having a texture overlay that only affects ground and not structures makes the boulders look differently colored (when in fact they're exactly the same as the turf). And the fact that the poopturf has a very scant noise doesn't help either, it would require the boulders to be much larger or much much simpler to look remotely identical.

I'm fine with using them for actual mineable rocks if you want (though i don't love the idea myself), or getting rid of them altogether.

But i'll give them a second shot before that.

 

Have you tried adding contour and see the difference?

 

Not yet. I'm going to remake them completely when i have the time.

[lifemare]

I've got my stylus, any terrible art needed right now?

 

Give us a peek at your idea for the Thunder Trees!