EVE Information Portal

@Sabriz: You can change your shortcut yourself in the "Esc" menu.

@Delegate Zero:

What I was doing pre-patch.

1- Activate the tracking camera.
2- Activate the "use tracking camera" in the D-scan window.
3- Go into the "Esc" menu and set my camera offset to 10% left
4- Select a celestial in the overview and press search with a 5 degree filter.

Result:

My ship appear slighty to the left in my screen. My target (Object tracked) is in the middle of my screen. When I hit d-scan with 5 degree search it work.

Post patch, either doing the same step or using the new "custom camera tracking" I cannot get the same result.

The only way post patch to get result with the 5 degree d-scan is to have your ship and the tracked target in the middle of my screen. (meaning my ship is obscuring the target...)

Hope it's a better explanation.

I sympathise entirely with Nelly and I am baffled that this situation could not be crystal-clear to you.

Like Nelly, and no doubt very many others, I have the tracking camera on at all times.

Previous to Rubicon 1.1 this is what I did in order to d-scan in the direction of a selected object:

1. Open scanning window and ensure that the tracking camera box was checked.
2. Click 'Scan'.
3. Close scanning window.

What I have to do now:

1. Click camera button.
2. Click 'Center Tracking Position'.
3. Open scanning window.
4. Click 'Scan'.
5. Close scanning window.
6. Click camera button.
7. Click 'Custom Tracking Position'.

Your blog is headed "Tracking Camera UI Improvements" but how this can possibly be construed as an "improvement" is beyond my imagination.

Much as I regret anyone being baffled by my responding to player reports of issues they believe they are experiencing with a request for clarification, I have to tell you that it's not going to stop me from trying to understand more precisely what is being described to me in any given report or post.

As it goes, Nelly's issue is significantly different to your issue. It also happens to be somewhat different to Seismic Stan's issue. So much is clear now they have both kindly clarified their issues.


I have news for Nelly which I'm afraid will not be welcome: I am familiar with the steps she described to achieve a slight offsetting of ship and target bracket using 10% camera offset with 5% scan. It was unfortunately a consequence of a defect in the relationship between camera and directional scanner. We have no plans at present to introduce some means of reproducing the effect by means of a feature.


For Seismic Stan: having looked into this matter of the ship possibly shifting, and lacking a video of it, I believe this is a consequence of zooming out. We removed a bound on zooming out with the tracking camera on. This has the consequence that when zoomed out beyond a certain level, the relative positions of the tracked object and ship on screen are maintained with reference to the custom tracking position set on the screen. This will have the effect of shifting the ship away from the centre of the screen 'towards' the custom position.


On the default key. We considered adding a modifier key to it but too many changes at once are sometimes quite unhelpful. The main complaint was always that there was no way to tell if tracking mode had been entered (by accident or not) while no object was selected. This we have addressed. If we need to do more, and we don't rule out changing the default shortcut key, we'll do so. It's a little bit of a double-edged sword - ease of toggling on is also ease of toggling off. We will see how the feedback goes there. Definitely something we will review.

Meanwhile, as has been pointed out, those who wish to alter the default can do so in the escape menu -> shortcuts -> navigation tab where it is listed as 'tracking camera: toggle point camera at selected object'.


Additional shortcuts for modes. We considered this as well. Again, it's the problem of changing too much at once. To be precise about it, the current shortcut is not for the custom position. It is for the tracking camera being on or off. It turns it on in the mode that was last selected. Yes, I recognise what this means for those who use the tracking camera in custom mode as their default camera mode in EVE - but it is important to be clear about what the controls actually do. Anyway, this is again something we can review.


Directional scanner link
I do think it is important to realize that the tracking camera as a whole was, in UI terms, in quite bad shape pre-Rubicon 1.1. We have to look at all use cases. Yes - both regular users of the tracking camera and those who only use it for d-scanning - are significant use cases. There are others. We needed to consolidate the controls. We needed, frankly speaking, to break the 'hard' link with the directional scanner because it produced quite undesirable effects and added to the problem of confusion in the overall control scheme.

Ideal solutions for everyone on the first pass? Not something I would claim. I think there is a lot to think about here and I don't want to casually make promises on changes without giving some thought to the issues raised. I can promise that they won't be ignored. I will be thinking about them.

I didn't say that I was baffled by your replying to Nelly's post - I said that I was (and remain) baffled that you didn't - and as far as I can see, still don't - understand the situation that Nelly, Samira and I are all trying to explain to you. And you are wrong - Nelly's issue is not significantly different from mine, the only slight difference is that I left my ship in its default position after selecting the tracking camera function. The fact that Nelly altered the ship's position relative to the tracked item is irrelevant - the selected item remained in the centre of the screen, which is what appears to determine the direction in which d-scan operates.

Please note Nelly's initial comments:
Let's get back to basics. Before Rubicon 1.1 there were two methods of aiming the d-scan:

1. Set the camera to look at your ship and then centre your ship over the object, thus placing both the ship and the target object in the centre of the screen.

Or

2. Turn on the tracking camera function and tell d-scan to use it for aiming. In this situation the object selected for the tracking camera was placed in the centre of the screen and d-scan looked in that direction irrespective of the position of the ship relative to it. I assume from this and the behaviour of the new system that the primary requirement is that the tracking camera's target should be in the centre of the screen.

What we are asking for is the return of method 2 but what you have given us is method 1 with no alternative. (Using the tracking camera now simply automates what is done manually in method 1).

I believe that you have approached the situation from the wrong angle. When setting the custom position the positions of both the ship and the tracked object are moved - this inevitably moves the tracked object away from the centre of the screen. What the system ought to do is move only the ship, leaving the tracked object in the centre of the screen. If my assumptions are correct, d-scan would then search in the desired direction without any resetting via the camera button.

I'm a sad panda then , hope you can change your view on that. I'm totally with Vila on that.



I could cope with a shortcut to switch between center tracking camera and custom tracking camera... but still meh...

We did.

Now, how about you dial back the comments and assumptions about what we did and/or didn't do, and our understanding of the issues, please? This kind of commentary adds absolutely nothing useful to the discussion.

There are several issues here and it does no good to anyone to conflate them. I'm concerned to tease apart the separable issues so they can be looked at sensibly. There are three main issues in the air at the moment:

1) The camera behaviour as reported by Seismic and illustrated in his fraps video.

2) The issue of the camera center offset, ship positioning, directional scanner and how they interact.

3) The issue of the usability flow when using the directional scanner with the tracking camera. This has two main use cases, among others, which are (i) tracking camera on and in custom position mode before and after using the directional scanner; (ii) tracking camera off before and after using the directional scanner.

Issue 1 - Camera behaviour as in fraps

We're looking into that particular issue and the circumstances where it presents itself. Will update when possible.

Issue 2 - Offsets, ship positions, d-scan

Let's get something very basic clear to everybody: the centre of the screen is completely irrelevant to the directional scanner.

This was so before and after Rubicon 1.1. As far as I am aware it has been the case since day one.

It remains true whether or not any camera offset has been set. It also remains true whether the tracking camera is on, and regardless of what mode the tracking camera is in.

The centre of the screen is a red herring when it comes to the directional scanner.

So what actually happens with the directional scanner?

First, the scanning cone originates from the centre of your ship.

Second, the vector of the scan is determined by the relative positions of the camera itself and the object it is set to look at (in the sense of the EVE 'look at' camera function - most of the time the object is your ship but of course it can be set to something else within a certain range) making the vector that line drawn from the camera position towards and through the object it is set to 'look at' - direction of camera 'view' is totally irrelevant here (this may sound bizarre but it's actually true, you can demonstrate it with some right mouse-button held down camera gymnastics, for one thing - thinking of the camera drones concept may help).

Third, for purposes of the directional scanner the above vector of the scan – in those cases where the object the camera is set to 'look at' is not your ship – is translated so that it runs through the centre of your ship. The scanning cone then takes its centre line and direction from that vector.

I know that given the terminology of EVE being a bit different to everyday usage and/or camera terminology in general there is plenty of scope for confusion. However, the main point here is that any ideas or interpretations that begin with the assumption that the centre of the screen is key to the functioning of the directional scanner are just going to be wrong.

Still and all, most of the time, these nuances don't really matter as the 'look at' tends to remain set on your ship when using the directional scanner. This can give a general illusion that the centre of the screen matters. It's very easy to arrange matters so that it is clear to see it doesn't actually figure in the matter. (Playing around with 'look at', narrow scan angles and trying to scan objects that are very close is probably the easiest way to see this yourselves.)

All this being the case, the centre of the screen is neither here nor there and there is no point to swapping around the behaviour of the custom position such that your ship is placed there and the tracked object stays in the centre. The essential problem would remain. The vector of the scan has to go through the center of the ship for purposes of the scanning cone.

Any situation previous to Rubicon 1.1 where this seemed not to be so is simply the result of a defect. Every time this has been reported as possible previous to Rubicon 1.1, it has involved small offsets and that's due to a defect. We've looked at this again on a reference build and what I have described is how the directional scanner and tracking camera tickbox option always were intended by design to work together - to line the target up with your ship (and camera position).

We really can't change this without changing the fundamentals of directional scanning. This is not planned.

Issue 3 - Usability

Our mandate was to improve the tracking camera UI and we had two main issues to deal with immediately. First and foremost, in a certain very common state you literally could not tell if the tracking camera was on or not. Second, the controls were in obscure places, not easily discoverable, and split between two totally different locations - Selected Item window and the directional scanner. Bearing in mind having to address those points, we looked at the options and how usability would be affected for all tracking camera users.

First thing to do was clearly to find a way to clearly provide feedback of the state of the tracking camera and consolidate the controls. We decided that the camera controls button was the way to address both needs. Then we looked at the directional scanner controlling the tracking camera and concluded this was undesirable. It's unnecessary for the use case of quickly lining up the ship with a tracked target and it introduced unnecessary confusion and some problems into the equation.

We did see that the use case of quickly lining up the ship with a tracked target for purposes of scanning should be facilitated. There are of course design arguments to be made that it shouldn't be done...

thx CCP Delegate Zero, I really love reading the nitty gritty details of design work :)
FWIW i find that the new tracking camera UI is perfect. The hinting provided by the box that flashes on the screen tells me that I turned it on or off, which was hard to tell pre-1.1. I always thought that the dscan window was a weird place to put a camera setting. And finally the increased speed makes it SIGNIFICANTLY less painful to scan celestials for targets.
-NJ

+1 support for Stan and Nelly's issues being genuine and legitimate. That video highlited some pretty bad math going on somewhere, and being able to d-scan from the custom position instead of while trying to see through my damned ship would be fabulous.

...and for goodness sakes, please stop adjusting zoom level when I change camera modes!

The tracking camera is still too slow on the next gate in a route.
It only behaves this way on the next gate, unless another item is tracked first and then the next gate is selected.
Please fix it so that the increased speed is on the next gate too.

I also sent a bug report about this.