Tiled: Being able to have an array custom property

[issy123]

Request

It would be nice if we could add a custom property of type array.
Mostly an array of strings.

I can't really see use for other datatypes, so just add array as option (which would be an array of strings)

Example

Reason

We currently use a comma seperated list to write down which doors a button would open. But this is prone to errors and prefer an array list.

[TurBoss]

you can use json, i think...

[bjorn]

While you can of course write JSON or comma separated values in a string property, I do think it would indeed make sense to support array properties explicitly, though it should ideally allow an array of any available type. Alternatively, the elements in the array could each be allowed to be of any type.

[issy123]

@bjorn What use case would satisfy the need of having any type of array?
I can only see a use case in string arrays.

Also why heterogeneous arrays? If they need heterogeneous arrays let them add custom properties of that type. This would also add complexity to parsing this, because you need to check for each array item what type it is.

It's fine by me adding those other types of arrays but it would create a huge list of options and maybe make them confused or being not user-friendly.

[EJlol]

I definitely can see use cases for other types too. A few use cases I can come up with:
A Chest object that contains several items (id / integer)
A Monster spawn area with several recolored monsters (color)
A light object that sends some kind of morse code (boolean)

[bjorn]

Also why heterogeneous arrays? If they need heterogeneous arrays let them add custom properties of that type. This would also add complexity to parsing this, because you need to check for each array item what type it is.

There shouldn't be much additional complexity to parsing heterogeneous arrays than to parsing heterogeneous property values. Anyway, the reason I considered it is because it is the normal state of affairs for any dynamically typed language. The type is associated with each value rather than with the array, and this is something many people are used to working with. It's also how JSON arrays work. So actually enforcing that each value be of the same type may be more complicated than just allowing them to have different types.

That said, I do agree the use-case is rare, so I will leave both options open until we can evaluate them while implementing this feature.

It's fine by me adding those other types of arrays but it would create a huge list of options and maybe make them confused or being not user-friendly.

That depends on how it is implemented. Most of the work is probably going to be in adjusting the Properties view to be able to work with arrays and allowing to add/remove elements. Maybe it can be done inline, or maybe it makes more sense to spawn a dialog for this. And all this work is not going to be much harder if any data is supported rather than just supporting strings.

So I'm not talking about adding just a "string array" type of property, but rather adding an "Array" checkbox separate of the type (or adding just an "array" property type, if values will be allowed to be heterogeneous).

[issy123]

4 upvotes, looks like they want it.

@bjorn is it going to be implemented?

[bjorn]

@issy123 Yes, it's going to be implemented. But currently I'm trying to focus on getting Tiled 1.1 out since there are already plenty of new features since 1.0. But unfortunately there are some things that remain to be done as seen on the Roadmap.

[issy123]

Awesome man!
I never knew github has such feature.

I'll be sure to support you on patreon!

[bjorn]

Thanks, that's really appreciated!

[styk-tv]

Definitely +1 for the list. It would be really great to be able to past json fragments. Its what I do now with the string property but looking at few lines of text and several squashed properties in one line is difficult to read. Sometimes I lock entire state machine sequence in a tile Type, would be wonderful to have better list visibility on more structured level. Start with multiline json would be great. It is then very easy to encounter that based on Type and consume into Tile capability from a single command (without having to parse each line separately. I also experiment with post-processing where this is done post-save.

[justgook]

In my opinion you can make just as visual representation in custom props and keep storing data as is.
That will not introduce new problems for parsers, but will allow navigate properties much easier, and as soon as you create name with . in name, or just name like "myArray[]" - it automatically become array, that in save-file is just "myArray[0]"

[justgook]

Btw - that way you also would be able store custom types in same array

[Phlosioneer]

I'd like to start tackling this; with #2712 almost finished, it's part of my use-case to need an array of connected objects.

Looking over this thread, here are my thoughts on the design:

• Limit arrays to one type. This is useful for two reasons:
  
  
  
  • Lets us re-use the code that Color properties currently use, where they unfold to show an array of ints corresponding to RGB.
  
  
  • We can later expand this to any type without losing backwards compatibility.
  
  
• Prevent arrays of arrays. The use case for this is small compared to the additional complexity, and no one here has advocated for this explicitly. It can be useful; but I think it's more important to ship an array property first and worry about the possibility of this later.

@bjorn Any other thoughts before I start working on this?

[bjorn]

@Phlosioneer As I wrote previously, I'm open to either typed or untyped arrays. However, I do think untyped will be easier to implement since that's just adding one new property type "array", which could probably use a QVariantList and instantiate a QtVariantProperty for each entry, which will automatically pick the right widget.

Since we can't actually use real typed arrays on the C++ side anyway, limiting the arrays to a specific type may only add complexity. It means we need to store the type along with the array somehow (unless you'd only allow empty arrays to be untyped, and derive the type of an array from its first element). In this case, I'd be inclined to add type restriction later if there is a real demand.

I think it's fine not to support arrays of arrays, unless it would work without additional complexity.