oops, I missed it :blink:
Thank you very much! :D :D 
Hi Dyson,
I am using mte.constrainCamera({loc = {1,1,mapProp.width,mapProp.height}}), when my image is within these boundaries , there is much lag , the moves very slow. What could be the problem?
First I would comment out the constrainCamera command and relaunch your app. If the lag remains, you cal rule out constrainCamera as the specific cause, and you may have your map scale set to low.
Otherwise, check to make sure you aren’t calling constrainCamera every frame, or multiple times in an event. You only have to call constrainCamera once to setup your constraints.
Hi Dyson
Just bought this a couple of weeks ago and first now I have the real opportunity to try it out.! And so far I like what you done 
But…
The first problem I have is with the onComplete on moveSpriteTo, in my test it fires directly and not after the time it has been completed !?The doc say it should fire when the move is completed but that seems not to be the case…it just fires as soon the move starts…
Example:
mte.moveSpriteTo( { sprite = hero, locX = xTile, locY = yTile, time = 2000, transition = easing.linear,onComplete=removetile(player.level,xTile,yTile,name) } )
Is it supposed to work like this or are I just doing something wrong ?
The other problem I have is, how do I specify the physics for some of the objects in tiled (not all) and mte will pick it up ? seems like what ever I do my physics objects will just fall past the tiled objects (think about it as a platform game with only one tiled level),… any ideas ?
I’m will kind of answer my own question here ;) Seems like you just add the physics properties into tiles and mte will take care of it :D sweet … (but it would be good it it was documented :rolleyes: )
Cheers
While on the topic of mte.moveSpriteTo(), I would like some delay parameter so when it does one movement, the next one can be delayed as indicated, not always fired right when its called. I am using the moveSpriteTo as my monster movement, and would like them to delay before each movement (check longer for an object to go in their range before they start moving again)
Hi Dyson,
I have commented out the constrain camera and checked my app, its far better than the before. I couldn’t see much lag, its working fine. And more over i am calling constrain camera function only once. I am using two different json.scale (0.50,0.75) for different Characters. But i am in a situation that i should use constrain camera function . Pls tell me what should i change.
Thanks,
Kumar KS.
Camera constraints shouldn’t cause any noticeable lag. Can you post or PM me the contents of the LUA file in which you call constrainCamera?
hi,
Still playing around and trying to get things to work, so at the moment I’m using the “Castle Demo” to try my ideas.
So I’ve enabled physics on the tiles (bodyType = static and physics = true) but what I discovered was that when I set the mte.physics.setDrawMode(“hybrid”) in the main.lua, the physic collition area is much smaller then the tile !!. After a bit of testing it seems like it’s down to the
local scale = 2
mte.setCamera({ locX = 53, locY = 40, scale = scale})
if I put the scale to “local scale = 0” then the tiles collision area is the whole tile…but then the whole map is tiny
I would assume that when you change the camera “scale” it would change the physics collision area as well or is it something else I need to do?
Cheers
Rotter; I’ll look the problem with moveSpriteTo’s onComplete parameter tomorrow. It shouldn’t be firing immediately, no.
Corona’s hybrid physics display is bugged such that it doesn’t update the hybrid display when the scale of the group changes. This is purely cosmetic. The collision bodies are the correct size, it’s just that the hybrid display output is the wrong scale.
Azmar; this sort of thing is beyond the scope of the function. One way you could achieve this effect yourself is to start a timer.performWithDelay at the end of one movement to start the next after the delay you specify.
Dyson
Hmm something is not right here… See this video. https://vidd.me/u0k
All i did was to add the physics to the castle code and to the tiles properties.
As you can see, we have gaps where it should be static tiles and also the dynamic tiles are all over the place !.So think it’s more then a cosmetic issue. :blink: unless I’m doing something wrong…
Hi dyson,
function GameClass:addPlayer(player, scale)
local playerobj = allClasses[player].new – CREATING OBJECT AND SENDING PARAMS
{
}
Mteobject:constrainCamera(playerobj)
end
This is how i add my constrain camera, which is called only once. If this is not the issue , can u pls tell me which factors generally would cause these type of problems.
Thanks,
Kumar KS
I checked the onComplete parameter of moveSprite to and it is working correctly. Your situation- running a function but also passing parameters to it- requires the use of a Lua closure. Simply put a closure is a function that returns another function. If you set onComplete equal to a function, that function will always run immediately. This isn’t a problem when you set it to the variable declaration of the function, because the function stored at that address will then run when the move is complete. However, calling a function will do just that: call a function, immediately.
mte.moveSpriteTo( { sprite = hero, locX = xTile, locY = yTile, time = 2000, transition = easing.linear,onComplete=removetile(player.level,xTile,yTile,name) } )
You are calling removetile(player.level,xTile,yTile,name). The function will run immediately and onComplete will be set equal to its output, which in this case I’m guessing is probably nothing.
You can change it like so:
mte.moveSpriteTo( { sprite = hero, locX = xTile, locY = yTile, time = 2000, transition = easing.linear,onComplete= function() return removetile(player.level,xTile,yTile,name) end } )
With this modification, you are calling the Lua closure immediately, which returns the function you want to call later, along with the variable arguments used by it, and onComplete is set equal to this function.
The default behavior of Corona’s physics implementation is to have downward gravity. The dynamic tiles are all over the place because they are 1) colliding with each other and the nearby static tiles and 2) being pulled down by gravity. Dynamic tiles are treated like sprites; they are not culled by the engine when they move offscreen. Static tiles are culled when they move offscreen. The result is that the dynamic tiles begin to “fall” towards the bottom of the screen because the world has culled out from under them. When you move back towards that part of the map and it comes onscreen, the engine respawns the static tiles which effectively lock the dynamic tiles in place where-ever they were at the time.
You can change the gravity with a physics API call:
physics.setGravity(0, 0)
You may find that the active tiles still wander around when they’re offscreen due to the last push given them by the static tiles as they cull. You can give them a shape property to define the shape of the physics body. You may want to reduce the (true) size of the physics bodies so that they don’t touch their neighbors and jostle around as they do in the very beginning of the video you posted.
As for the gaps which should be static tiles, are you sure you used the same grass tile, or that all the grass tiles have physics enabled? Some of the tilesets used in CastleDemo have duplicate tiles.
HI dyson,
I have rectified the problem, its because in constrain camera holdSprite is set to true, when i make it false its working fine. But i have got some other problem , now i have updated to v984-7, in this consrain camera behaves differently . I have seen that in new version you are using levelPos instead of loc, here is my code
mte.constrainCamera({loc = {1,1,mapProp.width,mapProp.height}, holdSprite= false, time = 300})
how do i change this to levelpos , my map size is 1760*1248
Thanks,
Kumar kS.
The constrainCamera function accepts both levelPos and loc table parameters. I see nothing wrong with the line of code you posted. What are the symptoms you’re seeing? How is it behaving differently from before? Please be as detailed as possible.
Map stitching is coming along nicely at this point.
[media]https://www.youtube.com/watch?v=aCV5NYp3EbU[/media]
Using appendMap you can append a map to the current map at a specified location, beginning on a specified layer. The function uses preloadMap internally, so each successive time you load the same map it’ll take much less time. Towards the end of the video I add the current map to itself, duplicating all of it’s contents including appended maps at the location specified. You’ll notice some clipping unrelated to the appendMap implementation; this is a quick-and-dirty test using the same code from the 3rd tutorial (for which a video is in the works).
On an unrelated note, I will be away from my computer from this Friday until Monday and unavailable to answer questions, etc.
Hi dyson,
When i was using loc parameters for constrain camera it was behaving well in the older version . But when i changed to the latest version , when i move the player to certain distance , it automatically disappears and starts to move from the first , which i didnt specify in the code . The camera also not moving along with the player . Should i change anything else for the new version .
Thanks,
Kumar kS
That is exactly what I was hoping for! Thanks Dyson - great stuff!
This has probably been asked before, but I can’t seem to find it. Using the castle demo code, I have a Tiled layer for ground (with layer property “level” = 1) and another Tiled layer for obstacles (layer property “level” = 1 as well), and the tiles in the obstacles layer all have the property “solid” = true. I would expect the sprite to collide with the obstacles since they all have the same level property, but the sprite just walks beneath them. If I place the tiles on the ground layer, it works (but the tiles don’t look right, so that’s not an option). How do I get MTE to recognize that the two layers are on the same level?
Has anyone else had trouble with a culling artifact? I have a slight black line on the right side of the screen when standing, and when the sprite starts walking to the right you can see the empty tiles before they are filled. When the sprite walks to the left, you can see the tiles on the right edge being deleted before they are off screen. I think the only real difference between this and the castle demo is that the tiles are 40x40 instead of 32x32. The sprite is also off centered to the left, which makes me think the larger tiles are shifting the visible screen to expose the tile culling on the right side.
Hi Dyson,
Is there any way to use @2x/@4x .png for tile maps?