Moving tile leaves tile values & detection behind

If I place a tile at one position, and later move that tile to a new position, the tile is not detected at the new position, but continues to register at the old position, though it moves visually.

Is there a way to move the tile and have it detected at it’s new location? [import]uid: 66672 topic_id: 14353 reply_id: 314353[/import]

This also happens with :destory. I’m really at a loss here as to while the tiles remove visually but detection remains. Seems like a bug.

Anyone from MonkeyDead care to chime in? [import]uid: 66672 topic_id: 14353 reply_id: 53164[/import]

I believe I am half way through sorting this with you via email now? [import]uid: 5833 topic_id: 14353 reply_id: 55784[/import]

Indeed, been chatting since a couple days after I posted above :slight_smile: [import]uid: 66672 topic_id: 14353 reply_id: 55802[/import]

Cool, thought I wasn’t going crazy :slight_smile:

Hopefully will get it properly sorted soon. [import]uid: 5833 topic_id: 14353 reply_id: 55865[/import]

Was this issue ever resolved? I’m having the same problem as mentioned in the first post. After moving a tile, the gridposition of the tile is not updated to the new position. I have the same issue with the tile:slideToPosition() function. I’ve tried to use tile:updateGridPosition() in addition to moving it but this doesn’t work either.
[import]uid: 129287 topic_id: 14353 reply_id: 96093[/import]

Not sure. I think it’s broken, but gotta ask Graham tomorrow I guess.

  1. If you do something like setImage(), all of the tile data references are lost, but the tile still functions. The trick is, if you call getTileAt() you can regrab the tile and have all of its new info.

(I tested this; basically, when you swap to the new tile, it has whatever properties the new tile should have, but you have no access to those properties with your existing reference. So you gotta regrab.)

  1. Unfortunately I’ve found I can’t get this workaround to work at all with :drag(). Right now whenever I use that all tile and object data is left behind. Which makes :drag a drag, so to speak, because the initial getTileAt() is coming after the drag has completed.

I’ll keep looking for answers, but yeah, it’s pretty frustrating. ~_~ [import]uid: 41884 topic_id: 14353 reply_id: 96138[/import]

I need this for a crate-pushing routine (as in sokoban). I discovered a workaround for my usage, but not a satisfying one. Using the tileLayer:swapTilesAtPositions function will update the gridposition, however it needs a tile to swap places with. So what I did was filling an entire tile-layer with invisible tiles in addition to the pushable crate-tiles. Then if the player pushes a crate it swaps the crate-tile with the invisible tile behind it. This works, but it’s not a preferrable way to resolve the issue. [import]uid: 129287 topic_id: 14353 reply_id: 96143[/import]

Hmm. Not entirely sure how that solves your problem, but it is an interesting workaround.

I’m thinking for my problem the only way around it may be to use a scrolling widget though. I still haven’t found a command to update everything on :drag(), and even the objects layer only responds at their original camera location.

I’m sure both you and I will be contacting Glitch about this ASAP :slight_smile: [import]uid: 41884 topic_id: 14353 reply_id: 96160[/import]

After having done some testing, peeking through the lime-tile.lua code and printing several variables to the terminal, I’ve discovered that the grid-position is actually updated. The problem seems to be that the tile-properties are not brought along to the new tileposition. They somehow seem to be left behind at the initial position of the tile. I’m doing a property-check on my crates called Tile.isPushable to see if there is a collision with a crate and to check whether the space behind it is empty. But when using the tile:move routine instead of the tileLayer:swapTilesAtPositions routine, the crate-properties stay put at the initial position of the crate-tile. Whenever my player-character enters the initial position of the crate the crate moves, but not when he actually bumps into the crate.

richard9: I tried to regrab the information by calling getTileAt() after moving the tile, but this didn’t work for me. I’m not using setImage() though. I’m not sure why the tileLayer:swapTilesAtPositions works either. Tried to look at the lime-code to figure it out but haven’t found anything yet. Maybe it has to do with this being a command operating on the tileLayer, not only on a single tile? Don’t know. However, when using the tileLayer:swapTilesAtPositions command it seems that the tile-properties are moved along with the tiles when they switch places.
[import]uid: 129287 topic_id: 14353 reply_id: 96193[/import]

Sorry, been away the whole weekend so just trying to catch up on things now. I believe this issue was indeed solved so it should be working in 3.5 Beta. What version are you guys using? [import]uid: 5833 topic_id: 14353 reply_id: 96317[/import]

I’m one of the guys chatting with you by email already, so yeah, 3.5 beta :slight_smile:

I’ll post solutions to the thread once we all figure it out. [import]uid: 41884 topic_id: 14353 reply_id: 96334[/import]

I’m using 3.4. I tried the 3.5 Beta but since I’m not a pro user of Corona, and thereby don’t have access to the daily builds, I got an error in lime-tileSet.lua:197. (attempt to call field ‘newImageSheet’ a nil value.) [import]uid: 129287 topic_id: 14353 reply_id: 96342[/import]

Ah yea, the Beta is only for people who have access to daily builds until Ansca move all the new APIs to the mainstream build. [import]uid: 119420 topic_id: 14353 reply_id: 96546[/import]

Yeah, newImageSheet() being part of the whole daily builds featureset. :slight_smile: I’m running latest or close to latest daily these days, so hopefully we figure this one out. [import]uid: 41884 topic_id: 14353 reply_id: 96637[/import]

Graham: If this issue was solved, would it be too much to ask how to fix this in the 3.4 version? That is if it’s not too complicated and if it can be done by just changing/adding a few lines of code? [import]uid: 129287 topic_id: 14353 reply_id: 96744[/import]

Yes that should be possible, just have to find the fix :slight_smile: I will search through my emails but if TopherMade is still getting these and happens to know what the fix was please give me a shout. [import]uid: 119420 topic_id: 14353 reply_id: 97398[/import]

OK, I can’t seem to find the fix but I think I know roughly what it was :slight_smile: Are you able to send me your project ( support AT glitchgames DOT co DOT uk ) then I can re-add it and send it back to you. And make the fix public. [import]uid: 119420 topic_id: 14353 reply_id: 97405[/import]

Sent.

Thanks. [import]uid: 129287 topic_id: 14353 reply_id: 97429[/import]

Just sent you what I think is the fix :slight_smile: [import]uid: 119420 topic_id: 14353 reply_id: 97481[/import]