Player Features and Ideas Discussion

Obviously you've never heard of reading comprehension.

Accuracy is why I suggested we include both in an updated d-scan, thereby providing flexibility. An AU slider provides your rough estimates, and the km based manual entry allows you to get your precision measurement.

I'd want to toggle between the both of them, sometimes KM is useful at short range. But we definitely need an AU option!

Needs more awesomesauce bumps.

The solution to this problem is simple. Consider these two simple truths:

1. The maximum range of the Directional Scanner is just under 15 AU.
2. Anything that is less than 15 Km away from you and isn't cloaked will show up on your overview.

With these things in mind, we arrive at a simple solution.

1. If the user enters a number that is less than 15, the D-Scanner should interpret it as a value measured in AU
2. If the user enters a number that is greater than or equal to 15, the D-Scanner should interpret it as a value measured in Km

The only potential problem with this solution would be that it would prevent players from dscanning at a range of less than 15km. If anyone can think of a situation where this would be a significant drawback, I'll be pleasantly surprised.

The Code
The beauty of this solution is that it requires nothing more complicated than an "if statement" to be added to the code. It doesn't need any new GUI elements or event handling. The code would look something like this:

if input < 15 {
input = input * 149597871;
}

This is a good idea, Maybe a toggle between kilometers and astronomical units so that people who got good under the current system can keep using their knowledge.

+1 for AU optionally input

CCP Karkur was actually asked about this directly during a stream. She more or less said "I'd rather see a whole new DScan tool created than to keep patching and tweaking the old one."

Should have been done years ago.

+1

I share her sentiment.

But I also, personally, fell into the trap of postponing quality of life improvements into 'the next big thing'. The latter suffering delays and feature creep until you eventually look back and say to yourself, "Man, I should've added that one small thing right away."

A very small change, outright requested, improving use of a frequented and consequential game mechanic for 40,000 players if only for 6 months to come? That's worth an hour wrangling the code in my books. And maybe even the three additional to jump through attached organizational hoops.


For me, the allure is in a very small change, and a large number of people affected by its positive fallout.

Small because all the existing can stay in place! The underlying scan code can still exclusively use the current km textfield's back-end as it does now. The scan button needs no changes, it'll kickoff a query to the km field as before and do its thing with that same value. Sole addition would be listening to focus-loss on both UI textfields, and convert-updating the respective other on this event, mimicking user input sans focus changes. And yes, it'd have to be inserted in the chain before the already in-place onValueChange auto-execute scan.

That's it.

Short of building a loop, I cannot see (right now, please correct me if wrong) how this could break anything functional because it doesn't touch on anything functional. As for the UI, I trust they have the experience to make it right first try. And even if something unexpected creeps in ("goto fail" anyone? ), it'll be a layout break, not functional.


(Disclaimer: I'm first to admit all the above as void the moment someone source privy points out "yeah, but more involved, done differently, historic code". Just if it isn't, let us have this change, pretty please with cherry on top. )

+1. This is a no-brainer.

In terms of scale KM means nothing on dscan. AU does.

Thanks OP. And as someone else said, "How has this not been suggested before?".