Possible feature: Tiles place on "static-layer" would automatically become static physics bodies?

Lime
#1

While I was working with Tiled, it occurred to me that you tend to use layers according to functionality also, like all moving things on one layer, background and decoration without physics on another, and also a simple hard-physics layer where all the static parts go like walls, ground, obstacles, hills, etc.

Right now you have to add property body types of static-physics to all the tiles and objects, and you have to add it to any new spritesheet you want to use, which is a little cumbersome…

My idea was that you could possibly define a special kind of layer where all tiles that would be placed there would automatically inherit a set of properties - this could then be used to easily create those static boundaries from all kind of different spritesheets with a minimum of configuration.

Not sure yet how to go about it yet… what to do with the already configured tile/object-properties (precedence?)? How to configure that (dedicated layer property?)? When should this kick-in? Simply add those layer defined props to the tile/object when they are read-in?

Most importantly though, would this be a useful feature?

Or are there other alternatives to easily achieve similar functionality?

I don’t believe the tileset and layer properties are used at this moment.

Could potentially also use json config files that have the same name as the tileset/layer to easily set defaults for a whole tileset externally from Tiled (?).

So many ideas and so little time…:wink:

-Regards, Frank. [import]uid: 8093 topic_id: 6849 reply_id: 306849[/import]

#2

I think this sort of feature would be great but I agree we need to put a bit of thought into how best to go about it. If anyone has any ideas for which the preferred choice from above would be (or any others) then please speak up. Would love to please as many people as possible with this. [import]uid: 5833 topic_id: 6849 reply_id: 23939[/import]

#3

I love this idea. Graham knows I tried the tile based properties to define static bodies in order to have to define object layer properties but had some difficulty and ended up reverting back to the object layer which is a pain. I have yet to try the config files but this was my next goto. If we can have a static object layer that would be great! [import]uid: 11904 topic_id: 6849 reply_id: 24033[/import]

#4

I have been playing with the following implementation, which seems to do what I described:

[lua]— For all the map’s tile-layers with the property “StaticBodyLayer”, make all the layer’s tiles static-body types.
– Should be called after loadMap() and before createVisual()
function Map:configStaticBodyLayer()
for i,tileL in ipairs(self.tileLayers)do
if tileL:getPropertyValue(“StaticBodyLayer”)then
for j,aTile in ipairs(tileL.tiles)do
if(tonumber(aTile.gid) ~= 0)then
aTile.HasBody = “true”
aTile.bodyType = “static”
end
end
end
end
end[/lua]

It is a little crude in the sense that it ignores and overwrites what the tile-properties may have been for HasBody and bodyType, but that is probably what you want for such a “StaticBodyLayer”: a layer with only tiles that are always auto-configured to static-bodies.

-FS. [import]uid: 8093 topic_id: 6849 reply_id: 24172[/import]

#5

I was just about to reply that I had done something similar to this directly in a create() function, thus alleviating the extra call that you guys would have to make. I’m good with either option. [import]uid: 5833 topic_id: 6849 reply_id: 24192[/import]

#6

I was just thinking as well, that although this is great. What if you wanted to set all the friction on this layer or the bounce for instance, would it be better that if you gave a layer a physics property like “HasBody” or “bodyType” = “static” that Lime then applies these properties to all of the tiles or would you prefer it to just be static and then deal with the other things on an individual tile basis.

Also, currently I have the static layer being created after the tile properties are loaded meaning they get overridden, if I did it the other way round then you could override a certain tile to not be static if you wanted? [import]uid: 5833 topic_id: 6849 reply_id: 24194[/import]

#7

It would be great if you could add it to a create function and take care of this config stuff automatically - keep it out of the user’s code and move it to a property set in Tiled’s design phase.

However, as it would work thru a naming conventions, make sure to give the property a name that wouldn’t clash too easily.

-FS. [import]uid: 8093 topic_id: 6849 reply_id: 24236[/import]

#8

Currently it is working in the create function with the Layer property of “IsStatic”. Sound OK? [import]uid: 5833 topic_id: 6849 reply_id: 24237[/import]

#9

As these kind of properties perform behind-the-scene and behind-your-back magic, which is different from those that will have effect if I write code for it - I would try to differentiate them more.

Also maybe trying to get them to the top of the sorted property list in Tiled will make it easier to catch your eye.

It seems that “_” won’t bring it to the front, but any of the “+_*” would… I’d vote for something like “*IsStatic*”.

-FS.
[import]uid: 8093 topic_id: 6849 reply_id: 24251[/import]

#10

Well it’d be part of the LID - http://justaddli.me/ldi.php - so should be easy enough to find/differentiate. Or Was that not what you meant? [import]uid: 5833 topic_id: 6849 reply_id: 24253[/import]

#11

I guess that’s ok…

Just getting concerned about the fact that all of those properties essentially get passed-on to calls like physics.addbody implicitly - name clashes are waiting to happen…

My suggestion was to ensure that your/Lime’s specific property name will be guaranteed to be different from any of the Corona or app-specific property names thru a simple naming convention, i.e. prefix.

-FS,
[import]uid: 8093 topic_id: 6849 reply_id: 24275[/import]

#12

Still going back and forth in my mind whether those tileLayer specified properties should overwrite the tile-props or whether they should function as a default tile-prop value that will be overwritten by a tile-specified prop…

Maybe the default-case causes least confusion as your tiles will behave as you have specified in their properties.

However, you would then also need a way to specify HasBody:false, as there is no way to overwrite that now.

It may then make more sense to have a more generic feature - have a “HasDefaultTileProperties” as the tileLayer prop that kicks off the magic, and have the user explicitly specify HasBody:true and bodyType:static in the tileLayer prop-list.

-Frank.
[import]uid: 8093 topic_id: 6849 reply_id: 24277[/import]

#13

How about “Physics:IsStatic”, as I use that prefix for setting the Physics properties of the map. [import]uid: 5833 topic_id: 6849 reply_id: 24278[/import]

#14

Yea that could also work, the main problem is that both way round (override or not) could be useful in certain situations. So it might be nice to be able to do both. [import]uid: 5833 topic_id: 6849 reply_id: 24280[/import]