Bunch of suggestions


I’m basing my suggestions on practical uses, because I had my own tilemap editor, 20 years ago (made for 2 games, like https://youtu.be/49w1T0tqIjg). While it was DOS-based (thus a very sucky UI) and was nowhere near as featured (no objects layer), there are things that I can’t find in this editor, so here are my suggestions:

-copy/paste through all layers, I’m sure it has already been suggested (or it’s there and I couldn’t find it). Even object layers actually, because when working on large maps, it’s common to insert room & shift the rest of the map around.
Another way of inserting room would be commands to shift (in my editor it was shift+arrows, I think) all layers within the selection.
I understand that it wouldn’t be easy to make paste work through all layers because it triggers the stamp tool (which is mono-layer), but a simple way would be that paste pastes the content straight in the current selection (even cropping it). So you’d select, “copy all layers”, select again, and “paste”.

-full-screen editing. A basic form would be F11 to temporarily hide the gutters, leaving the side panels (tiles, etc).
A better form would be real full-screen, with right-click invoking tile selection, fullscreen as well.
That’s how my editor worked, and finding tiles in a screen filled of them was very quick. Scrolling the map was done by hitting the screen’s edges, that was quick too. But here middle-click panning works fine.
This said, maybe I should start working with multiple monitors.

Some more suggestions:

-middle-click panning working in the tileset window as well (right now it seems not to be doing anything but selecting, unless I missed something)

-a quicker way to delete or select without changing tools. Like, the common ctrl+click to start a selection. And Del to delete the tile under the cursor if there is no selection, or better, one of the extra 2 mouse buttons.
Talking about selection, it feels a bit weird that it snaps the coordinates in rounding mode instead of truncation. It feels more intuitive to hit the tile you start from, but often you’re a little above the tile’s center and it’s the next one that you select. I can understand this making more sense in isometric mode, though.

-as I suggested here http://forum.mapeditor.org/t/trying-to-understand-automapping/1259/2, a way to make automapping a lot easier (or even usable for me) would be to first save a temp copy of all layers before applying it, and allowing the rules to access it through something like “OriginalInput_LayerName / OriginalInputNot_LayerName”.
As explained in the thread, feedback in the processing is a nice feature but also a problem, when checking surrounding tiles that just have been changed by the previous rule step, and could then have been turned into a lot of different tiles.
That same copy could also be used to restore the original map in areas outside the selection, as right now automapping applies to the whole map, which can be destructive in zones where you’ve already applied it & have refined the results manually.
Also, it would be even better if “Input_” & “Output”_ without any layer name appended, would apply to the selected layer.

-a quick optimization that would (only within the selection, & disregarding hidden layers) remove any tile that’s masked by a fully opaque tile in a layer above it. The reason it’s better done at design time than by code when loading the map, is that if you have dynamic zones in the map, tiles under opaque ones may end up being revealed.

-the fact that all layers have the same size doesn’t make them very suitable for parallaxes. Parallax layers as their own map is ok, but it’s a bit hard for layers that are close to the front one and their content is related to it. I have no real solution here, though, as it would require introducing new concepts. And parallax layers don’t necessarily share the same tilesets anyway.

You are right with your analysis that it’s a tricky issue. It has been requested many times before and here’s also my answer as to what makes this complicated (pretty much the reason you’ve already stated).

I’m not sure if I like your suggestion to have the user first select some area and then paste should paste into this selection, but it’s something to consider. I personally think we need a “floating” mode after pasting as seen in most image editors, but also there this usually works on a single layer only.

Yeah, that’s definitely something I’d like to add as well. For making any of the views still quickly accessible, I think they could just be assigned shortcuts.

You’re the 4th to ask, so this is definitely something I should look into soon.

That’s an interesting suggestion, though unfortunately Ctrl is already used by most tools for other stuff. Delete could delete the hovered tile or object, in case of no current selection. Will have to try how that feels.

I did it that way because it’s how the GIMP image editor works. The idea is that simply clicking should clear the selection, and not select the tile below the cursor. Because otherwise it’s hard to get rid of your selection. But you’re not the first to dislike the current behavior, so maybe I should reconsider this.

This is definitely an interesting optimization, but indeed also one you have to be careful with. You’re already mentioning hiding layers or applying it only to the selection. So it’s clear that there is no one-size-fits-all for this kind of thing and I would rather spend time making Tiled scriptable so that such a thing could be easily added as an example script that can be tweaked as needed.

See issues #149, #1071 and #1181. :slight_smile:

I can’t say much about the automapping topic, since this was coded by @stefanbeller and I’m not intimately familiar with the code. What I would like to do there eventually, is to make live automapping integrate better with the undo commands, and also possibly making Tiled scriptable would allow much of the logic to be moved into scripts where it can be more easily tweaked as needed.

Thanks for all the suggestions! It definitely helps hearing what people care about, even if there are sometimes already issues open about it. It gives me a better idea of what things to work on next.

If you kept the original state and operated on that, it may be easier indeed to understand what is going on.

Back in the day I thought it was a feature to continuously operate on the data without having intermediate safe stepping points. If you wanted to have the rules not influencing each other you would have a layer which would not be affected by the outputs at all. (say a “planning” layer to be deleted on the final map).

It doesn’t apply to the whole map but only at places where the input layer (i.e. read planning layer, as that’s how I used it), had tiles. So you draw up a plan for a part of the map and experiment. Once you’re satisfied with the basic automapped layout you’d delete that part in the planning layer and do the fine tuning manually by placing special tiles or such.

If you wanted to have the rules not influencing each other you would
have a layer which would not be affected by the outputs at all. (say a
"planning" layer to be deleted on the final map).

Yep that’s what I tried to do, but it doesn’t work either, I suspect a bug there. As explained in my other thread, even the existence of a second input layer breaks the logic, even if it’s empty (or maybe, because it’s empty).
Perhaps the engine didn’t expect me to check both the source & destination layers (for some steps [like, checking if a block has surroundings] it’s easier to check the source layer, for other steps [like, completing corners] it’s easier to check the destination layer.

What about shifting then? Duplicating big map areas isn’t that common, but as I wrote, what’s common is to have to insert room in the middle of a large map. Shifting within a selection would only be tricky for objects, as you’d have to decide which object “is” inside the selection (either fully or partially).

I see, when selecting you use shift to append to the selection (quite standard), and ctrl to remove from the selection. That’s too bad considering ctrl is like the universal key to select. But alt would be fine too.

But snapping in truncation mode doesn’t prevent easy de-selection, it could just start selecting after you’ve moved the mouse by one or 2 pixels.

Yeah scripts would be nice, as long as they allow access to tile properties (but for this case, the script would also have to be able to tell whether a tile is fully solid or not).
In fact, scripts would also make automapping easier to re-use, as you would assign automapping logic properties to tiles & different tiles would be able to re-use the same logic.