Player Features and Ideas Discussion

To be fair, I have no idea when they ninja'd it in. All I know is it made me very happy (as a heavy missile user). \o/

I am conflicted on these numbers. One side of me says that a ship with the advanced computers ours would have could easily and probably would provide such information so I say why not. The other side of me tends to agree with Iain Cariaba and the continual dumbing down of the game, thus eliminating another of the things left that clearly differentiate the good pilots from the great ones and setting server load argument aside that would be a bad thing so I say NO to this idea.

A few response to things posted.


Actually they do.
The CPU has to tell the memory and math portions of itself that they need to wake up and go to work.
While the actual math may be handled by the math co-processor portion of the chip the cpu still has a lot of work to do to make it all happen.


Ah actually it can be a technical behemouth.
Given 500 ships, 100 drones and say 50 other objects in space on your grid we have a lot of "simple" math going on.
1st we have the calculations for the ships themselves so 500 x 500 = 250,000
2nd now the drones relative to the ships 500 x 100 = 50,000
3rd now the drones relative to each other 100 x 100 = 10,000
4th the ships and drones relative to the other objects 600 x 50 = 30,000

At this point we have 340,000 math operations per second, as the informercials would say but wait there is more.
To the computer your formula is actually handled as 2 separate math operations the multiplication and the division so we need to account for that so
340,000 x 2 = 680,000
Add in all of the other situations where this calculation may be needed on the same server and you could easily add several million more math operations per second and taken all by themselves that could initiate TIDI. And I do not know about you but I hate TIDI and increasing the chance of it happening for a gee this would be neat idea gets a NO from me.

Some of you feel that this would not add to the server load because it could be handled client side and I wonder if that is really true?
Since the damage calculations are run server side does your client have the signature data for every object?
Does the client receive all the relevant data about the drones?
If not then handling this client side simply replaces the math load on the servers with the data processing load required to move all this information to the clients of every active player in the node.

Having gone through all of that CCP obviously has found a way to handle this without adding to much server overhead or they would not have brought it to your local test server. Either that or they need the data from the test servers to determine if the additional load can be handled by Tranquility.

All this talk is getting out of hand. All you need is one logical evaluation to see if the object is currently visible in the overview and a few trivial math operations by the client on values the server is already sending you.

If you're worried about performance, turn that column off.

I do however, recall from one of the Fanfest presentations that the overview code is particularly "legacy"... so that's the only real thing I could see holding it up.

Funnily enough it's not. Client does not get information on the sig size of your target. We can argue over if it should or shouldn't, but this would actually give you relative information as to sig size of your target.

The change they have on sisi doesn't even make checking tracking easier to do. If you want to get a ballpark on what you can and can't track you still need to adjust for sig res/rad differences (because most ships don't have a 40km sig radius).

I don't know if this is just me being "back in my day we had to learn tracking uphill both ways", but I don't think this change is needed because turret mechanics aren't that hard to understand.

I agree with this, but can "Evasion Score" be on the locket targets information box as well?

I really don't care to have my overview expanded any further then it needs to be, and really I only care about the enemies evasion score if I have them locked and I am trying to fire.

Also allow us to see Accuracy Score on the module hover over, so we can make quick good decisions.

I agree that the introduction of an "Evasion Score" would be helpful for giving the "Accuracy Score" something to directly compare to - and would finally, *finally* solve the problem that the "angular velocity" column on the overview is almost meaningless without taking the target's signature radius into account. As both values are already provided by the server to the client, and both can already be put on the overview, it'd just be cutting down on mental math required to determine "am I likely to hit this target?"

There's good difficulty, and there's bad difficulty. I don't feel like "do mental math quickly to multiply two overview columns" is a useful kind of difficulty to keep.

Why not boil it all down to a single number: % chance to hit displayed under the target icon when it is actively being shot at?

Since we are getting off-topic anyway, pipelining is not the only thing that influences processing speed.

Reading some whitepapers along the way, my cpu has 4 15 stage pipelines, does MADD, MUL and some other hardcoded math operations per cycle, actually several of them in one.

One of those calculations per cycle is completed so quickly that addressing the result in memory takes longer as riding from the US West Coast to the East Coast with a bike from the cpu's point of view.

In recent CPU architectures they have increased the speed a little and shortened the ways that result has to travel but from the CPU's point of view it's still slow.


Anyhow, that accuracy score leads the way to a stamina score for shields and armor, a mana storage capacity for cap and a dexterity score for ship speed and agility.

Next thing you know, we are picking up health potions at a moon.

OK guys I just crunched a whole lot of data from several sources. I ran 3 independent algorithms to verify my conclusions from different viewpoints. Here's what I came up with.

Bigger targets are easier to hit.
Smaller targets are harder to hit.
Fast targets are difficult to hit.
Slow targets are easier to hit.
Targets going around you are really hard to hit.
Targets moving toward you are the easiest to hit (more speed = better speed)
Targets moving away from you are also easy to hit (less speed = better speed)

Target painters help you.
Webs help you.
Tracking computers help you.
Signal amplifiers help you.

Sensor damps screw you (can't lock target) or help you (give you time to make tea while locking)

ECM Screw you.

New sensor boosters - didn't do the complex math on them yet, but the general feeling is they are good.


Your ship's speed helps you if you're moving toward or away from the target.
Your ship's speed doesn't help you if you're not.

There is a lot of deep (really deep) math behind this. To get the raw data - go to my website and download the stuff (63 page pdf and 16 spreadsheets).


Boiling this down further:

1. Hit approach
2. Apply point/scram
3. Apply webs and painters as available
4. Press fire
5. Cross fingers
6. Turn on reppers/call for reps/watch buffer melt away (as applicable)
7. Reload as necessary