Mapeditor not adding to .tmx type properties if image tile

[ManPython]

Describe the bug Mapeditor not adding to .tmx type properties if image tile, Working for each other, eg. text, rectangle, point.

To Reproduce Steps to reproduce the behavior:

1. Go to objectes layer 1
2. Create image with tile
3. Add name and type
4. Edit .tmx in some editor and chek objects.
5. Do this same for other objctes than step 2 eg. point

Expected behavior <object id="34" type="type_t1" name="name_te" x="295" y="352.5">

Media

Specifications:

• OS: W11
• Tiled Version: 1.11.0

[bjorn]

Are the name and type displayed if you close and reopen Tiled? If so they must be stored and you might be looking at the wrong file.

[ManPython]

Yes, is displayed and greyed as eishiya indicated in linked issue. Reopen show me greyed value as string in class but in file not exist. I resolved this issue by creation property called type2 due this, but not sure.. is good way. Also for objects in tmx lib for python not serving option to discover corectly gid for objects and related firstid, co I'm going for own solution, but here is what I meet. Sounds like wrong value mapping if property or something.

[eishiya]

If the value is shown greyed out, that means it's inherited from somewhere (probably the Tile), rather than explicitly set on the Object. Inherited values are not written out by default, which allows them to "change" if the inherited value changes.

If you need the values written out, you can export the map with the "Resolve object types and properties" export option enabled. Alternatively, you can resolve the inheritance yourself when loading the map, which will make your files tidier.

[bjorn]

Closing the issue since this is not a bug.

[ManPython]

I confirming the case about Inherited, but don't seeing reason to Inherit class due tile have class. Why child object must be child for tile and can't be a parent for other object then? The tile for object is by gid, not Inherited class/type.. right? Soo.. mapeditor determining some Inherit model and limiting usage for objects due asssing texture from tiles only - this is crazy when animation can be done and tiles have many class/type names.

[bjorn]

Inheriting the class from the tile was added for convenience, because it allows people to specify the class once on each tile rather than having to add it to each instance of that tile on their map. Generally you can just ignore this feature, if you're not using it. Why does it bother you?

[ManPython]

It seems to me that it would be possible to extract a class for a tile from an object. However, not being able to save a class to an object in .tmx file is a strong lack of ready-made functions and a standard (class/type), in relation to attributes. It's not about ignore but natural cognitive sense to save in file. Ignore can be done in code, but if not have data in file then nothing to mapping for ignore. I see like to much thinking about internal function of class/type in Mapeditor, not a role of tile maps in games as .tmx data.

[bjorn]

However, not being able to save a class to an object in .tmx file is a strong lack of ready-made functions and a standard (class/type), in relation to attributes.

What makes you say it's not possible? You don't have to set the class on a tile, you could also set it on each object instead.

And if you want to set it on the tile, but still have it written out in the TMX file for each object, that's what the "Resolve object types and properties" export option mentioned by @eishiya above is for. This does require using the "Export" action, but that's because when this would be applied during a regular "Save" action, all those class values would be considered an "override" of the class set on the tile, and when changing the class of the tile it would no longer affect these objects. But so far I do not understand what behavior you're actually after, so I'm not even sure if I'm helping by explaining this.

[ManPython]

Coz I have tiles that are used with class, eg. enemy and interaction/collision as static role and this same tiles are used in objects as dynamic role with variable control python class, eg supported by other objects to interact (pins).

[bjorn]

If you use the same tile in different contexts in which different classes are needed, you can choose between:

• Not specifying the class on the tile at all, only specifying it on each tile object as needed.
• Specifying the most commonly used class on the tile and overriding it with another class on tile objects where needed.
• Not specifying the class on the tile at all and creating object templates instead, where you can set up class or no class, and then instantiate those templates. This way you don't need to do it for each instance, but it requires you to either read in the templates or export with the "Detach templates" export option enabled.