With all the activity, I thought it may be appropriate to list editor “features” that I find troublesome and sometimes silly. I have not had a chance to check out 3.5 beta, so they might already been addressed, and for some, I don’t know if they appear in other architectures. I’m using windows 10.
Again, I’m only talking about GUI behavior here and not how they affect the model.
-
Maps. If I “add a map” to my module and scroll down to select “include toolbar button to show/hide?”, I am not allowed to enter in the button text, icon, or hotkey. It wants me to save and exit; then start the editor again, at which point I can enter the button information. Now there is a trick to get around this. Add a new map and check the “include toolbar button.” Next copy and paste this map window. If I now edit the copy, I CAN enter the button text, et. al. This fits in the silly category because there seems to be no reason why I can’t enter the button fields, especially if I can do it to a copy.
-
Grid numbering. I create a rectangular grid, and then I add grid numbering. If the grid’s cell height is around 250 pixels or more (not unreasonable), then the grid numbering window will have the “ok/cancel/help” buttons, which are at the bottom, disappeared off the bottom of my screen. I have to grab the window’s top edge, drag it down, and then pull up the window to expose the buttons.
-
Send to Location trait. This window has a “advanced options” checkbox. If I check it, it opens an in-place sub-window where I can specify additional offsets. (Note that for some reason, the “additional X offset” is blank while the others are set to zero.)
The massively annoying thing about this checkbox is the editor does not remember its state, so if I re-open this window later, the checkbox is unchecked. It is ALWAYS unchecked. One might think that this trait has no advanced options with an unchecked box, and one would be wrong. This has no business being a checkbox. If it’s going to operate this way, it should be a button.
But even more so, why is there a checkbox? Ditch the checkbox and simply put the “advanced” options inline where everyone can see them. The code has to be simpler than adding all this checkbox and sub-window nonsense. As you might guess, this one bugs the hell out of me. (I think there may be other “advanced” checkboxes elsewhere, and I think they should vanish too.)
-
Game piece layers. It’s a bit annoying that there are two “layer” elements, game piece layers and piece layers, but I’m not complaining about that. Suppose I define 3 layers: top, middle, and bottom. You would think they would be listed in vertical order as you would picture them: top, middle, bottom. But nooo. The window lists them upside down: bottom, middle, top. This one falls into the goofy category.
-
Trigger trait. In this window, there are scrollable lists for “watch keystrokes” and “perform keystrokes.” Each list has an “add” button, which adds a new blank line to the bottom of the list. This is harder to explain, but you can see a problem if you have 6 or more keystrokes in a list. The add button is in the scrollable region, so when you add enough lines, the add button scrolls off the top of the list. What I have to do then to add a keystroke then is I must scroll up to show the button, press it, and then scroll down to get to the new line, which was scrolled off the bottom. Really tedious. And if I want to insert a keystroke in the list, it’s too bad. I have to rebuild the list almost from scratch. I wish these lists used an un-goofy versions of the game piece layers component (see #4).
-
Coordinate systems. Most components define pixel location (0,0) at the center of the piece or region, but there are a couple that put it in the top left corner, and ± may mean different directions. (I don’t remember which components behave this way, but I’ve run into them.) I’m not talking much about this one because I don’t think it’s easy to fix and keep backward compatibility.
