In projects where there are a lot of such properties, it is very inconvenient.
Is there any possibility to make sorting based on drag and drop of custom properties and disable automatic sorting?
And then the second question:
Is there any possibility to create a new type of property - textarea.
Now there is only a string, which can be split \n into several strings. The problem is that it is very inconvenient to read such properties.
For example, if I use my own scripting language for objects in a project and I want to introduce some function, it would be convenient to have a textarea that I can extend as high as I want and write as much text as I want.
Already implemented. Click the “…” edit button on the string and you will get a multiline text editor.
As for your first question: This has been requested already. It is probably not going to happen, for technical reasons. I’ve left a comment on the relevant issue (#2164), which was closed with the suggestion that custom property classes would have controllable order, but they do not.
Already implemented. Click the “…” edit button on the string and you will get a multiline text editor.
This is what I’m talking about. This is the division of a line with the \n symbol, and it is completely impossible to read if you do not open this dialog every time.
If you work with a large number of custom properties and need to enter scripts and quickly review them, then this string type is not suitable. Need textarea that is visible directly on the properties panel.
Ah, so like an inline text editor that expands whenever you focus on the string if it contains more than a couple of newlines? I can see that being pretty handy, at least if you keep your properties panel wide enough.
I don’t know whether that’s possible, but I’d like to see it as an option! (Option because for people who don’t need to view/edit such strings often, auto-expanding would be annoying when they’re just clicking/arrow-keying around properties.)
And if it’s not possible, perhaps showing the text with real line breaks as a tooltip would be a good compromise? So you’d still have to click the button to edit the string, but you’d at least be able to see more of the string right in the properties panel.
Related issue: It would be nice to at least be able to Save the document (so I can test the script) without leaving the editor :/ I use File properties for my more substantial scripts (so I can easily edit the files in proper text editors with syntax highlighting), but I do use strings for simple-but-unique scripts.
I answered on GitHub. As a real project worker, who is hardly using Tiled last year, I completely agree with topic starter. This is huge problem for developers who is using custom properties to insert quests, different kind of behaviors’ etc…
I got the explanation and I think I understand where the problem is coming from, but I think it is time to think if you can change the way custom properties are stored in DB.
PS: Same as lack of shortcut for property renaming. Something like SHIFT-F2 or ALT-F2 will be really helpful.
Here is a real example of one NPC from the project.
Even if we make numeric prefixes and even if we do a gap between numbers, it’s still a problem.
Imagine that I need to correct the behavior of this NPC and insert 10 more actions in the middle. If I made a gap for 2-4 numbers, then I will have to rename bunch of properties after making the changes.
In any ongoing project, such changes are made daily. Many of them.
It looks like you’re using properties to describe what are essentially full quests/interactions? Would it not be easier to edit this as a single script/interaction property or something? Even if all the properties were stored in order with the proper names, adding a new property for each step seems like a weird way to do this.
Don’t get me wrong, I agree that there should be a way to store properties in a user-defined order, it just seems like there must be a more convenient way to do what you’re doing.
Of course we tried many approaches. And yes, you can simply make links to scripts, and keep the scripts themselves in separate files and edit them with normal editors.
But in the end we came to the conclusion that the visual component during editing is very important. It is important for people who make a map and place objects to immediately see on the screen what they are writing a script for.
This also turned out to be very convenient when searching for errors. It is much easier to open the map, click on the NPC and immediately see all his actions.
In general, whether we are doing the right thing or the wrong thing is a separate conversation. But I hope you agree that even if we forget about our approach, there are a lot of other parameters that people would like to insert into objects.
We are not talking about a specific project. At least one person wrote the same thing on Github. Serious projects require many parameters.
