These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Player Features and Ideas Discussion

 
  • Topic is locked indefinitely.
 

The Toggle Trade-Off for Scanning

Author
Nikk Narrel
Moonlit Bonsai
#1 - 2014-11-20 16:08:58 UTC  |  Edited by: Nikk Narrel
First, let's specify that this is not simply about scanning alone.

It would affect other areas quite plainly.

This is my expectation of a trade off for self-repeating sensors, or d-scan as we often refer to it.

It would introduce a new toggle-based control option for d-scan, in addition to the single use scan button.
In this context, toggle means to change states in a persistent manner, rather than triggering for a one time event.
Specifically, it means having the sensors automatically rescan based on the existing settings for the d-scan.

This is to define how long it takes repeating sensors to automatically rescan, rather than needing to press the scan button each time.

The consideration that this is automated should be included, I believe, as this diminishes player error at the point of forgetting to trigger sensors to stay updated.
For that reason, I would recommend that existing d-scan options for manual triggering be left alone, to reward those willing to make the extra effort rather than have it done for them.
(similar to the logic that auto-pilot was less efficient in moving ships)

Basic Details:
Next, let's presume that it takes X amount of time to scan an area of space, comparable to the grid we see parsed in our overview of local contacts.

Now, we can use D-scan to control the area of space we scan in two ways.
We can use a cone, to limit scanning to one direction.
We can select the range, to set the distance and possibly signal strength.

At one end, we have simple on-grid awareness, which is instantaneous and constantly updated.
For each grid equivalent we add to this, sensor cycle time should increase.
The more grids we try to scan, the longer it should take to cycle.

Now, lets presume that we are scanning a full sphere, omnidirectional.
Add to this, we are setting the maximum possible range.
(I personally think each ship should have different range capabilities, but that may be another topic for another place)

The settings I just described should result in the longest possible cycle time for the sensors, to again repeat the task.

What amounts to a balance question, is what should be the time for this maximum scan?

1 minute? Perhaps 2?
Anhenka
The New Federation
Sigma Grindset
#2 - 2014-11-20 16:21:08 UTC  |  Edited by: Anhenka
The way you are phrasing this is rather ambiguous.

Are you proposing that D-scanning an area as large as the current possible area should take time?

What do you mean by "self-repeating sensors, or d-scan " since the last I knew d-scan was a manual action that in no way self repeated.

Will we be able to drastically increase the distance that we scan at in exchange for it taking time? If I want to d-scan a planet 200 au away on a 5 degree arc, would I be able to do that?

But if you proposal is that standard d-scanning should take any time, I'm going to have to ask you to take the idea somewhere with a lack of sunlight.

It's used in 95% of PvP, and a 1 minute delay or more would basically relegate it to complete uselessness unless you were an afk cloaker too lazy to warp around the system to actually check if there's someone ratting and would prefer to just scan the whole system with a 15 minute timer or w/e.

We really don't need more barriers on tools that help people get fights.
Nikk Narrel
Moonlit Bonsai
#3 - 2014-11-20 16:34:02 UTC
I did not expect the term 'toggle' to be seen as something unclear.

In this context, it means to change states in a persistent manner, rather than triggering for a one time event.
Specifically, it means having the sensors automatically rescan based on the existing settings for the d-scan.

This is to define how long it takes repeating sensors to automatically rescan, rather than needing to press the scan button each time.

The consideration that this is automated should be included, I believe, as this diminishes player error at the point of forgetting to trigger sensors to stay updated.
For that reason, I would recommend that existing d-scan options for manual triggering be left alone, to reward those willing to make the extra effort rather than have it done for them.
(similar to the logic that auto-pilot was less efficient in moving ships)
Kaerakh
Obscure Joke Implied
#4 - 2014-11-20 16:36:04 UTC
Nikk Narrel wrote:
I did not expect the term 'toggle' to be seen as something unclear.

In this context, it means to change states in a persistent manner, rather than triggering for a one time event.
Specifically, it means having the sensors automatically rescan based on the existing settings for the d-scan.

This is to define how long it takes repeating sensors to automatically rescan, rather than needing to press the scan button each time.

The consideration that this is automated should be included, I believe, as this diminishes player error at the point of forgetting to trigger sensors to stay updated.
For that reason, I would recommend that existing d-scan options for manual triggering be left alone, to reward those willing to make the extra effort rather than have it done for them.
(similar to the logic that auto-pilot was less efficient in moving ships)


I also missed that you said toggle, and I was under the impression this replaced dscan. You should probably underline those parts that say otherwise.
Nikk Narrel
Moonlit Bonsai
#5 - 2014-11-20 16:45:13 UTC
Kaerakh wrote:
Nikk Narrel wrote:
I did not expect the term 'toggle' to be seen as something unclear.

In this context, it means to change states in a persistent manner, rather than triggering for a one time event.
Specifically, it means having the sensors automatically rescan based on the existing settings for the d-scan.

This is to define how long it takes repeating sensors to automatically rescan, rather than needing to press the scan button each time.

The consideration that this is automated should be included, I believe, as this diminishes player error at the point of forgetting to trigger sensors to stay updated.
For that reason, I would recommend that existing d-scan options for manual triggering be left alone, to reward those willing to make the extra effort rather than have it done for them.
(similar to the logic that auto-pilot was less efficient in moving ships)


I also missed that you said toggle, and I was under the impression this replaced dscan. You should probably underline those parts that say otherwise.

Your point is well taken.

I apologize for any confusion, I sometimes have trouble explaining ideas because of simple details like that.
Switching gears between engineer and spokesman is a bit rough for me, lol.
Anhenka
The New Federation
Sigma Grindset
#6 - 2014-11-20 16:45:31 UTC
Sorry man, it's really hazy.

"The Toggle Trade-Off for Scanning" vs "Proposal: Automatic D-scan w/ time delay"

Which one is easier to understand? Hint: It's not the first.

Next, clearly outline your proposal in a way anyone can understand without fancy language. Include examples of mechanics and how they work. It's not F&I job to fill in the gaps in you ideas.

Ex. "I propose a d-scan option that repeatedly scans, returning a d-scan result with a delay that increases as the area being scanned increases"

Then explain why you think it's a good idea for the game. Optional but advised : Try to make it sound not self-serving

"I'm too damn lazy to keep D-scanning, and think that this would be a wonderful option to allow me to be more lazy while staying alert for people using probes"

Then fill in the small details. Is scan delay longer on a 360 degree scan compared to a 90 degree? What is the distance limits on the automation. Will this have a noticeable impact on server performance? What's the cycle time on the scans?
Can they be set to stop scanning when they find something in particular?


TLDR: Strip out all the fancy attempts to sound edumacated, spell your idea out in a way even an idiot can understand, and flesh out the smaller details. P.S. This idea is frequently beaten to death in "Remove Local" threads, and it never ends well for this idea.
Iain Cariaba
#7 - 2014-11-20 16:49:19 UTC  |  Edited by: Iain Cariaba
Nikk Narrel wrote:
...diminishes player error...

Those three words make this a bad idea. Player error is the cause of a vast majority of the content in this game.

I'm sure you've heard of the Battle of Asakai, it's only one of the largest battles in online gaming history. Remember what caused that? Player error, when a Titan pilot clicked jump instead of bridge. I could go on and on, providing examples of how player error is good for the game, if not necessarily for the player who made the error.
Nikk Narrel
Moonlit Bonsai
#8 - 2014-11-20 16:53:27 UTC
Anhenka wrote:
Sorry man, it's really hazy.

"The Toggle Trade-Off for Scanning" vs "Proposal: Automatic D-scan w/ time delay"

Which one is easier to understand? Hint: It's not the first.

Next, clearly outline your proposal in a way anyone can understand without fancy language. Include examples of mechanics and how they work. It's not F&I job to fill in the gaps in you ideas.

Ex. "I propose a d-scan option that repeatedly scans, returning a d-scan result with a delay that increases as the area being scanned increases"

Then explain why you think it's a good idea for the game. Optional but advised : Try to make it sound not self-serving

"I'm too damn lazy to keep D-scanning, and think that this would be a wonderful option to allow me to be more lazy while staying alert for people using probes"

Then fill in the small details. Is scan delay longer on a 360 degree scan compared to a 90 degree? What is the distance limits on the automation. Will this have a noticeable impact on server performance? What's the cycle time on the scans?
Can they be set to stop scanning when they find something in particular?


TLDR: Strip out all the fancy attempts to sound edumacated, spell your idea out in a way even an idiot can understand, and flesh out the smaller details. P.S. This idea is frequently beaten to death in "Remove Local" threads, and it never ends well for this idea.

I revised the OP just prior to this post.

I am hoping I did not use too much fancy language, your comments confirm issues I have communicating in regular life as well.

Embarrassingly, I am not trying to sound educated. My communication skills are simply flawed, owing to my difficulties in translating my ideas to terms most others can more readily absorb.
Ix Method
Doomheim
#9 - 2014-11-20 16:53:50 UTC
Anhenka wrote:
P.S. This idea is frequently beaten to death in "Remove Local" threads, and it never ends well for this idea.

True enough its oft repeated but has there ever been a genuinely convincing argument for or against it? People on both sides tend to wildly misrepresent clicking as 'eve is hard' or think they should have magic sensors that make everything warpable and auto-target ships before they land.

In the end you're either paying attention to your D-Scan or not, is there any extra value in having people spam-click it?

Travelling at the speed of love.

Nikk Narrel
Moonlit Bonsai
#10 - 2014-11-20 16:56:33 UTC
Iain Cariaba wrote:
Nikk Narrel wrote:
...diminishes player error...

Those three words make this a bad idea. Player error is the cause of a vast majority of the content in this game.

I'm sure you've heard of the Battle of Asakai, it's only one of the largest battles in online gaming history. Remember what caused that? Player error, when a Titan pilot clicked jump instead of bridge. I could go on and on, providing examples of how player error is good for the game, if not necessarily for the player who made the error.

I appreciate the concern, but in this case it is being balanced by the automation exacting a price in time for sensor updates to process.

In exchange for the player relying on the game to cover for them, like in my autopilot reference, the game handicaps them.
A player manually using d-scan will be faster, and better able to compete.
FT Diomedes
The Graduates
#11 - 2014-11-20 17:07:40 UTC  |  Edited by: FT Diomedes
Ix Method wrote:

In the end you're either paying attention to your D-Scan or not, is there any extra value in having people spam-click it?


This is the most important bit. Automating d-scan might well make people more complacent. In my mind, forcing people to spam click is a bad game mechanic. The player should be able to set the scanning interval, up to the current max. It then scans automatically when the window is active (not closed/minimized, nothing on top of it, etc).

CCP should add more NPC 0.0 space to open it up and liven things up: the Stepping Stones project.

Serendipity Lost
Repo Industries
#12 - 2014-11-20 17:11:13 UTC
The concept is cool, but the output would be used by bots to detect incoming ships and take action. Anything that will automatically change your overview data should be a no go.

Concept is cool, but it would become a botting tool. Sorry, but helping botters just isn't a good idea.
Nikk Narrel
Moonlit Bonsai
#13 - 2014-11-20 17:13:30 UTC
Thank you for being patient
Anhenka wrote:
...
Then fill in the small details. Is scan delay longer on a 360 degree scan compared to a 90 degree? What is the distance limits on the automation. Will this have a noticeable impact on server performance? What's the cycle time on the scans?
Can they be set to stop scanning when they find something in particular?

Grabbing just this section, for now, as it offered what I believe to be good questions to clarify:

The arc of the scan, as comparing a full omnidirectional sphere to a limited cone, is not the exclusive factor in this.

If you have a 180 degree angle scan, that is basically everything on one side of the ship, it can scan farther in the same amount of time than a full 360 degree scan could.

I am using the local grid like a unit of measurement here, trying to keep things relatable.
It takes X amount of time to scan 1,000 grids, regardless of how they are arranged.
If you only look in one direction, 1,000 grids extends much farther away than if you had them in every direction.

The cycle time on a maximum scan, maximum range combined with full sphere scanning, should define the longest possible cycle time.
The scanning time should scale based on the amount of space being scanned, down from this number in a linear manner.
(If you scan 3 grids instead of 6, it takes half the time)

As to the sensors reacting to a specific item, I am not pushing for that right now.
I am thinking it is getting ahead of ourselves, and may be too far in automating things.
Nikk Narrel
Moonlit Bonsai
#14 - 2014-11-20 17:16:55 UTC
Serendipity Lost wrote:
The concept is cool, but the output would be used by bots to detect incoming ships and take action. Anything that will automatically change your overview data should be a no go.

Concept is cool, but it would become a botting tool. Sorry, but helping botters just isn't a good idea.

CCP has stated in the past that we should avoid judging ideas in terms of whether they would help or hinder botting.

You may be right, and this might make botting easier. That is not my concern, and CCP effectively asked that others not focus on it as well.
Anhenka
The New Federation
Sigma Grindset
#15 - 2014-11-20 17:28:44 UTC
Btw, grids are not (why the hell do we call them grids anyway) some sort of static cubic area defined by certain distances. Grids are dynamically generated and altered based on the behaviors and locations of objects and players, along with when and where they moved.

Grids can be stretched out to thousands of kilometers, into weird shapes, or manipulated into tiny grids less than 50 km across.

As such they are not a good measurement for defining distances. It would be better to use the normal AU measurement when talking about scanning distance or scanned volume.

For those interested, here's a guide on just how ****** up grids can get and how they are generated/manipulated.

http://go-dl.eve-files.com/media/0912/gridfumanual2.pdf
Nikk Narrel
Moonlit Bonsai
#16 - 2014-11-20 17:57:14 UTC
Anhenka wrote:
Btw, grids are not (why the hell do we call them grids anyway) some sort of static cubic area defined by certain distances. Grids are dynamically generated and altered based on the behaviors and locations of objects and players, along with when and where they moved.

Grids can be stretched out to thousands of kilometers, into weird shapes, or manipulated into tiny grids less than 50 km across.

As such they are not a good measurement for defining distances. It would be better to use the normal AU measurement when talking about scanning distance or scanned volume.

For those interested, here's a guide on just how ****** up grids can get and how they are generated/manipulated.

http://go-dl.eve-files.com/media/0912/gridfumanual2.pdf

Oh, I agree on that point.

I am trying to define this in terms of the average perception of a grid in size.
I expect most players are generally familiar with that, even if it is undefined in genuine measurements.
I did my best to word it carefully, so as not to make the mistake of assuming grid size was standardized.

That stated, this is a relative term only used for comparisons against itself.
We already have the D-scan settings with hard numbers, and I have no wish to change those limits for the toggle version.
Serendipity Lost
Repo Industries
#17 - 2014-11-20 18:35:43 UTC
Nikk Narrel wrote:
Serendipity Lost wrote:
The concept is cool, but the output would be used by bots to detect incoming ships and take action. Anything that will automatically change your overview data should be a no go.

Concept is cool, but it would become a botting tool. Sorry, but helping botters just isn't a good idea.

CCP has stated in the past that we should avoid judging ideas in terms of whether they would help or hinder botting.

You may be right, and this might make botting easier. That is not my concern, and CCP effectively asked that others not focus on it as well.



I'm pretty sure as a sentient human being I can focus on whatever I like. I'm pretty sure CCP is aware that I am sentient. I'd also like to point out you posted this on a forum for discussion. I'm discussing my opinion.

NO because it will be a botting tool.

Also, link where CCP has asked that others not focus on possible botting buffs.
Kaerakh
Obscure Joke Implied
#18 - 2014-11-20 19:28:41 UTC
Serendipity Lost wrote:
Nikk Narrel wrote:
Serendipity Lost wrote:
The concept is cool, but the output would be used by bots to detect incoming ships and take action. Anything that will automatically change your overview data should be a no go.

Concept is cool, but it would become a botting tool. Sorry, but helping botters just isn't a good idea.

CCP has stated in the past that we should avoid judging ideas in terms of whether they would help or hinder botting.

You may be right, and this might make botting easier. That is not my concern, and CCP effectively asked that others not focus on it as well.



I'm pretty sure as a sentient human being I can focus on whatever I like. I'm pretty sure CCP is aware that I am sentient. I'd also like to point out you posted this on a forum for discussion. I'm discussing my opinion.

NO because it will be a botting tool.

Also, link where CCP has asked that others not focus on possible botting buffs.


There's really no reason to be upset, and he is correct in saying that we shouldn't focus on botting. Focusing on balancing around game exploits and other EULA illegal activities is unproductive and unnecessary. That's what CCP and the GM staff are there for.

An analogous example would be comparing this to T2 BPOs. They exist, but they're an outlier exception to the rule and gameplay is not designed around them and nor should it.