Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Consistency on layer type and object type detection #1922
I was writing a parser and serializer for JSON map in C# for Unity, and found some inconsistency on how layer type and object type are handled.
The data for both cases are semi-invalid, so I am not expecting miracle. But maybe Tiled can establish an order of precedence for attributes, so that invalid data can fallback consistently? Like ignoring
By the way, I am ran into this issue largely because I am using the less-than-great Unity built-in serializer, it not only doesn't support
At this point I am preparing to dump Unity serializer so my issue could very well be a non-issue. Just something people should watch out for...
A even more difficult problem is object type for point and ellipse, they are both boolean flags, which is not nullable in C#.
will be a displayed as a point object instead of polyline.
I haven't looked at the code directly, but I think the precedence is something like:
gid > point > ellipse > other object.
Basically if I want to serialize current object format, I will need:
An alternative: just use
This is a bug. It is caused by the assumption that when an object is not a point, then there will not be a point property. The Tiled loading code doesn't even bother to check whether the value is
I'll be sure to look at improving the data / chunk code as well to improve the situation, though due to Easter holiday and a business trip next week I may not have time for this until Friday 6th.
It might be a bit late to suggest this: Is
Feels like it's there for the same reason as
(I am basically checking
A bit later than I intended, but this issue is now addressed in the commit above.
Well, in fact there is already
I'm not sure what would be a better solution here. It's definitely something to keep in mind for future format changes.
Thx! Sorry I wasn’t around to comment but will look into this. (From my phone)…
On Apr 25, 2018, at 0:18, Thorbjørn Lindeijer ***@***.***> wrote: I pushed another small change, to not raise data corrupted error when there is a data: null entry. I hope this helps you avoid problems there. Though data:  still raises an error (since I was not sure how to ignore this... it looks wrong to me). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.