MTE - Tile properties issue - Bug?

Million Tile Engine
#1

Dyson,

I have a 25x25 map with 4 tilesets of 64x64 - Buildings, Castle, Grass, Water … about 400 tiles.  On the first tile on Buildings and Water I have added tile properties of physics and solid both set to true.  When I am testing I collide with walls however I can walk on water - my character is not a god, at least not yet LOL.  I have debugged that the water tile #332 does in fact have physics and solid set to true.  Can you offer some insight?

Thanks,

Noral

Update - it seems that the first tile in each additional tileset is having an issue.  So tile 0 of tileset 1 has no issue, tile 0 of tileset 2 has issue, tile 0 of tileset 3 has issue, etc.

#2

Hello Noral,

First, I would turn the physics hybrid display on and check whether the tiles in question do actually have a body associated with them: mte.physics.setDrawMode(“hybrid”)

Second, there is a known bug in the function getTileProperties which causes an attempt to look up properties on the first tile of tileset 2 or greater to fail. The bug can be corrected by going into mte.lua, scrolling down to the getTileProperties function at line 1823, and changing all occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in that function. The fix will be included in the next update as well.

Let me know if that works out for you! We’ll get to the bottom of this one way or another.

#3

Dyson,

Thank you for the information - I will try this when I have a moment this evening … I am in Pacific Time.

Just an FYI - I am using the Castle Demo code and just plunking in my tilesets and map.  The only code I have changed is for testing portals … of which I have a suggestion for a code change in the castle demo.  Right now the code is limited to only an X or a Y change and in my opinion it should be both X and Y.  My guess is for the Castle Demo is was not needed, but it would be more of a complete demo :)  Can you PM your email address and I will share it.

Thanks again!

Noral

#4

Well, in that case you can ignore my recommendations about testing the physics! The CastleDemo sample project does not actually use physics for anything, foregoing it in favor of simple map-location-based collision detections. Physics is a lot more useful when you have sprites moving on a per-pixel rather than per-tile basis.

#5

Dyson,

I changed all occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in the getTileProperties function after line 1823 *and* changed the single occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in setTileProperties.  I also mentioned that I am using the Castle Demo.  In the obstacle function I also changed “if detect[i].properties.solid and i == 1 then” to “if detect[i].properties.solid then”.  Your code only checks layer 1 and I would like to check all layers.  I then ran the code and low and behold it worked :wink:

I look forward to the update - do you know when that will be.  As the new guy on the block I do not know if you have a release schedule.

Thanks for the help!

Noral

#6

I’m hoping to have the next update ready by the end of next week! I usually release updates on the friday of the week they’re finished and so far I’ve taken between three and five weeks to work on each one, depending on the size of the update. This one definitely ranks amongst the largest! 

#7

Hello Noral,

First, I would turn the physics hybrid display on and check whether the tiles in question do actually have a body associated with them: mte.physics.setDrawMode(“hybrid”)

Second, there is a known bug in the function getTileProperties which causes an attempt to look up properties on the first tile of tileset 2 or greater to fail. The bug can be corrected by going into mte.lua, scrolling down to the getTileProperties function at line 1823, and changing all occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in that function. The fix will be included in the next update as well.

Let me know if that works out for you! We’ll get to the bottom of this one way or another.

#8

Dyson,

Thank you for the information - I will try this when I have a moment this evening … I am in Pacific Time.

Just an FYI - I am using the Castle Demo code and just plunking in my tilesets and map.  The only code I have changed is for testing portals … of which I have a suggestion for a code change in the castle demo.  Right now the code is limited to only an X or a Y change and in my opinion it should be both X and Y.  My guess is for the Castle Demo is was not needed, but it would be more of a complete demo :)  Can you PM your email address and I will share it.

Thanks again!

Noral

#9

Well, in that case you can ignore my recommendations about testing the physics! The CastleDemo sample project does not actually use physics for anything, foregoing it in favor of simple map-location-based collision detections. Physics is a lot more useful when you have sprites moving on a per-pixel rather than per-tile basis.

#10

Dyson,

I changed all occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in the getTileProperties function after line 1823 *and* changed the single occurrences of “if tile > map.tilesets[i].firstgid then” to “if tile >= map.tilesets[i].firstgid then” in setTileProperties.  I also mentioned that I am using the Castle Demo.  In the obstacle function I also changed “if detect[i].properties.solid and i == 1 then” to “if detect[i].properties.solid then”.  Your code only checks layer 1 and I would like to check all layers.  I then ran the code and low and behold it worked :wink:

I look forward to the update - do you know when that will be.  As the new guy on the block I do not know if you have a release schedule.

Thanks for the help!

Noral

#11

I’m hoping to have the next update ready by the end of next week! I usually release updates on the friday of the week they’re finished and so far I’ve taken between three and five weeks to work on each one, depending on the size of the update. This one definitely ranks amongst the largest!