Objects have inconsistent origins about tmxlite HOT 2 CLOSED

Hi! I had indeed noticed this pecularity some time ago when working on one of my own projects. The inconsistency sadly runs a bit deeper than this - objects in the tmx file which aren't a rectangle contain a child node describing their shape, which the Shape enum is designed to represent. On the other hand rectangular objects have no child nodes (in which case tmxlite just assumes the object is rectangular) but they may or may not have a tile gid attribute if they are a tile object. sigh. I've always tried to maintain a 1:1 match for the data structures as closely as possible without making any assumptions on the end user's behalf, and this is already slightly skewed by the fact that I've had to introduce a Rectangle shape type which doesn't technically exist, at least not as a tmx node. For this reason I'm not keen on introducing a new member to the enum and, as you point out, it may break existing user's projects when Rectangle type objects suddenly become exclusively non-tile objects. However as an object may potentially have a tile ID Object::getTileID() exists, which can be used to determine if an object is a tile type. By default this returns 0 so it can be used something like:

if(object.getTileID())
{
    //must be a tile object
}
else {}

Which I believe is the intended (albeit slightly confusing) use. Of course should the tiled devs add support for modifying object origins I'll endeavour to support any new properties which may be added.

from tmxlite.

Thats a good point, I didn't think about checking the tileID, I think that will work as a temporary fix when properties in regards to origin placement come into fruition.

from tmxlite.