Brilliant! Works just fine now.
Thanks. [import]uid: 129287 topic_id: 14353 reply_id: 97569[/import]
Awesome!
For anyone that experiences the same problem before the 3.5 version is public, the fix is very simple. Firstly you must make sure any calls to the getTileAt functions has “true” passed as the second paramater. If possible only pass true when you know you are looking for a tile that has been moved.
Then the actual bug in my code, all you have to do is go into the “getTileAt” function in “lime-tileLayer.lua” and at line 431 in the second block of the if statement you should find this line:
return self:getTileAt(gridPos)
Simply change it to this:
return self:getTileAt(gridPos, full) [import]uid: 119420 topic_id: 14353 reply_id: 97788[/import]
I’m still experiencing problems with values and detection left behind at a tile’s gridposition. If I place a tile with the property isObstacle (which stops the player from entering this position), then remove it from the map (with destroy()), I still can’t move to where the tile once was. It’s as if the properties are left behind on the map, even though the tile is removed.
I’ll be mailing you an example which demonstrates it. [import]uid: 129287 topic_id: 14353 reply_id: 99870[/import]
Got the email and replied 
To anyone else, basically this should already be fixed I just hadn’t uploaded the latest version of the Beta from my computer. I have done this now so feel free to download now and test out any new bug fixes etc. [import]uid: 119420 topic_id: 14353 reply_id: 99881[/import]
Don’t know if you’re aware of this or if it’s been fixed in the Beta, but I figured I’d mention it just in case.
In the lime-tileLayer.lua there’s a call to the getTileAt-function from inside the TileLayer:removeTileAt(position)-function. So in accordance with the fix you posted further up, this call should be passing a true paramater as well, like this: local tile = self:getTileAt(position, true), to work properly. Without this parameter added, I found it impossible to remove a tile with an updated position.
My question then is, is there a problem (speed- or memory-wise) to just add the true parameter to the TileLayer:removeTileAt(position)-function or am I better off copying this function and call it something like TileLayer:removeUpdatedTileAt(position), add the true parameter to the getTileAt-call inside this function, and call this only when needed? [import]uid: 129287 topic_id: 14353 reply_id: 99922[/import]
The first issue has been fixed in the beta
I have also changed the removeTileAt function to this now:
--- Destroys a tile at a certain position.
-- @param position The position of the tile, world or grid.
-- @params full If true the search will check all tiles using their updated rather than original grid position. Might be slower then non-full search so use with caution.
function TileLayer:removeTileAt(position, full)
local tile = self:getTileAt(position, full)
if tile then
tile:destroy()
end
end So that the paramater can be passed there too. [import]uid: 119420 topic_id: 14353 reply_id: 101385[/import]
The Beta-fix dealing with values and detection needs to be added to several functions, not only the destroy()-function. Updating of the tile list “self.tiles[i].index” (I guess), must be added to all movement-functions and “placement”-functions. I’m unable to read or pass property-values when using move(), createAndBuildTileAt() and similar functions. Even the destroy() function still have issues! [import]uid: 129287 topic_id: 14353 reply_id: 103324[/import]
@Graham: Can you please try to fix these issues? I’m now stuck in no less than 5 functions in my game because of these bugs, and I can’t move on unless they are fixed. I mailed you an example a while back showing what the problem is, so could you please be so kind to have a look at it. This is really getting frustrating!
Thanks.
[import]uid: 129287 topic_id: 14353 reply_id: 105001[/import]
After hours of hair-pulling, I finally figured out a way to deal with this problem until it’s being fixed. Before destroying a tile, all properties need to be set to nil by hand. So if you have a tile with the property .isDestroyable and want to remove it from the map you’ll have to set tile.isDestroyable = nil before calling destroy() or any other remove-functions. I guess something similar can be done when moving tiles. First setting the properties to nil, then move the tile, and finally restore the property-values of the tile at the new position. At the time of writing, I haven’t resolved this, but I’m working on it. [import]uid: 129287 topic_id: 14353 reply_id: 105229[/import]
@Dr.Mabuse I had to stop using Lime for awhile (another project came up that doesn’t use tiles) so I’m not totally up to date on its progress but I’m guessing Graham is most responsive right now using email. You’ll probably want to contact him that way (keeping in mind he still has a day job…) [import]uid: 41884 topic_id: 14353 reply_id: 105288[/import]
@richard9: There are some progress and some of the issues have been fixed in the latest Beta. However, there are still bugs that need to be addressed. I have mailed Graham about this and I have sent him some example-code a while back, but I haven’t heard anything. Guess he’s busy as usual, so I’ll just have to be patient. After all, most of the time he is remarkably available and helpful!
I’ve now done a comparison between the Beta and the v.3.4 code and I’ve copied all the changes from the Beta to the 3.4 regarding updating of the tiles. It looks as if the bugs related to moving the tiles actually have been fixed. I just wasn’t informed about all the changes made to the Beta. I’m still having issues with the destroy() function where I have to set the properties to nil for this to work. I’ll have a closer look at this and the placement-functions. [import]uid: 129287 topic_id: 14353 reply_id: 105318[/import]