Simple Tiled Implementation - STI v1.2.3.0

[Karai17]

Welcome!

1) Yes, you can access a tile's properties. If you want to set a custom property in tiled for a door tile called "door" then you can look for that property during a collision.

2) You will need to update the particular spritebatch with the new tile. I haven't made a simple way to do this so you'll need to find otu which spritebatch you need to update and update it manually.

3) You just need to make the object out of several tiles.

4) You can find out more about the contents of a map by looking at your exported map file. A quick introduction can be seen here: http://karai17.github.io/Simple-Tiled-I ... rties.html

[pevzi]

1) Yes, you can access a tile's properties. If you want to set a custom property in tiled for a door tile called "door" then you can look for that property during a collision.

Sorry, still don't understand how to access a tile itself. In a callback I have two Fixtures and a Contact, so what do I need to do? I would expect a Fixture to contain the tile so that the latter could be retrieved with getUserData, but it doesn't.

As for 2 and 3 I guess I got the idea, thanks. But regarding the documentation I still believe that it would be better if it was a bit more comprehensive.

[Karai17]

The tile data and the physics collision data are not exactly intertwined. They don't know anything about each other. What you'll have to do is determine which tile you're on based on your position.

[pevzi]

Ow, this sounds like some superfluous work to be honest. What's wrong with the "setUserData" approach? Just made a quick hack of the STI source code to implement this and it works fine and seems to be pretty convenient for me.

[Karai17]

Feel free to submit a pull request and I'll check it out.

[pevzi]

Sorry for a delay. I've also found a bug (flipped tile objects caused STI to crash) and tried to fix it in a reasonable way. So here is the pull request, hope it's not too ugly.

[pevzi]

There's another fix I've made but I'm really unsure about this one. The trivial part: at the line 475 there was a missing case of all three bits set. The more dubious part: I've made use of "origin" arguments of SpriteBatch:add to correctly rotate and flip quads (and also to correctly generate collision objects afterwards) because the method that was used for scale/rotate compensation worked really wrong in some cases which resulted in displaced tiles and their collision objects (here's an example). But the thing is that now the x and y properties of a tile instance point to the center of a tile instead of its upper-left corner like they did before. Not sure if this is acceptable. But on the other hand it doesn't seem to be a big deal for an end-user of STI. What do you think?

[Karai17]

It would definitely be better if the origin remained in the top-left corner.

[pevzi]

I think so too. Anyway the compensation method should be changed in some way because it doesn't work as intended.

[Clean3d]

Hi Karai,
I found a solution to the problem I was having. map.lua:269 needs a tile.properties table, which doesn't seem to be present on animated tiles. So, I changed this line:

Code: Select all

elseif tile.properties.collidable == "true" then

To this:

Code: Select all

elseif (tile.properties or {}).collidable == "true" then

...which makes sure that a table is at least present. This seems hacky, so I haven't committed this or submitted a pull request. You can give me a shout if you'd like me to fix this (it can probably be cleaned up with an if statement instead of an or), or I'll just let you decide how/if to handle it.