Similarly, being able to pattern probes with one click is a great improvement to the UI. Unfortunately, the two patterns we are given are not ideal; I'd prefer a more regular 8 probe pattern, and a flat pattern for hunting people. Ideally there should be user-determined patterns so we can each have what we want. However, at least it is clear that CCP is aware that what we have now in this respect is not ideal. They are working on it.
There was one change that I was expected, but which did not occur. And I don't know if they even know. (How can they not know? And yet: there it is.) That change is removing the ability to drag on the probe-movement arrow which is pointing primarily in the Z axis.
The Z axis is computer-programmer lingo for the depth "into" the screen (which, being 2D, you cannot actually show). Put another way, the Z axis is near to parallel with the direction of view. The "Z-axis arrow" is the one that points almost straight "up" out of the plane of your computer screen. Here's a picture:
Z-axis arrow, seen edge-on in the center. Image stolen from Penny. |
Adjusting probes by dragging on the square itself is superior to using the arrows; the arrows have their limited uses, but the "power prober" almost always searches faster by adjusting two dimensions at once. And yet, dead center in a UI element (the cube) that does one thing (planar adjustment) is a teensy tiny, almost invisible UI element (the edge-on Z arrow) that does something completely different -- and completely unwanted. But it is easy enough to hit accidentally that I still do it almost every time I scan down a system.
Is this broken? No. But is it annoying? Hell yes! It really does make we wonder if nobody at CCP who works on this code actually does exploration. I imagine them doing a very limited amount of exploration, where they only use the arrows to adjust things.
There are two fixes I think I'd be happy with.
One way to go would be to leave the UI drawn as it is, but make the arrows insensitive when they are sufficiently parallel to the Z axis. Ideally I'd like to be able to grab the cube instead (this is always what I am trying to do). But if it were simply a no-op, I could probably live with it.
The better way to deal with it is to not display the arrow when it is pointing mostly in Z. This is the better UI. To show a control element at all is to suggest it is there for a good reason and that it can be profitably interacted with. In this case, there is no good interaction with the arrow once it gets to an angle of perhaps 45 degrees or less with Z. So, stop drawing it then. (Indeed, if the "don't draw" angle were as large as 60 degrees I think that would be even better.)
I tend to drag using boxes, altering two dimensions at once, and this has been a problem for me for a while too. I've also noticed that if an erroneous z-axis drag is significant, the probes can now all become clustered in to one big ball, losing the formation you had. This is on top of them zipping off a few hundred AU out of the system. Maybe the pattern can be recovered, with the new pattern options, but it's still frustrating and takes time to correct.
ReplyDeleteI'm not sure about not drawing the arrows when they are barely visible. It seems the kind of change that would attract bug reports. But I really would like it if they weren't selectable when they are obviously in a position the player will never want to select them. There is a precedent for this type of change too. With Odyssey, the scanning patch notes (I believe, or it may have been a devblog) said that planets will no longer get in the way of grabbing probes.
If you remember, prior to Odyssey another issue was trying to reposition a probe that had its box over a planet. You'd select the planet instead. Personally, this wasn't as much of an issue because all of the probe boxes were visible by default too, and I could simply choose a different probe box. But the problem was fixed, and now selecting a probe takes precedence over selecting a planet.
Similarly, I suggest that selecting the probe box take precedence over selecting an arrow. Logically, this seems to solve the issue. If the arrow and box are coincident, then the arrow is not really in a position to be selected purposefully.
Maybe the same code that checks if a probe and planet are coincident can be modified or repurposed to do this similar check. If a mouse-click can select both an arrow and box simultaneously, ignore the arrow. No more will probes dash unexpectedly out of the system.