IssueHuntDo you want to work on this issue?
You can request for a bounty in order to promote it!
Custom numerical values for Enum custom properties #3534
eishiya posted onGitHub
Background
Currently, numerical enum values are set by Tiled based on whether that custom type is allowed to have multiple values. This is great as a default, but the lack of control makes it difficult to add Enums in Tiled that align with Enums in one's game, or enums that only allow a particular range of values, as those may have values that don't start at 0 and/or don't increase in the ways Tiled supports.
Feature request
For Enums that cannot have multiple values, it would be good to allow users to set custom numerical values. These would only be relevant when saving the values as numbers, so perhaps it would also make sense to limit this feature to those.
(In case this request sounds familiar, I brought this up before in https://github.com/mapeditor/tiled/issues/1211#issuecomment-943878139, but that issue was closed without this feature being added.)
UI suggestions
I think the numerical values should be displayed in the list of values, greyed out when they cannot be edited. Perhaps when saving as String, the number column should be hidden entirely since it's irrelevant, though it should keep any custom numerical values that were previously set. When editing a value, you should be able to click or double-click the number and edit it like an integer. When committing a change, if there's a conflict, I think a warning should be displayed, with options to Edit NameOfValue, which puts the just-edited value back into focus without committing the change, and Edit NameOfConflictingValue, which commits the just-edited value and puts the conflicting value into focus for editing instead. This second option would put the definitions into an invalid state if the user closes the editor at this point (and while Tiled can try to keep the user from exiting, it can't stop a force-quit xP). A potential fix is to set the conflicting value to 1+ current highest value (but give the user the old value to edit), so that the enums are never in an invalid state under the hood, even if they're temporarily displayed with invalid values for editing.
