Default object properties derived from type properties are not included into Lua export file

[Bladum]

When using object types editor and adding custom property to specific type, then assigning this type to object on objects layer, then export it to Lua. This custom property is missing from properties table in lua export. All manually edited properties will be exported, but not these default ones.

[bjorn]

This is intensional to avoid an overly verbose export. The idea is that these defaults will usually be already part of your game, and that if needed you could read those defaults from the objecttypes.xml file. In the latter case, you'd place this file somewhere in your project.

Yet, this request has come up several times now, so I could consider adding an option to include default properties in the export. But I'm uneasy about it, because it could easily lead to huge files with an insane amount of duplicated information.

[Bladum]

Thanks, but there is no information in the export file about default properties. If you dont want to add it to export file per object, then please create section in export file that defines what are the types. What is value to keep export file clean if you need process more data outside export anyway (objecttypes.xml)

[ghost]

Is any sort of object type data stored in JSON-exported maps either? I don't see any object types fields or anything. I'm thinking an efficient way to keep from duplicating data would be this:

    "tilesets": {...},
    "layers": {...},
    "objecttypes": [
        {"name": "testObjectType", "properties": [], "propertytypes": []}
    ]

[bjorn]

@GymbylCoding @Bladum The data would then still be duplicated in each map. In any case, I could support this as an option. Alternatively I'd support Lua and JSON files as additional export options in "Export Object Types".

[kheftel-old]

Is there just one objecttypes.xml across all maps? What if you have more than one game with different sets of objects and default properties?

I'm assuming the objecttypes.xml information isn't included in the .tmx format either, right?

[bjorn]

Is there just one objecttypes.xml across all maps? What if you have more than one game with different sets of objects and default properties?

In that case, you'll currently have to switch Tiled between different objecttypes.xml files. You can do this from the "File" menu in the Object Types Editor. Later on I'd like this to be connected to a project file.

I'm assuming the objecttypes.xml information isn't included in the .tmx format either, right?

Correct.

[kheftel-old]

Oh I didn't know tiled supported multiple objecttypes.xml files. That's great!

[IoriBranford]

Alternatively I'd support Lua and JSON files as additional export options in "Export Object Types".

I'm for this.

[locknic]

Currently I am having to kind of change the default values so that they are added to the objects and become not "greyed out". Is there a way to automatically have default values added to the objects?

[EskelCz]

@bjorn "The idea is that these defaults will usually be already part of your game" When is something a default in my game engine, why would I type it into the editor? I imagine (from my experience) people usually do the opposite. They use the map editor as a source of truth. So the ease of export and version control is the primary concern. When I have separate files for my game-state origin, there is a potential for unnecessary errors. Also importing means I have to combine the two data sources and only then I can build my entities, instead of one logic pass over all the object properties.

"easily lead to huge files" I can't imagine how plain text of simple "property - value" pairs can get huge in today's standards. By this logic I would expect tilesets to also be a separate file, since they are also not always map specific. That would be even more work on our part.

Also I think you are making an assumption that everyone is using multiple maps for their game and also that map file size matters. I have the opposite case. I use just one really large map instead and I parse the export into my own game-state structure that is streamed over net, so the export size doesn't matter at all to the actual player. It's just sitting on a developers' terabyte drive.

My last issue is that xml files are a pain to parse in javascript, but I see you have already proposed to make a json as well. That would be nice but I'd really prefer that 'Export Object Types' option in settings as a primary solution.

Thanks for listening. :)

[bjorn]

When is something a default in my game engine, why would I type it into the editor?

Because otherwise, your editor can't help your level artist show which values are available, and what their defaults are. Tiled knows nothing about your engine, so it needs to be told such things.

When I implemented support for object types, I envisioned types to be basic things implemented in the engine, like "building", "npc" or even just "entity". But it seems that some people are using the types to specify more specific things like "residence", "scorpion", etc. That is not what I had in mind, but it's a valid use-case, though in that case you will obviously want to load this information into your engine.

I can't imagine how plain text of simple "property - value" pairs can get huge in today's standards. By this logic I would expect tilesets to also be a separate file, since they are also not always map specific. That would be even more work on our part.

Tiled already supports external tileset files, and in the next release I want to make working with external tileset files the default workflow. Mostly since duplicated information associated with tiles is hard to maintain.

Also I think you are making an assumption that everyone is using multiple maps for their game and also that map file size matters.

No. I know that many people are using multiple maps, and that for many people size matters. That this is not the case for everyone doesn't mean it's irrelevant.

My last issue is that xml files are a pain to parse in javascript, but I see you already proposed to make a json as well. That would be nice but I'd really prefer that 'Export Object Types' option in settings anyway.

Thanks for your feedback!

[bjorn]

Currently I am having to kind of change the default values so that they are added to the objects and become not "greyed out". Is there a way to automatically have default values added to the objects?

If you enable this option, do you expect unchanged defaults to still get updated when you change the default value after placing the object? Cause normally when you add those values to the objects, they override those defaults.

[EskelCz]

@bjorn Oh my, now I feel really stupid. Once you explained how you intended the feature to work, it finally occurred to me there just has to be another way to add properties to objects. I was looking for it earlier but couldn't find it. I just completely missed the little plus at the bottom of the window. I'm sorry, disregard what I said. :( I basically lead myself into thinking the object types editor is the only way to add properties, although it makes no sense. I'd just propose to add the 'add value' into the top menu as well just to be sure everyone finds it immediately.

[bjorn]

@EskelCz Alright, glad you found it and I'll try to make this more visible!

[locknic]

@bjorn I'm not 100% certain I understand the question, but from what I understand yes I would expect unchanged defaults to reflect changes to the object if the type that it is based on is changed. Right now my default values for my entities have almost all the options I want already set, aside from a few values here and there. Instead of being able to just change the values I want to, I am having to go down the entire list checking and unchecking the bools, plusing and minusing on the ints, and deleting and retyping characters for the strings to make sure that the level gets exported with all of each object's values. Another downside to this is if I edit the type itself, I have to go through all my entities and reflect the changes to them too since I've "overridden" the defaults (despite them being the same). I think in my ideal world, it would work exactly as it does now, except the greyed out default values are still written to the objects in the xml.

I've attached an image of how I use the properties at the moment. When I load it into my game, I actually have a parser written that then creates the json files for each entity. Then I use json to create actual java objects for each entity for artemis-odb. Tiled is really awesome! I can create everything in the editor exactly how I like.

[NotMrFlibble]

Well. All that I can say is that Starbound doesn't like these properties keys being missing and throws an exception about the first one that it finds. (It continues happily, though; it just stops adding the dungeon at that point.)

This is arguably a Starbound problem in as much as it should reasonably cope with this. However, I'm mentioning it here as it's a compatiblity issue.

[bjorn]

This is arguably a Starbound problem in as much as it should reasonably cope with this. However, I'm mentioning it here as it's a compatiblity issue.

Actually this must be about something else than this issue, because this issue is about adding something that was never there before, whereas the issue you describe with Starbound must have something to do with no longer writing a properties key when no properties are set on an object at all. This was something I did to reduce the file size and I would advice you to report that issue to Starbound since it should be trivial for the game to deal with this case.

In general I do try to avoid issues like this, but I really thought it was a mistake to always include the properties key.

[bjorn]

The above change makes it possible to use JSON as the format for the object types definition file. While not resolving this issue (since it is about the Lua export), it will still help some people.

[Rakoonic]

My question is why are the object types treated differently from every other type of grouped data by not being able to be included in the exported files?

What I would have expected is that the objects type data would be exported into its own section (or with a link to the external file), and we can parse it ourselves to extract the default values. At the very least this data should be referenced somewhere within the exported files.

For example currently you can have an internal or external tileset, but in either case, there is either the data (internal) or pointer to the data (external, with the filename property).

Tilesets are by far the closest comparision because they are a distinct, shareable asset, IMO almost identical in conceptual use, regardless of what the default is (internal or external), yet with object types you've created a new paradigm of the exported file not referencing anywhere this data.

Why not simply make these types work identically to tilesets? You already ask us to parse the object types data ourselves (IE when you instantiate an object in-game you need to reference the type and look up defaults) yet in this specific case you also ask us to find and load it.

By making an object type file external but linked, you aren't bloating the file (keep it external, but referenced with a .filename property like tilesets), and for those of us who like or neeed a single file to be the definitive contents, saving it internally does exactly that.

Sure we still have to parse our own object types for the defaults, but the data is at least there to be accessed.

I know pretty much everyone who uses Tiled in Corona SDK keeps things internally, as portability and being self-contained is far more valuable than saving a kb or 2 of string data.

Doing this also means you don't have the current problem of all maps sharing the same object type data (which you want to solve by making it part of a project setting, yet that's complicating a simple issue - there's really no problem in having an object type file as a per map setting (or, if you want to get silly, why not allow multiple object type files? ;) ).

The current problems (1 overall object type file per install of Tiled, and not actually having access to this data on exported files) are rapidly solved by my suggestions, and fit in to the current way of doing things in Tiled.

Please consider, because as it stands, this awesome feature is basically unworkable for many of us.>

Here's some samples of what I'm talking about (referenced to the lua export option - these would be top level entries):

objecttypes = { rock = { color = { { 255, 0, 0 }, }, properties = { solid = true, weight = 10, score = 1000, }, }, enemy = { color = { { 0, 0, 255 }, }, properties = { score = 2000, }, }, },

or for external ones:

objecttypes = { filename = "../myDefaultObjects.json", },

There's really no bloat there :)

[roig]

I think this should work like an external Tileset, stored in the map information as a reference.

[tomtominc]

I'm not sure if this was solved yet, but I'm exporting a JSON file and I'd like to export the custom properties for each tile. Duplication is okay. Is there a way to do this?

[bjorn]

I'm not sure if this was solved yet, but I'm exporting a JSON file and I'd like to export the custom properties for each tile. Duplication is okay. Is there a way to do this?

It is currently not possible. Something to keep in mind when adding other export options, like those noted at issue #1850.

[bjorn]

While there is no way to actually include the object type definitions, the original issue reported here has been resolved by the addition of the "Resolve object type and inherited tile properties" export option mentioned at #1850.

Of course, this will duplicate the defaults to each instance. If that would cause too much data, then it's always still an option to load the additional object types file (either in XML or JSON format). I currently have no plans to include the contents or a reference to this file in exported maps, instead I expect the object types to be more integrated with the support for projects that is planned for Tiled 1.3 (see issue #1665).