Release 0.1.0: Map Mode/Editor Feature Changes

[Roots]

I updated the Map File page on the wiki this evening, which lays out our standards for both map data files and map script files. I still need to update the script file portion, but I've decided on our new standard for the data file. Take a look at it.

By far the biggest change is how we store tile data. If you recall, before we would have a table for each tile layer for the base map context (lower_layer, middle_layer, upper_layer). These tables were all the same size and contained the tile number that should be placed at that location. If the map had additional contexts, there would be a context table for each context. Entries in this table were grouped into four sets of numbers that represented the layer, x/y coordinate, and tile id to determine what tiles should be drawn. The idea behind this was that most contexts were expected to inherit and only change a small portion of the map, so we'd just separate out the data that changed. But if a context did not inherit, this would be a lot of data. And I didn't like the idea of the base context and other contexts having a different data format.

So instead, the new standard I thought up uses a single table and stores all the tiles for each layer and context all together. For example, lets pretend we have a map with 3 tilesets, 2 tile layers, and four contexts.

Code: Select all

map_tiles = {}
map_tile[26][74] = { 216, 78, 89, 103, 544, -1, -1, 11 }


The first two numbers represent the tiles that should be drawn on layers #1 and #2 for context #1. The next two for context #2, and so on. So the size of an entry in this table is always (# tile layers * # map contexts). It makes everything much more consistent and easier to write and parse the data to the file. The downside is that contexts which inherit from others will be writing a lot more data than they could otherwise. we're dealing with just 32bit integers here, so I don't think we're going to need to worry about memory consumption (although I worry if loading large maps might take a while on slower PCs).

Thoughts on this new standard? I'm open to suggestions for improvement. I'm pretty satisfied with this new standard though, especially compared to the wonkyness of the last map file format.

[Roots]

With so much talk about the editor changes, there's been no visual information. Here's a screenshot of the VT editor I took today so you can get an idea of how the Allacrost editor will look in a few more weeks. The biggest change is everything to the right of the map view area. Instead of tilesets being listed on the bottom of the page, now they are found in the lower right. Above the tileset area is the layer selection/view area. Notably missing is anything for map contexts, since VT does not use that feature. This editor looks pretty slick, doesn't it? Going from this image, here's how the Allacrost editor will be different.


1) The coordinate information on the bottom will be more succint. I believe I specified coordinates as "Tile (x,y), Coordinates: x.x, y.y".
2) The tileset tab names on the bottom right will not include path information or filename extension. They will simply be called "Mountain Landscape", for example.
3) The tile layer will not include type information like "ground" or "sky". Instead there will be a small area with a boolean flag so you can make the tiles in that layer collidable or not collidable
4) The top area with the layer information will include a tab or some other ability to swap it out and display the context information instead. There you can select the active context, change context inheritance, etc.


Here are additional changes I'd like to see in the future, but aren't high priority and may not make it into this release if there's no time.

1) Change the options in the file menu to: "File, Edit, Select, Tools, Help"
2) Expand the area on the bottom for the tileset names so it has more vertical height. That way if we have a lot of tilesets, we can keep all their names on the screen and don't have to scroll through a big horizontal list
3) I'm not sure about the little toolbar for editing the properties of the tile layer. Might do away with it entirely and just have people click the various properties on the layer to change them, or drag layer names around to reorder them

[Roots]

Update

Been working through the map code to add support for custom tile layers and objects. Tile layers were simple enough, but objects layers is a bit more difficult. Also the map code is a lot more messy than I remember it being. :/ But I'm not going to spend time right now improving the internals of this code so that its nice and elegant. That can be done later when there's not more urgent matters at hand. My aim is to have a polished API that won't need to change (because I don't want to be going through and updating all our map files later), but to leave the internals only "good enough" to do what we need them to. I would need to sit down and seriously think about all of this in order to do this design "the right way".


We're only using a single object layer in all of our maps so far (the "ground layer'). What I'm thinking about doing is defaulting all created objects, map zones, etc. to use the default object layer that automatically gets created with every map. Then later down the road, we can add the ability to allow objects, zones, etc. to be placed on a different layer and truly support multi-object layer maps


Should have something committed before next week. Then, I'll return to the editor. Still hoping to find another developer to join the team and convert the map data files to the new file format. I can do it myself, but its quite a bit of work and doesn't require any experience with the code, so its a perfect task for someone new.

[Roots]

Update

Back at work on the editor. Things are going pretty well so far and I feel like we'll have the editor usable again much sooner than I thought we would. I'm shooting for the end of this month to have the editor back to a state where we can safely use it to make and edit maps once again, but it may take a little longer if I run into difficult issues. I change a lot of code in the editor previously so that's definitely a possibility. Honestly, I am pretty shocked that the editor isn't in a severely broken and unusable state right now. Take a look at the editor tasks on the Roadmap. We're actually not far off from being finished with the green tasks (which is when I would consider the editor usable).

Right now I'm working on getting the layer edit widget working correctly (top right widget in the image two posts above). This is going to take some time because I'm writing a brand new self-contained class for all the logic that happens here, rather than mixing it in to the main Editor class. I'm having to go through QT documentation to figure out how to get this new class to do everything that I need it to do. I also decided to remove the layer toolbar on the right because its just...not an ideal design. In its place, a widget very similar to the layer class will be displayed. Only instead of displaying layer information, it will display context information. This will also be a brand new class that will take some time to put together. The good news is that it will be based off of the same QT class that the layer view uses, so once I perfect the layer view, the context view should be much easier to finish.

Following the completion of those two widgets, I'll need to reimplement the map file load/save logic to use the new map data file format. Then I'll just have to do some testing and further bug fixing and we should be good to go. There are several "nice to have" features I'd like to implement as well, but if we don't have anyone to work on map creation/design, I'll probably have to put that aside and do the map work myself.

[Roots]

I'm working on implementing all the features we need to support multiple contexts in the editor now. Here are a few things that I'm planning to do:


1) Add an "inherited tile" code.
We use -1 in a layer to indicate "no tile". What happens if we have a context that inherits from another? Currently, we treat it the same way and no tile is drawn. This works for some situations, but not others. What if we're inside a house and we want to show some of the tiles that are outside of the window from the context on the outside of the house? We don't have a way to do this.

The solution is to add a new tile code, -2, that says "draw the tile from the context that I inherit from at this position". We need to support that much at least. Its up to the map scripts if they want to do something else with inherited tiles, such as use a 50% black overlay so they are shaded differently, apply a custom shape so that there is a "cone" of outside tiles as opposed to an odd rectangular section, or whatever. This will be easy to add support for in both the editor and map mode. The tricky part with the editor is a usability issue, and how to make it clear to the user that "this tile is inherited" versus "there's no tile at this location"

2) Changing context inheritance
The new code, however, doesn't make any sense for a tile context that does not inherit from another. Imagine a scenario where we have an inherited context, make it non inherited, then inherit from a different context. The "inheriting tiles" would be lost, and this could be a big annoyance for the user. So I'm only going to convert -2 to -1 for non-inheriting contexts when the map is saved.

3) Cloning contexts.
Another feature I think will be useful to have is the ability to clone a context (adding a new context using all the same tiles as an existing context). This will not be difficult to do, so I'm going to go ahead and add it. Might add the cloning feature for tile layers at some point as well, but leaving it out for now because I can't see that feature being used as often.



My goal is to get contexts finished in the editor by the weekend, but I've fallen ill this weekend so I'm trying to rest and recover. I'll be on vacation the following week. If we're lucky, we'll have a usable editor again before the new year. But I'm not holding my breath because we still don't have another active developer, and it's a lot of work for me to handle by myself.

[Roots]

I updated the first post in this thread to reflect all of the work that I've completed. As you can see, there's been a ton of progress made since this discussion was started. Excluding the "nice-to-have" features that are optional for this release, there are only a few things left to do:

• Convert old map files to new format
• Change MapMode map file loader to parse new format
• Make changes to the editor to load/save to the new file format
• Fix up bugs and other issues with the new editor
• Make necessary changes in both MapMode and the editor to support the new format of contexts

The first two of these tasks is something that I would like someone else to do. nemesis has said that he'd be willing to work on it, so I want to describe more precisely what needs to be done here. Please refer to the wiki page Map File and look to the data file section to describe what the files in lua/data/maps should be re-formatted as. The old file format is kind of slapped together and I'll try to explain what needs to change below, but if you have questions about it just ask me. You should write a script or program to do this, and it can stand alone from the entire code base (no need to include any utilities or anything like that). Any language will do, but I recommend using Lua to do it since it will be easier to parse the existing files (since obviously a Lua script can read the data in a Lua file).


Here's the top information from an old map file (harrvah_underground_river_cave.lua):

Code: Select all

context_inherits = {1, 1}

---------- BEGIN: Map Editor Generated Content ----------

map = {}

num_map_contexts = 3
num_tile_cols = 139
num_tile_rows = 110

sound_filenames = {}

music_filenames = {}
music_filenames[1] = "mus/Cave2.ogg"

context_names = {}
context_names[1] = "Passage Collapsed"
context_names[2] = "Water Unblocked"

tileset_filenames = {}
tileset_filenames[1] = "desert_cave"
tileset_filenames[2] = "desert_cave_ground"
tileset_filenames[3] = "desert_cave_walls"
tileset_filenames[4] = "desert_cave_walls2"
tileset_filenames[5] = "desert_cave_water"


Here's how it should look in the new format:

Code: Select all

local ns = {};
setmetatable(ns, {__index = _G});
savetest2 = ns;
setfenv(1, ns);

map_name = ""
map_designers = ""
map_description = ""

map_length = 139
map_height = 110
number_tilesets = 3
number_tile_layers = 3
number_map_contexts = 3

tileset_filenames = {}
tileset_filenames[1] = "desert_cave"
tileset_filenames[2] = "desert_cave_ground"
tileset_filenames[3] = "desert_cave_walls"
tileset_filenames[4] = "desert_cave_walls2"
tileset_filenames[5] = "desert_cave_water"

tile_layer_names = {}
tile_layer_names[1] = "Ground"
tile_layer_names[2] = "Detail"
tile_layer_names[3] = "Sky"

tile_layer_collision_enabled = {}
tile_layer_collision_enabled[1] = true
tile_layer_collision_enabled[2] = true
tile_layer_collision_enabled[3] = false

map_context_names = {}
map_context_names[1] = "Base"
map_context_names[2] = "Passage Collapsed"
map_context_names[3] = "Water Unblocked"

map_context_inheritance = {}
map_context_inheritance[1] = 0
map_context_inheritance[2] = 1
map_context_inheritance[3] = 1


Hopefully you can figure everything out about those fields from that. Some of the data in the map file is new, such as the tile_layer_names. Just copy the same value over for any new data from the example I posted above. Some of the old map data (sound_filenames, music_filenames) is no longer used. Throw that data out.


Now there are five other tables remaining, and these will take the most work to convert:
map_grid
lower_layer
middle_layer
upper_layer
context_*

For map_grid, simply rename the table to "collision_grid" and keep all the data the same.

The new file format contains a new table called "map_tiles", and this table contains the combination of all the data that was previously found in lower_layer, middle_layer, upper_layer, and context tables. The map_tiles table is formatted like so:

Code: Select all

map_tiles = {}
map_tiles[0][0] = { ... }
map_tiles[0][1] = { ... }
map_tiles[y][x] = { ... }


In other words, every tile in the map has all of the tile information written to a single entry in a 2D table on one line. Unlike how a single tile used to be defined by multiple tables in the old format. Going back to our earlier example file, there were three tile layers and three tile contexts. Here's how the data from those old tables should be converted to the new tables:

Code: Select all

map_tiles[y][x] = { lower_layer[y][x], middle_layer[y][x], upper_layer[y][x], context_01, context_01, context_01, context_02, context_02, context_02 }


Now the context_** tables are the most tricky to convert, so read this carefully. The old context tables were formatted like this: context_01 = { LAYER, X, Y, TILE, .... }. That is, every four numbers in those tables would determine one of the properties of a tile. The LAYER number indicates which layer the tile is in (0 = lower, 1 = middle, 2 = upper). The X and Y numbers are the coordinates where the tile should be placed. And the TILE value is the tile index into the tilesets that should be used. So read through these tables and extract every four values you read and process those as a single entry. For example, if we came across the following in the context_01 table: "1, 24, 96, 156", this means that we should enter the value "156" into map_tiles[96][24] as the 5th value in the table (because it's the middle layer of the second context).

Now the tricky part is that not every tile in the context_** tables are mapped. In fact, the vast majority of tiles in a context are not mapped to anything. In this case, you should enter a value of "-1" if you don't have information for the context table and the context does not inherit from another context (see the map_context_inheritance table to figure this out), or a value of "-2" if the context does inherit from another context. The easiest way to do this is to first figure out if a context inherits from another or not, then fill in all -1 or -2 values for the entire context appropriately. After the map_tiles data is initialized with these numbers, read the context_** table and change the appropriate data as you parse the values in these tables.


I know that's a mouthful and can be confusing to wrap your head around. Ask me if something doesn't make sense or you need additional clarification. Once you read all this data in from the file, the next step is obviously to write it back out to a new Lua file (so you can check that things look correct without overwriting the old file). The exact format of the new file in terms of line breaks, spacing, etc. are all laid out on the map file wiki page linked at the top of this post. This is a very important task to do, so I hope that it can be completed or at least partially completed within a couple weeks.

[Roots]

Update
We're near a major milestone with the new editor. It's usable for creating maps again now, and the only major feature that remains to be completed is adding support for inheriting contexts. There are still a large number of bugs that need to be squashed as well, but most of them are small. I'm really happy with our new editor and even though it took longer than I expected to do this work, I think it has been worth it.

The Roadmap still lists several optional tasks for the editor that have been discussed in this thread. I think it's unlikely that those will be implemented in this release. My efforts are going to be needed more strongly elsewhere (probably map creation/design), so unless someone else steps in to work on the editor or other people are covering the more important work, those features will have to wait. There are, however, several small features that I've realized would be immensely useful that I realized during my work on the editor and playing around with Tiled. Those I'm going to attempt to add in, but might leave them out if they are harder to add than I expected (I'll discuss these shortly).


Final Steps
Here's the final list of things that I'm going to finish for the editor in this release, in roughly the order I plan to do them. Once this list of items is complete, I'm going to step away from the editor and either use it to make our maps, or work on other more urgent tasks.

• Change the edit mode "Move" to "Swap"

We've had this edit mode since the dawn of time, but it's never been very useful. The move mode allows you to drag a single tile to a new location and erases the tile at the old location. I'm going to instead rename this to swap mode and it will work nearly the same, but instead of erasing the tile at the old location it will swap the contents of the new and old locations. This will apply to selection rectangles too. Should be pretty simply.

• Implement Inheriting Context Feature

There is already partial support for this, I just need to finish it up. I might decide to do the "bare minimum" necessary to get this working and leave it up to future releases to really polish this feature in the editor.

• Fix bugs and "missing" functionality like fill/clear selection

As I said, there are tons of small bugs everywhere. Some old features like fill layer are completely gutted and need to be re-implemented. The most difficult bugs deal with operations on selection areas.

• Dialog for insert/remove rows/cols

Currently we can only insert or remove a single row/column from the map at a time. I want to add a right click option that brings up a dialog window that will make this much more powerful. Might add it to the main menu as well.

• Improve tileset tab widget and tileset add/removal/update support

I'd like to improve this widget in the UI to make it easier to add and remove tilesets from the map. I'll probably add a right-click menu to this

• Improve selection actions

Using the selection tool is quirky right now and difficult to use. You can enable "select mode" but there's no tool to really create, change, or clear your selection. I need to figure out a better way to do this, and will likely look to the Tiled editor and follow their example.

• Right click selection menu

I want to add a right click menu for the selection area on a map. Actions in this menu could be "Copy to Layer", "Move to Layer", etc. I'm sure that we can figure out some more uses for this menu down the line. The use case I'm thinking for this is when plopping down a large object or structure (such as a tree). You want some tiles in a "ground" layer and others in a "sky" layer. Would be convenient if you could put the whole tree down at once, then select the portion that should go on a different layer and use this menu to do that. Right now, you'd have to select each half of the object individually.

• Add "ghost paint" feature from Tiled editor

One super nice thing about the Tiled editor is that you can see what you're painting before you plop it down. We don't have any thing other than the cursor, and sometimes I'll accidentally paint something in the wrong spot because I wasn't aware of exactly where it was going to be placed. Was only a minor annoyance when we had the undo/redo support, but that feature is now missing so it's an important issue to address, less we waste more time with map design than we should.

• Created editor use video and upload to youtube channel

Once I'm comfortable with the editor for prime-time use by others, I'm going to make a short video explaining how to use it and its capabilities. I'll upload this to our youtube channel (which contains only a single video I made a couple years ago). This video will serve as our "user documentation" for the time being, as I don't really have time to write that up myself.


Future Changes
Now here's some things for us to consider for the future.

• Add code editor documentation to the wiki

The editor is a major component of the code yet has no documentation on how it works in the wiki. I'd really like to change this, and I expect I'm going to be the only person willing to do this work. I might get around to doing this before the release, but we'll see. Part of the reason I want to write this is to make it easier for others to help out with the editor. It's not a good situation for me to be the only one able to work on it, considering all the other things in this project needing my attention.

• Re-enabled undo/redo support

I bring up this feature because it would be really, really nice to have it back. The problem is that it is very difficult to add in, and will have to be done in a completely different way than it was before. Ideally, this feature will be working before the 0.1.0 release, but I'm not holding my breath.

• Hire QT Developer

Would be nice if we could find a short-term developer willing to finish the rest of the editor features and really polish it off. I miss having gorzuate around (who fathered the original editor and took care of it for the rest of us). I don't expect that we'll need or want to continue investing our time in the editor for the long-term once we have all of these nice features in place.

[Roots]

Update
Support for inherited contexts is now in the editor. This is the last major feature that I am adding for this release. Whether or not I get around to any other features depends on our priorities. Now I will be focused completely on bug fixing and improving usability. Top most and roadmap have both been updated.


I'm making changes to one of our editing tools, the Fill Layer tool. This tool wasn't very useful because it would simply fill the entire layer with the specified tile. There was no way to use it to fill a specific area. I'm renaming this the "Fill Area" tool and it will be a normal tool like paint, erase, etc in that you can only select one of these tools at any time. This tool will work just like the fill tool in an image editor. When you click a tile, every tile adjacent to it that is the same tile will be filled with the selected tile (or tiles). When you select an area on the map and use this tool in that area, it fills the entire area with the tile regardless of what the value of each tile in this area is. The Clear Layer (renamed Clear Area) will work in the same way, only it will remove any tiles. I'm also adding a third tool similar to Clear Area called Inherit Area, which will fill with inherited tiles (this tool is only active for inherited contexts).


The tiled editor has a cool "random input" state that you can activate by clicking a dice icon. When this is active, any tiles you paint, fill, etc. are filled randomly with the selected tiles from the tileset widget. It's pretty nifty and can be useful for randomizing an area of dirt, grass, etc. really easily. This is something I really think we should consider adding at some point, but I'm not planning on adding it in for this release as I consider it a low priority feature.

[Roots]

Update

Really getting down to the wire now. I estimate that in 1-2 more weeks, all the necessary work for the editor will be done for this release and I'll be moving on to something else. Probably the map code to support the new file format and the enhanced support for inherited contexts. Here's what remains to be done:

1) Implement the swap tool (formally called the move tool).
2) Implement the area tools (fill, clear, inherit area).
3) Implement the "ghost paint" feature so you can see where you're painting what you're about to place down
4) Implement the select are tool (its pretty much broken right now)
5) Implement select area actions (move to layer and so on)


I've fixed all the bugs in the editor that I'm aware of right now. I'm sure there's still some more to be found though, but hopefully they are minor. I wish I could continue working on the editor for longer and add in some of those nice-to-have optional features, but since I'm the only active programmer right now that's unfortunately not possible. There's too much code for one person to handle alone...

[Roots]

1) Implement the swap tool (formally called the move tool).
2) Implement the area tools (fill, clear, inherit area).
3) Implement the "ghost paint" feature so you can see where you're painting what you're about to place down
4) Implement the select are tool (its pretty much broken right now)
5) Implement select area actions (move to layer and so on)

These features are now all implemented and working. There are still some small to moderate fixes that need to be made to the various tools when they are operating with a selection area. There's one final feature that I want to squeeze in, and that is the ability to make custom-sized selection areas (ie not just a rectangle). I decided to add this one in because I don't think that it will be very difficult. So yeah, one more feature to add and a bunch of fixes to the editing tools, and then the editor work will be complete for this release.

[Roots]

Exciting Update
The editor overhaul/upgrade/redesign is officially complete! Look at the roadmap for all of the features that I've implemented over the past couple months. It's been a lot of work, but I'm confident that this effort will quickly pay for itself as we design more complex maps. I'm eager to start using it myself to enjoy the fruits of my labor and finally make forward progress on this next release. I also hope it will help me identify the last few bugs that need to be fixed. There's still a small amount of work left with the editor. I know of one minor bug with the selection area sometimes not drawing a tile that has been clicked with another tool. Also the four primary tools (paint, swap, delete, inherit) need some changes to play nicely with selection areas. Those are the only remaining issues that I know of at this time that are important enough to fix. I'll likely be leaving a few minor bugs and UI quirks in there since they aren't a big deal and can be fixed at a later date.


I'm not transitioning my efforts to the map mode code. I've already committed changes so that the map code can load the newly converted map files. Support for inheriting contexts needs to be added to map mode (currently inherited tiles are just treated like missing tiles). I'm also thinking about adding a fourth mandatory function for map scripts, in addition the Load, Update, and Draw functions. This function would be called Reset, and would be called whenever the Reset() function of the mode is called. I'm thinking that this is going to be needed for certain maps to handle changes to the audio or graphics that need to be happen whenever the mode is re-activate. I'm also thinking of adding a boolean to the MapMode class that is used to keep track of when the first call to Reset is made (in other words: we can check when the map first becomes active). This will be useful for some of the loading code that is currently kind of hacked at the end of the Load function. There may also be certain script functions that we'd want to call only on the first activation of a map (like play an environmental sound). I also need to make some changes to the way audio is handled, as right now the first music track auto-plays and we don't necessarily want that. We want to be able to pre-load our music and play it when we choose, not hard-code playing of any audio in the map code. So that change will be incoming as well.


Finally, as I start working more on the map scripts I'm going to start figuring out the best way to conform the script files. The script files have very minimal requirements for what they are required to implement, and it will remain this way. However, it's not beneficial for each script to do common things their own unique way. I'm going to standardize the way we do certain things like add characters, enemies, dialogue, and so on so that map script files are easier to understand and work with. Of course there's always the option to do things in a unique way when it is required. I'm not heading into this with any sort of firm plan, as I expect that I'll figure out a good way to do this as I go along and work on the maps. I'll be adding the changes to the map file page on the wiki when I do.


One more thing I almost forgot: the new editor video. I have to figure out a screenplay of how I want to do this and probably make a small sample map to work with in the video. I'm also going to show at least one of the actual maps in the game for these examples as well. I'm going to try and keep this video under 5 minutes, but there's a lot to cover so I wouldn't be surprised if it turns out to be 7-8 minutes long. I'm also going to try to make it more interesting to watch than the last video I made a couple years ago. We'll see what I can do. This is going to take me quite a bit of time to make I imagine, but I'll try to get it done by the end of the month.


Summary

• Editor work is done except for a few small things to polish off.
• A few changes will need to be made to map mode to provide better functionality for map scripts
• Looking to confirm map script files to a standard to make them easier to write and comprehend
• Producing a "how-to-use" video of the new editor by the end of the month

[Roots]

Decided I would go ahead and show off a screenshot of the current editor in action. This is what our editor tool now looks like.



A few notes:

• The screen devoted to the map is much greater than before, now that the tileset data is moved to the right side of the screen (instead of the bottom)
• You can easily see what layer and context you are working on with the two widgets at the top right. You can double click and right click in these widgets to change properties or add or remove layers or contexts.
• Tileset tabs are easier to navigate than before (I think...can't remember how they used to be).
• The main menu is cleaned up and is now much simpler. Each menu contains exactly what sort of commands/options you would expect.
• The main toolbar is a bit busier now. On the left are buttons for undo/redo (currently disabled because this feature isn't there). On the right are our eight different tools. The first four are the more basic/single tile tools, while the last four are for applying an operation to an area of tiles. Also the hotkeys for these tools are now 1-8, making it easier to than trying to remember "p for paint, s for swap, r for select, ..." etc.
• On the map view, you'll notice some areas have an orange tint. This is the "missing tile" overlay, which shows you where no tiles are painted for the selected layer (in this case, the ground layer).
• The blue tile areas show the area that the user has selected. As you can see, we can now easily make custom shape selection areas with the Shift and Ctrl key modifiers. The selection area doesn't have to be congruent either.
• The green area shows the paint-preview feature. We've selected this ground of tiles from the tileset, and the preview is showing where those tiles would go if the mouse was clicked at the current cursor location. Much easier to see what you're doing and figure out where things are going to go.
• The coordinates on the bottom tell you what tile is currently selected by the cursor as well as precise map coordinates (in units of the collision grid). I think this will be very useful for scripting to help determine the size of map zones and other objects.

i worked really hard on this so I hope you guys like the changes that I made. There's always going to be room for improvement in the future, of course.

[Roots]

Finished the video that demonstrates how to use the new editor. Here it is. This is the result of the past several months I put into working on the editor. Hope you enjoy it. I feel I did a better job this time in producing the video than my previous effort, partly because I used better software to record the video (Kazam) and used a video editor program this time (OpenShot).




I did forget to cover one major feature in this video, and that is that you can select an area of tiles and then right click to move or copy the selected tiles to a different tile layer or map context. Might make another short video for explaining how to use that feature later, because it's really damn handy.


Finally, I did discover a couple bugs in the process of filming this. When you drag and drop to reorder tile layers, the tile data gets screwed up (tiles start disappearing or moving around unexpectadly). I thought I had fixed this bug several weeks ago, but apparently not. The other bug is that when you reorder map contexts, the inheriting context ID number does not change like it should. Hope to find some time to fix these issues in the near future, but for now I just want to start using the editor to make some new maps.

[Roots]

I'm finding and fixing some minor bugs as I'm working with the editor to create the Harrvah capital map. The biggest problem I've noticed is that for large maps the editor will sometimes really slow to a crawl. I'm not sure why, but there's definitely a performance issue that needs to be addressed.


Also, I think that sometime in the future (probably not for this release), we need to consider using gzip or another compression library to wrap our map files. Currently the Harrvah Captial map is nearly 1MB, which is a really large file size. I don't want our game to take up 50MB worth of just maps for something as simple as a layered 2D map. Compiling the lua file for the map with luac made it twice as large for some reason. I'm not worried about this now, but maybe 2-3 releases down the road we will want to consider this.

[Roots]

Two issues with the editor I've noticed:

1) It seems that there are problems with having numbers in layer or context names. I wanted to create multiple interior contexts called "Interior1", etc., but that caused the editor to crash (I think). I'm going to look into this and fix it when I have a chance.

2) There's a performance issue with large maps, and I believe it's only when the tile grid is enabled. I'm not planning to fix this any time soon (since the workaround is obvious). A solution that might work would be to draw the grid once, save it in some sort of QImage, then just draw the QImage over the screen when the grid is enabled instead of re-drawing each line individually.


Other than that, I haven't run into any further issues with the editor from the past week of using it. It's working better than I had hoped for.