This is a known issue (Github issue #3658). The maximum safe number of flags is 30, and I believe there’s a “fix” pending to restrict the UI to 30 flags. It’s still a mystery as to why it breaks after 30 rather than 31.
64-bit ints, whether for flags or for property types more generally, are unlikely, as JSON (used by Tiled both for some of its built-in asset formats, and for Project storage, which also includes storing custom types) does not support 64-bit ints, requiring workarounds (such as storing them as strings with an additional type disambiguator). Since they’re not easy to add (since Tiled doesn’t directly write JSON out itself and relies on layers of abstractions) and since workarounds exist for the few users who want them, I doubt we’re likely to see support for them seriously considered in the near future.
Yeah, that is weird, would expect it to break after 31.
Fair enough, I wasn’t aware that json didn’t support 64 bit types. Yeah I will make a work around, strings, or two 32 bit values.
Having an enum using string storage (with flags) should not be limited to only 30 flags though right?
As your json/xml etc is not outputting any number. Just a list of string names separated with ‘,’ or whatever like so:
If I could store up 64 of these on an object. That would save me a lot of hassle, as we need 64 bit flags. If there is no plan to change that, then I’ll think of another solution.
I’ll have a look at clarifying and finishing this issue for 1.10.2, so at least it limits to a non-buggy amount of flags.
Unfortunately, since the flags are stored in a 32-bit int internally even when “Save as” is set to “String”, and the entire UI for editing the flags also expects this, raising the number of supported flags per enum is going to be a rather bigger change.
