There's already an open PR for that: #7007

There's already an open PR for that: #7007

I think your linked PR is not related to this issue.

Your linked PR is for the general object type in Tiled. One object can have one type. The "type" got changed to "class" at some point but I think that was reverted or can be changed in Tiled how you want to store it.

This PR however is related to object properties of type class. An object in Tiled can have multiple properties and one of the types is "class" which itself can reference other class properties.

So, imo, those two things are different and the separate PRs make sense.

Oh yeah my bad! PR seems good in that case 👍

So I finally did some digging into this class property thing as I've never used it. I was pretty confused at first. Since I couldn't figure out why none of my map exports contained any values. Until I found out that the only values altered from the default in the class were exported. There is an option to export the custom class structure into an xml or json. We could parse this to get that info, I guess. But I'm not sure if we are asking too much of the user.
Also as a side note. Sadly for us the .tmj exports don't even include the types of the custom class properties. So there's no way to tell the difference between a string vs a color, or a int vs an object, etc. Some discussion about it here

Since we don't even have a test ready for this I believe this should be shelved for now and I will put it towards the back of the Tiled Cleanup list until we have some more time to look at it.

I personally would highly appreciate it because I have a custom loader right now just for this. Would be good if it works out of the box.

I try to find some time in the next two weeks to enhance this PR.

Regarding your comments:

• no need to support exported classes. This should be a separate PR but I guess it is different from game to game. I currently parse the project file to autogenerate classes in the core project but it is very specific to my game because those classes also get some utility functions auto created.
• I don't know if the type is that useful in the exported data. Since it anyway must be casted at runtime to the correct type. A user knows what kind of type he expects and I think the MapProperties class already supports this conversion/casting?
• I also wanted to have an extra loader Parameter to specify a factory method of a class to not create a generic MapProperties class and instead create a real class of the game. However, I think java.util.function is not allowed in LibGDX because it compiles against Java7. Therefore, it is impossible to do that and we can skip it.

I personally would highly appreciate it because I have a custom loader right now just for this. Would be good if it works out of the box.

I try to find some time in the next two weeks to enhance this PR.

Regarding your comments:

• no need to support exported classes. This should be a separate PR but I guess it is different from game to game. I currently parse the project file to autogenerate classes in the core project but it is very specific to my game because those classes also get some utility functions auto created.
• I don't know if the type is that useful in the exported data. Since it anyway must be casted at runtime to the correct type. A user knows what kind of type he expects and I think the MapProperties class already supports this conversion/casting?
• I also wanted to have an extra loader Parameter to specify a factory method of a class to not create a generic MapProperties class and instead create a real class of the game. However, I think java.util.function is not allowed in LibGDX because it compiles against Java7. Therefore, it is impossible to do that and we can skip it.

These are all great points. I'm just the wrong person to look at this since I was unsure of the use cases for this and did not want to make any assumptions. My use of tiledmaps may be a bit less complex than others. But I fully support adding every feature we can get in here. So feel free to have a go at it. 👍

PR #7534 which was a replacement for this PR has now been merged.
Either @silas-hw or one of the admins can now close old PR out, so it doesn't add to any confusion.