I know it's possible to animate objects, gear, even weapons.....But is it possible to animate solid blocks? As in the kind of blocks you can stand on, put in the background, stuff like that?
Well let me turn it around a bit then; Is there a page or a list of the properties of .material files somewhere? I went checking on the wiki, and there's not a condensed list of values for such like there is other file types. I imagine it is possible, but not likely without extra script being added.
Thing is, "blocks" do not run scripts; the only way I'm thinking this could be done would be by using another type's script to look around for a given material and use drawables to "animate" them (and I think only objects and activeitems can use that), but I'm unsure about the peformances this would have. As an example, drawables is what is used by the ore detector; it overlays a white square above blocks that have a ore "mod" (modifier) to them.
Certainly. An object can easily be the same dimensions as a tile. That's 1 space aka 8x8 pixels. Objects accept the "health" attribute and it works exactly as you'd expect. I've been playing with an energy platform that changes appearance when others like it are touching(to eliminate a border thus making it look like one continuous object). That ability will require LUA to accomplish. Object can place foreground tiles via object.setMaterialSpaces that can in turn provide your collision. Doors do this with "metamaterial:door" but you could use "metamaterialbjectsolid" just as well. Upon the object being removed the tile is also automatically removed as well. You can accomplish that without LUA by adding this JSON. Code: "collisionSpaces" : [ [0, 0] ], "collision" : "solid", "spaces" : [ [0, 0] ] That last line you'd use instead of the now standard "spaceScan" thus allowing you to manually assign which spaces the object "exists" within. Now the standard sort of borders you see on tiles could be faked. You have 2 animation parts. The first part is the object, and the second part is the border(which is slightly larger. The border sits at a lower zLevel than the object itself. So two such objects themselves next to each other will hide the border where they meet. If you do this, manually defining your "spaces" becomes more mandatory than optional because otherwise Starbound will consider the object larger than it appears. There are no partial "spaces" where an object existing(or a tile being "occupied") is concerned. And since you're likely pairing this up with other tiles, the use of "renderLayer" is recommended so that it matches the layer of the foreground tiles aka no border overlaying them. The animation you want to do could be done in any way that objects can be animated of course. There would be some drawbacks 1. These won't be background "tiles". Well there are other ways of faking that too, but you probably won't have 1 object that fakes both foreground and background. 2. This will be less efficient than the tile engine, and that's before you add animation into the equation. Indeed this won't be handled by the same part of the engine(besides the collisions anyhow). Objects are considerably more complex entities. You might not want to over-do it with these "tiles." Possibly I'm over-stating this but only actual testing will tell us for sure. 3. Your animation - if necessary to do so - will be difficult(not impossible) to synchronize across all the objects.
@bk3k: That's all well and good, though not what I'm looking for. I already have objects that merge and change like signs, and even some that function like blocks in that they adjust or block player movement. What I'm looking for however is the ability to place animations in the background rather than foreground. We already have stuff that can animate in the foreground easily-- But every single one of those things prevents other objects or blocks from being placed. I do want to say though, blocks do have scripts of their own. Not sure why it was said they don't; they still make calls for block data, as well as functions for being damaged, breaking off, ect. The only issue is though I don't know where the actual files are for these things, just that they exist. Does anyone know where the .config files related to block damage and breaking are? I found -a- file in the asset/tiles folder called defaultDamage.config, but it's just simple values for damage factors and tile recovery. Anyone know where the actual code for damaging tiles that would call for these values would be?
Then...There's not a file that can be altered to produce a different effect? My thinking is, block damage is 'animated' in that each level of destruction has a different overlay sprite. If that could be recreated, with a different trigger and sprite, it could be possible to animate the blocks, technically?
I still think you have the wrong idea about how the tile engine works. If you want to see what we have access too, look at the .material files obviously, but also look at their material template config files. That's where the best things you can do are handled. I'm surprised I haven't seen anyone but myself make a custom one(or maybe I haven't noticed). You can defines some rules for boolean checks. Based on those checks, you can choose different parts of the sprite sheet to render and where to render them. Nothing about animation I'm afraid. They are also dictating that color variants are along the x axis, and recolors along the y axis. So you see the PNG files are not set up the same as animated objects that have "frames" and "states" to facilitate this. Also look at blockdamage.png, blockdamage.frames... you might think you're on the right track but actually this is used by the hard-coded part of the engine. There isn't so much as an .animation file to modify. Same deal with the tile protection equivalent. No doubt this be because the C++ side is more efficient than a scripted equivalent would be. Tiles are used so extensively that small performance differences are big overall differences. There are some things I think they should move to the LUA side of things, but this isn't one of them(as much as I'd enjoy the possibilities that would unlock). Yes there is also /metamaterials.config too. Those are also technically tiles with less configuration going on(and no images), some of the metamaterial nameSpaces mentioned are entirely hard-coded too. I gotta say this is probably a dead end.
Oh more than likely. I don't have that much experience with the engine as a whole yet, just minor modifications and the like. And yeah, there's nothing to modify with the blockdamage/protection stuff, but I would like to point out that it does mean that there can be an animation going on in the background. The animation part-- being that they're just states-- still applies to background blocks, and can be blocked by foreground entities. Likely it'd cause a [large] proformance drop, but I think that it's possible to apply an animation effect over tiles in the background...Somehow. I'm not well versed in Java, so I don't know too much of the structure or syntax, yet. But as it is, there has to be a way to hook in new structures and mechanisms into the game, right? Adding a new function that applies the same kind of effect as block damage, visually, can't be that insane, right? I'm gonna keep at it, and fiddle around with the configs to figure out what's what. I know it's possible to animate blocks, just not sure how to do it. 'sides, who knows what else will come out of breaking the game open?
