Cool, good to know.
Bertram {l Wrote}:As for importing functionalities from HoA to VT about map editing. Well, I must say I'm eager to see what you have done with Hoa in term of map editing, code design and such, but I won't have time for this until a few weeks when I see my own TODO list and patches to finish, but I will gladly have a look at this sooner or later.
I do hope that porting the VT editor to QT 4.8.x was useful for your own dev time, though.
To the user, there's not a whole lot of difference between the VT editor and the latest Allacrost editor. The same widgets are found in the same locations. I removed the layer editing toolbar because I thought it stuck out like a sore thumb. Instead, you can do everything you did with that toolbar by interacting with the layer widget itself. You can drag and drop layers to reorder them. Double click their name and edit their name to whatever you wish. Toggle whether they are ground/sky layers (I instead called this a collisions property), and right click in the widget to add/rename/delete layers appropriately. Another change is that I added another tree widget that operates very similar to the layer widget that handles map contexts in the same way. VT doesn't use contexts, so you'd just remove this widget from your editor if you choose to import the changes back. I'm also planning to make minor improvements to the tileset tab widget (making it easier to go through all tileset tabs) and the main window menu and toolbar.
Most of the changes are in the underlying class structure to make the code more sane and easier to maintain. For example, I pulled out all of the map data from the Grid class (which I renamed the MapView class) into a MapData class. The editor keeps an instance of MapData and passes a pointer to it to each widget that may need to access or modify the map data (the map view, the layers widget, etc.). Just about every class except for the dialog boxes and tileset editor have undergone a complete restructuring of their innards. And yes, moving to QT was nice. I was most excited to remove the use of our video engine to render the scene in the editor, as that was something that we always felt wasn't necessary and causes more trouble than its worth.
Oh, we also followed your example and separated out maps into separate data and scripting files. This has been awesome. We are able to write multiple script files that use the same map, so it helps keep our map scripts more organized and easier to read through. It looks like to me that VT still uses a single script for every map file, which is fine. Its just that certain maps (like Layna Village) have a ton of different scripting paths for different events that occur throughout the game on those maps. I also updated our map data file format, which you can read about here:
http://www.allacrost.org/wiki/index.php/Map_File . I doubt VT is going to want to convert to a new map file format considering how many maps you already have released that would need to be converted over. It's really easy to edit the load/save map function in the allacrost editor code to store the map data in whatever way you like.
Bertram {l Wrote}:Two things that also are really needed for maps IMHO, are:
1. Add an option to make it possible to edit the collision layer within the editor, and flag the map as having a custom collision set.
2. Add support for tilesets with different size than the old fixed 512x512 (even if it is fitting most of the needs.)
I've thought about the first for a long time, but I've never made it a priority because I don't think we're going to need to use such a feature anytime in the near future. I have no interest in supporting the second feature.
The features I want to add to the editor are more focused on usability and making it easier and faster to produce quality maps. Maps were so tedious and frustrating to make with our old editor. It was a major reason why Allacrost stalled out a couple years ago. Here's the list of features I'd like to add.
- Add support for making custom shape selection areas
- Add support for changes to selection area to apply to more than one tile layer
- Add support for changes to selection area to apply to more than one context
- Add support for cut/copy/paste from one layer to another
- Add support for cut/copy/paste from one context to another
- Add support for cut/copy/paste across multiple layers
Essentially I want the selection tool to be more powerful and to be able to make changes across multiple layers at once. Imagine a city map with a lot of nearly identical houses. Instead of building each house from scratch, what I would like to do is to make an "average" house exactly once, then select the entire house (which isn't always going to be perfectly rectangular) and hit Ctrl+C and Ctrl+V to paste multiple copies of it all over the map. Then, a user can make changes by changing the dimensions of the home, filling in the contents of the interior, etc. That would make map editing so much faster and remove the tedious laying down of individual tiles over and over to build each home from scratch. These aren't features that are guaranteed to be added to our editor this release though. It depends on where I'm most needed, as I'm currently the only one working on our map editor. Maybe if we find another developer devoted to the editor we could get this set of features in.