The .color property is not a temporary fix, rather it is a workaround for the SDK’s lack of a getFillColor property. The engine has no way of looking up the fill color of an object. When the lighting system tints an object the original tint is lost forever unless it is stored somewhere by the user. The new .color property fills that need. Whenever lighting is in use the developer must use .color if he or she wishes to change the tint of an object.
If I’m wrong about the lack of a getFillColor or functionally identical function than please let me know! It would do away with the need for a developer to set .color manually.
All that being said, I’m still trying to nail down exactly what the default behavior of MTE should be in regards to lighting. Sprite’s are lit based on their lighting parameter, a simple boolean. At the moment the default setting is true; any tinting will be lost unless you set .color. If you set the sprite’s lighting parameter to false the engine won’t overwrite your fill color and you can tint the sprite manually using Corona’s native functions.
Do you think lighting’s default should be false instead of true? Or, perhaps, “vector” sprites could default to false while others default to true? Feedback is welcome!
I used the 0-255 range because MTE uses this internally and still requires this range when using Tiled properties to set Tiled Object colors. But you guys are right about it causing confusion. I’ll go through the engine and samples and bring everything up to date with the new 0-1 range this week.
AppDeveloperGuy;
Yes, I can add in those events. That’s easy enough.
What I hope to accomplish with the new map stitching feature is the seamless expansion of a map. Using a function similar to loadMap, you will specify what map you want to load and where in the pre-existing map to place it (including outside of the current bounds). If any part of the new map is outside the current map bounds the engine will increase the size of the map table to accommodate. It will then load the new map tiles directly into the current map. It will also loop through all the Tiled properties and tilesets in the new map and attempt to merge them into the current map’s properties and tileset table. The result is that you won’t have to do anything special when moving a sprite into the new map, because the new map isn’t a seperate object. If you have a 40x40 map and stick a second 40x40 map to it’s right edge, moving into the new map would be as simple as moving to locX = 41. All you’ll have to watch out for is the load time of a map. Loading a large map will cause a noticeable delay in gameplay.
Coldwilson;
I used willEnterScene because there is only a single scene; it is reloaded and reused when the map changes. The scene is never destroyed, so createScene will only ever fire once. What I needed to do is load a new map and sprites whenever the scene was entered- even if it was entered from itself.
Scalefactor is an old concept which is no longer valid. Actually users were never meant to even see scaleFactor, let alone have to use it. In 958 the blockScale determined the size of the tiles, but the resulting coordinate system did not match that of the map file. If your tiles were 32x32 in size, but you set blockScale to 72, the tiles would be rendered at 72x72. This meant the center of a tile 1,1 on the map was 16,16, but the center of tile 1,1 in MTE would be 36,36. Scalefactor translated between these values whenever the user tried accessing them using an MTE function.
This is not longer the case. The engine scales the group instead of each tile, so a 32x32 tile with ALWAYS be 32x32 and it’s center will ALWAYS be 16,16, no matter how large or small it appears on the screen.
Long story short, you can get rid of scaleFactor. The touchScroll implementation only uses it here:
--Uncomment code block at line 341 to enable pinch zoom / touch scroll if isDragging then local velX = (startX - currentX) / scaleFactor / mapObj.xScale local velY = (startY - currentY) / scaleFactor / mapObj.yScale ...
Simply cut it out as such;
--Uncomment code block at line 341 to enable pinch zoom / touch scroll if isDragging then local velX = (startX - currentX) / mapObj.xScale local velY = (startY - currentY) / mapObj.yScale ...
Documentation has not been my strong point, I admit! I’m hoping to rectify that shortly.
Greg;
Go to line 312 of mte.lua and comment it out;
return result
Apologies, that was an oversight on my part. Basically, if an object or the Runtime receives a touch event and returns anything (even the boolean true) the touch won’t propagate to other objects.
I’m trying to cast a wide net, not get duplicate results!