Selection tool and group projects

Started by Zaidyer, June 16, 2015, 08:25:47 AM

Previous topic - Next topic
I've been looking at this engine for a couple days recently and I'm very happy with how it's built as of version 1.4.2. I particularly love how quests are just a collection of files and Lua scripts, not a series of weird formats or a single big package. (Zelda Classic's "qst" format and all its numbered slots are murderously hostile to the very idea of rapid development and group organization with multiple contributors. It deserves to be left in the dust bin of the DOS era from whence it came.)
In fact, I am over the moon with how you can just drop things into the quest's directories and the editor instantly knows they exist without having to reload anything. This is absolutely vital to rapid development and decentralized group collaborations. An engine like this hasn't come along in a very long time and I'm eager to explore what it can do.

There are just a few things I want to look into to really start working on something with this.

First: When editing Maps, it seems that the click+drag selection tool doesn't work unless I start by clicking on empty space. This happens in both the tile selector and the map area itself. It causes me to spend an unnecessary amount of time very carefully shift-clicking on every single tile I want selected.

Second: When dropping resources into the game, sometimes the editor needs to integrate them into its database before they can be used, and this has to be done with user input. Would be nice if this were automated a bit better or perhaps even made unnecessary.
Imagine a group of three to five (or ten!) people collaborating on a single quest. Addressing this issue would help.

Third: Dialog entries in particular are all bundled into a single large file. This is one of the few things in this engine that is hostile to group collaborations. I suppose it could be circumvented somewhat by using some custom scripts, but I don't think it should have to come to that, as doing so would theoretically make everything a little more difficult than it should be. (Particularly translations.)

Thanks for the compliments!

1) I am not sure I understand the bug. To add a tile from the tileset to the map, don't keep the mouse pressed to drag it. Click the tile pattern in the tileset (and release the mouse), then the pattern follows the mouse on the map view and you can click again to put it. Is this the problem?

2) This is a choice that can be challenged indeed. In early versions, it was really important to associate friendly names with resources like maps and tilesets, because maps file names and tileset file names were only integer numbers (1.dat, 2.dat, etc.). So we really needed a database file to associate file names with their friendly names (we don't want to have to open all files to be able to show their friendly names in the quest editor). Now that any file name is allowed and that files can be organized in a hierarchy, friendly names is much less necessary. And now that the quest editor is able to detect very efficiently files that are created or destroyed (thanks Qt!), another reason to maintain this database disappears. So, very good suggestion.

The only potential problem is that it will take more time to open a project in the quest editor. It will be necessary to browse the whole data directory recursively to find the resources. But I think this can be also done efficiently (asynchronously) with Qt filesystem tree model.

3) Good point. I don't really see how to improve the situation though. One thing we should have is a property that marks a text as translated or not translated yet. So the translated dialogs file could start as a copy of the original one, with all dialogs marked as "not translated yet". This way, group collaboration is possible, there should be no conflicts.

What I mean with the selection tool is, you can hold left-click and drag to create a rectangle. Anything inside the rectangle is then selected. This is useful for working with groups of tiles that form a single object such as trees, mountains, dungeon door frames, and so on.
But if you left-click on a tile that already exists (whether it's from the tile window or the map window) it will not let you create a selection rectangle. There needs to be some kind of keystroke that will invoke the rectangle no matter what.

And what I mean with dialog is:
In a group project scenario, when someone is making maps, they usually want to put in NPCs. The "show a dialog" option currently refers to the master file "dialogs.dat", which is one large file containing every single dialog in the entire quest.
In order to combine work from multiple contributors, things will get very difficult very quickly unless "dialogs.dat" is phased out and each dialog can have its own unique ".dat" file instead. The folder structure is already neatly organized by language anyway, so doing this would still allow for translations to be made.

Ok thanks for the clarification.
I have just opened an issue for the selection problem: https://github.com/christopho/solarus-quest-editor/issues/47
In previous versions, Ctrl or Shift allowed to do exactly what you describe. The quest editor was rewritten from scratch recently (with a lot of new features) but I forgot do this point.

For the dialogs, I agree, this can be a problem indeed. I am not sure about having one file for each dialog though. No translation framework that I know works like this, there is always a large file with everything. But the first language does not usually have its own file, maybe this is the problem.

Why not using a github repository at least for the dialog ? If you separate the file with commentary about part of the contributor, the merge will never fail (for example, in the file, you put this :


-- Part for contributor1

[Here, all the dialog contributor1 will write]

-- End part for contributor1

-- Part for contributor2

[Here, all the dialog contributor2 will write]

-- End part for contributor2

...
...
...


This way, every contributor can change only the dialogs.dat file, the merge don't fail, even the organization inside the part for each contributor can be decided by contributor (like in a real separated file in the end).