Hi Dyson,
Is there any way to use @2x/@4x .png for tile maps?
Hi Dyson,
This might be silly question , but i am confused with this. How Do i find the current position of the Sprite object.
Thanks,
kumar KS.
Hi kumarks,
Maybe there are better ways but you could give this a try:
local prop = mte.getSprites(sprite)
if prop then
print(“locX,locY :”…prop[1].locX,prop[1].locY)
end
Finding the current position is in the getSprites sample code, and other useful tools.
Hi, Dyson
I am having troubles accessing objects from Tiled that are given a type or name that can be influenced through collision handler.
I created a pot through MTE (object 1 layer following demo code) with name of pot1 and type pots, after in my code I get the object, I gave it a type because the type in Tiled wasn’t working for me either.
local potObject = mte.getObject({name = “pot1”})[1]
potObject.type = “pot”
After in my collision code I give it for the pot (the code works fine for everything else)
…
elseif (agro.type == “player” and hit.type == “pot”)…but I can never get it to detect the pot, been trying multiple different ways and nothing works
Hi Dyson,
The problem solved by set the tile index over tilesets[1] has.
The appendMap API looks awesome, do you have any idea when will it be available? 
Didn’t see you recently, is everything going well?
Hansman, collision detection in CastleDemo is handled programmatically in main.lua, on lines 95 to 106:
--DETECT OBSTACLES ------------------------------------------------------------ local obstacle = function(level, locX, locY) local detect = mte.getTileProperties({level = level, locX = locX, locY = locY}) for i = 1, #detect, 1 do if detect[i].properties then if detect[i].properties.solid and i == 1 then detect = "stop" player:pause() return detect end end end end
On the line “if detect[i].properties.solid and i == 1 then” the “and i == 1” restricts the collision detection to the first layer of the level (or the first layer containing a tile at the given location). You can check all tiles on the level by removing the “and i == 1” from the code:
--DETECT OBSTACLES ------------------------------------------------------------ local obstacle = function(level, locX, locY) local detect = mte.getTileProperties({level = level, locX = locX, locY = locY}) for i = 1, #detect, 1 do if detect[i].properties then if detect[i].properties.solid then detect = "stop" player:pause() return detect end end end end
As for the issue with the exposed culling margin at the edge of the screen, I’ll need to look at your files to find the cause. I’ll shoot you a PM with my email address if you don’t already have it. The size of the tiles doesn’t matter, the engine was designed to compensate for that automatically.
Hello Phoenixongogo,
Simply include those PNG files in your project folder where the standard-size tileset PNGs are stored. Corona will automatically load the larger images to match the screen resolutions defined in your project’s config.lua file.
Hello Kumarks,
If you created the sprite programmatically you can just access sprite.x, sprite.y, sprite.locX, and sprite.locY as you would any displayObject property. If the sprite was generated from a Tiled object you’ll have to use Phoenixongogo’s suggestion to retrieve the sprite object first.
Hello Azmar,
MTE 0v984-7 doesn’t add the object type to the sprite created by drawObjects(). I’ll add that to the current development build. You can add it by going to line 6534 of mte.lua. Beneath sprites[spriteName].bounds = nil add the following:
sprites[spriteName].type = object.type
The reason your original code wasn’t working was that you were setting type = “pot” in the Tiled object after creating the sprite from it. You would have had to set type = “pot” for the object before calling drawObjects() for that to work. The above code addition to mte.lua removes the need for all that so you can just check for type == “pot” in your collision code.
Works perfectly now with that new line of code, now I am having troubles actually removing the object on touch…I did end up using the type from Tiled to get it to work properly. But when I enter collision which works fine, I try to remove the object on touch as:
mte.removeObject(“pot1”, 4)
– 4 being my first object layer on where it was created and the “pot1” is the name from Tiled designated it, its not giving me back any errors when I do this, nothing happens…but if I change the name or layer it will give errors saying it doesn’t exist. It is detecting that it exists but does nothing.
Side note: the debug command on side says Memory: “stuff”…is that the amount of memory used? I know I read that android should keep total tiles below 1000 on screen but any direction you could send me for that memory part on what amount we should stay away from?
The removeObject() function removes a Tiled object from the map data. It sounds to me like you really want to remove the sprite representing the object. I know this can get confusing what with Corona using the term displayObjects for onscreen sprites and images, and Tiled using Object for, well, Tiled Objects. Any MTE function with the word Object in it is meant to manipulate Tiled object data in the map file. What you’ll want to do in this case is retrieve the sprite using mte.getSprites({name = “pot1”}) and then destroy it. Keep in mind that getSprites() always returns a table, so in this case the object will be at index 1 of that table.
I would like to say I solved this by now, but sadly still having troubles with it 
I still have it in Tiled as an inserted object tile (layer 4 with identifier name = pot1 and type pot
local potObject = mte.getSprites({name = “pot1”})
print(potObject) – show that I got something
mte.removeSprite(potObject[1], true)
–mte.removeObject(potObject[1], 4)
I’m assuming I should be calling removeSprite but whenever I try to do this it keeps throwing me an error: attempt to index local ‘sprite’ a nil value mte.lua:1241
I understand now that before I was just removing the object box and not the actual image
HI,
As i posted earlier, i am giving tiles with some properties and i am accessing those tile properties at the run time using getTilesWithProperty(key, value, level) not layer and placing the sprites at their positions.
The sprites getting placed only at camera view is seen , but not at the tiles which are offset . Why is this problem ? I tried to inspect the mte library and i found that in getTilesWithProperty() ,
for x = masterGroup[layer].vars.camera[1], masterGroup[layer].vars.camera[3], 1 do
for y = masterGroup[layer].vars.camera[2], masterGroup[layer].vars.camera[4], 1 do
end
end
why are you giving these conditions , i feel it is not created because of these . If not please tell me the solution . Since i am calling my function only once at the runtime.
Thanks,
Kumar KS.
Hello everyone,
MTE 0v990 (appendMap, etc) will be landing in a few days. I’m just finishing up some updates to the documentation. I’ll include the Coronastein3D files as well for those of you who want to play around with them. Once that’s up I’ll start working through the backlog of questions and requests and give them more time and attention.
Kumarks, the getTilesWithProperty function returns tile display objects. MTE achieves its performance advantages over older frameworks by culling offscreen tile objects. That is why the function only loops through the space defined by masterGroup[layer].vars.camera; there are no tile objects outside of the that space. I’ll have more by way of suggested alternatives for you tomorrow.
Azmar, each sprite and object comes with performance overhead. The more sprites and objects you add to a map, the lower the performance. 0v990 supports culling of Tiled objects (polygons, shapes, free-placed tiles) which will improve performance on maps with large numbers of these objects at the expense of higher memory usage.
Offscreen physics was meant mostly for a small number of critical sprites, not every sprite on a map. It increases the number of tiles and physics objects the hardware has to handle at any given time, which decreases overall performance- quite significantly in some cases. For example, ten sprites overlapping each other offscreen will only need a small number of tiles around themselves. This is easy and fast. However when those sprites all move away from each other, the engine has to maintain enough tiles to surround each one; so ten times more tiles. This is not so fast. The performance situation is one of those “there’s no free lunch” situations: nothing is free, every object in an app takes processing power and memory to maintain, even when it is sitting motionless offscreen.
HI dyson,
Thanks for your reply and i am waiting for the solution .
Thanks,
Kumar KS.
Hi Everyone,
This is my code ,
mte.moveSpriteTo
{
sprite = self._BombSprite,
time = 0,
– easing = “linear”,
levelPosX = params.x,
levelPosY = params.y,
onComplete = function ()
self._BombSprite.isVisible = true
print(self._BombSprite.isMoving)
mte.moveSpriteTo
{
sprite = self._BombSprite,
time = self:getTransitionConstant(),
– easing = “linear”,
levelPosX = params.Destx,
levelPosY = params.Desty,
onComplete = function ()
print(“In onComplete”)
self._BombSprite.isVisible = false
end
}
end
}
At first both the onComplete Function is executing , but later on for the second time on wards the second onComplete Function its not at all working , whats the problem. Is anything wrong with the code.
Thanks,
kumar KS.
Hi dyson,
Can’t wait to try new version! thanks for the excellent work
I got an issue here,
I set “mte.enableSpriteSorting = true”,“sortSprite = true” and mte.addSprite( ),
when calling mte.update( ) i got error:
File: mte.lua
Line: 9939
Attempt to index field ‘?’ (a nil value)
stack traceback:
_plg/mte.lua:9939: in function ‘processObject’
_plg/mte.lua:10416: in function ‘update’
I tried set “mte.spriteSortResolution” for some numbers, but still got the same error.
Did I miss anything? thank you
Phoenixongogo, make sure you’re calling mte.enableSpriteSorting = true before you load your map. That is the most common cause of this sort of error.
Kumarks, I suggest looping through the map’s tile properties to determine which tiles have the property you’re looking for, and then looping through the map’s world data table to find the locations of those tiles. You can then convert that location to a level position using mte.locToLevelPos() and spawn your sprites.
--FIND TILE LOCATIONS WITH PROPERTY local map = mte.getMap() local layer = 16 local property = "temp1" local tileIDs = {} for i = 1, #map.tilesets, 1 do if map.tilesets[i].tileproperties then for key,value in pairs(map.tilesets[i].tileproperties) do if value[property] then if not tileIDs.key then tileIDs[key] = true end end end end end for x = 1, #map.layers[layer].world, 1 do for y = 1, #map.layers[layer].world[x], 1 do for key,value in pairs(tileIDs) do if map.layers[layer].world[x][y] == key + 1 then print("found", x, y) print(mte.locToLevelPos(x, y)) --Spawn your sprites end end end endHi Dyson,
Thanks for the reply, I call “mte.enableSpriteSorting = true” and “mte.spriteSortResolution = 5” before “mte.loadmap” but still didn’t work. then I noticed I didn’t have “spriteLayer = true” in that layer after I check the sample maps, after set it on the layer sorting functions well.
However I found something misbehavior when turning on sorting functions:
- the integer of “mte.spriteSortResolution” will affect upward moving speed of sprites, the larger number will increase more speed, and _ only _ affect upward movement.
2.when move the character reach the cameraLocY = 1, no matter set “mte.toggleWorldWrapY” true or false, the sprite just stuck and keep playing there but you can’t move it anymore, looks like it removed from mte with no error message.
I tried CastleDemo sample and get the same error, it looks like bugs, maybe you should give it a try:
set mte.enableSpriteSorting = true and mte.spriteSortResolution = 5 or more, add sortSprite = true in the sprite setup, make path and move character to cameraLocY = 1
Thank you
Hi Dyson,
My following projects rely heavily on MTE,
and I would like to request 2 features for appendMap:
-
appendMapRegion: copy and paste selected region from a map, so we could manage all stitch pieces in single or few maps.
-
flipX,flipY option: reverse the data loading order from tmx, so it could make a single region or map have 4 different looks.
They are really useful for generating and managing random maps,
hope the features won’t consume too much of your time, thank you very much
Azmar, there are two bugs in the current release related to the problem you’re having. The first is that getSprites always returns a table whether it finds anything or not. you can fix this by going to line 814 and replacing the line return table with:
if #table \> 0 then return table end
The second is a bug which adds “1” to the end of a Tiled Object’s name when it is drawn. The bug alters the name of the sprite, but not the name of the Tiled Object. If you go to line ~1376 you’ll see this block of code:
local spriteName = setup.name if not spriteName or spriteName == "" then spriteName = ""..sprite.x.."\_"..sprite.y.."\_"..layer end if sprites[spriteName] then local tempName = spriteName local counter = 1 while sprites[tempName] do tempName = ""..spriteName..counter counter = counter + 1 end spriteName = tempName end
Replace it with the following:
local spriteName = sprite.name or setup.name if not spriteName or spriteName == "" then spriteName = ""..sprite.x.."\_"..sprite.y.."\_"..layer end if sprites[spriteName] and sprites[spriteName] ~= sprite then local tempName = spriteName local counter = 1 while sprites[tempName] do tempName = ""..spriteName..counter counter = counter + 1 end spriteName = tempName end
Kumarks, I would need to see enough of your code to put the bit you posted into context in order to help you with it. If you’d like to email the project to me I’ll have a look at it for you.
MTE 0v990 - https://gumroad.com/l/staO/
MTE 0v990 adds several new features and functionality to orthographic (square/rectangular) maps. Isometric support for applicable features will come later.
- forceDefaultPhysics layer property: if true, all tiles on the layer will use the default physics data stored in mte.physicsData.
- managePhysicsStates MTE parameter: boolean enabling or disabling MTE’s management of sprite physics states. Setting mte.managePhysicsStates = false will prevent MTE from overriding sprite.isAwake and sprite.isBodyActive for ALL sprites.
- managePhysicsStates sprite parameter: boolean setting whether MTE manages the physics state of the sprite. Setting sprite.managePhysicsStates = false will prevent MTE from overriding sprite.isAwake and sprite.isBodyActive for that sprite.
- physicsSourceScale tileset property: used to set the scaleFactor of PhysicsEditor data imported into MTE. Applies to all tiles in the tileset.
- physicsSourceScale tile property: used to set the scaleFactor of PhysicsEditor data imported into MTE. Applies only to that tile.
- Support for Tiled Object rotation in Tiled v0.9.1-243.
- mte.appendMap(src, dir, locX, locY, layer): Inserts data from the a map file into the current map, adding layers and expanding the map bounds if necessary.
- mte.drawObjects now takes a single boolean argument, new, which sets whether the function should redraw all objects or only draw new objects, for example the objects added by appendMap.
- Fixed offscreenCulling: sprites will no longer fall through the world under certain circumstances.
- Tiled Objects with physics bodies attached will no longer switch off while they are only half-way off the screen.
- Tiled Object Culling: setting the cull property of the object or the cullObjects property of the object layer will cull those objects just as MTE culls tiles!
There is also a nice new sample project named AppendMap which, surprise surprise, demonstrates the use of the new appendMap functionality by stitching a large town map together out of many small maps. In this case I made the individual maps relatively obvious by designing the town around a grid, but you could also follow a more random approach to create more varied maps.
This update also includes dozens of fixes for bugs reported since the release of 0v987-4. Those of you with current issues with 0v987-4, I ask that you load the affected projects into 0v990 and see if the problems are resolved. As usual I will keep an eye on the forum for bug reports. Next on my todo list is the implementation of applicable features added in this update to Isometric maps as well.
Enjoy!
Now that the update is up, my attention will be elsewhere for the next couple days, namely 1) Hurricane Arthur careening in my general direction and 2) 4th of July celebrations.
Phoenixongogo, if you could send me a project exhibiting the behavior you’re seeing with sprite sorting that would be very helpful. I’ll have a look at it as time becomes available.