Local chat delay in K-space (intelligent lore compatible idea)

Yep, yep you did, or you wouldn’t have been telling someone else that they should credit ‘you’ with the idea, instead you would have been crediting someone else.
So… Yeah, you made it sound as if you were the first to suggest it. And your ragepost response makes it pretty clear that you don’t like being called out for your lies.

1 Like

Alright, let’s set things straight here. While it’s true that people may have suggested a delayed local in the past, my shallow web search found exactly 2 topics regarding this (one of which is this very thread here). So obviously it’s not something that’s on alot of peoples mind, no matter what you want me or others to believe. In fact, I’m playing EVE for 8 years now and I never heared anyone meantion or saw anyone write about a delayed local chat in the way I suggested ever, or any way really. Getting rid of local all together? Yes, plenty of times.
So the fact that OP suggests the very same thing in the exact same way, just wrapped in a different bow, only 2 days after my post suggests to me that he took my idea and ran with it. Therefor asking for credit where credit is due is hardly unreasonable. And yes, the way I suggested it makes it my idea, even if delayed local per se is obviously not.

“Ragepost”? Pfff. Stop projecting.

Search conditions. “Delayed Local”

For just a small sample. You clearly didn’t even do the shallowest search, or pay the slightest attention to the forums.

1 Like

But what makes a d-scan bot’s input more detectable than any other bot’s input? If CCP can’t stop all of the other bots out there, all of them making similar client inputs, then what is the purpose of leaving d-scan dysfunctional for legitimate players?

Server loading. Large distance formula pulls for multiple items aren’t something python handles well, so either d-scan range would need to decrease significantly for automated versions, or the period would need to be a fairly long, making it less than useful.

Or you see a hundred people open it in jita and boom, tidi.

But the current d-scan can already be spammed and often is. Allowing auto-repeat doesn’t increase the server load because it doesn’t (meaningfully) increase the rate of scans, it just allows the current rate to be done without excessive button presses.

If automated, how many more people will have it set to max range, max frequency and just leave it open 23/7?

Not many given the fact that running d-scan at maximum refresh rate is pretty much mandatory everywhere outside of highsec, and d-scan is of very limited value in highsec.

Quick reminder to everyone that this is not about automating frickin D-scan, to me it’s fine as it is, get good and press your d-scan button. Can we get back on topic?

Sure. The idea is unoriginal, one of the worse implementations of the concept, and should be yeeted on grounds of open thread with functionally identical proposal.

This is on topic,
If you want a delayed local, Deep Scan has to be automated for balance. Otherwise you are handing a ludicrous advantage to all hunters.

Player input will show Deep Scan interruptions when other actions are performed, bots will not,
If someone has deep scan happening on 3 accounts cloaked at gates while their 4th is also performing combat actions… it’s very unlikely to be a legitimate player because of the number of actions per second required.
These are tells which CCP can use to follow up on buts currently that automating would remove.
I mean, I do want automated Dscan, I think the lack of it is silly, but I can also see where in it’s current form it would cause a whole lot of other issues.

If at least you would have read the posts you just linked and compared them to what I’m suggesting (and the OP, I guess) you’d have realized that those aren’t even close to being the same.

Nice try though. Better luck next time.

All 3 of the linked posts are the same exact base concept, and the fine details of this particular post are neither novel enough to be significantly different, nor is their a clear reason for this to be implemented in this manner. Especially as the implementation isn’t even expressed as a formula.

120-(60*(1+[sec status as decimal]) seconds isn’t hard to write, is far clearer on the actual output, and lets people play around with it.

This gives the same results, as displayed in the chart below.

sec status Seconds delayed
1 0
0.9 6
0.8 12
0.7 18
0.6 24
0.5 30
0.4 36
0.3 42
0.2 48
0.1 54
0 60
-0.1 66
-0.2 72
-0.3 78
-0.4 84
-0.5 90
-0.6 96
-0.7 102
-0.8 108
-0.9 114
-1 120

Just like a olympic pool and a wave pool in a water park are “the same exact base concept, and the fine details […] are neither novel enough to be significantly different […]”, right. Dear lord. :roll_eyes:

Talk about a poorly thought out idea.



well it is my own, only after it was yours… you know some people can think about the same things. I’ve only been playing for a year, so it’s probably logical that people thought about this in the 17 years life span of the game lol. I just have no way to know without doing a search in the deep corners of this forum for older threads which i didn’t feel was necessary.

I would be ok with this so long a can have radar that constantly scans automatically and shows my ship in a 3d bubble and anything that shows I could see what direction it’s in.
I would want to be able to filter out noise like npcs but it could show stations so I can see what direction a possible threat is coming from. I would also want a list of ships found to be generated somewhere so I could see what ships my radar has found and how far away they are from me.

You want to take local away then I want something in return.
The only people that would want this are the gankers and griefers that would stand to gain from local being taken away.

Separating by security isn’t lore compatible lmao.

I have a better idea. Gate cloak hides local from the entrant as well as the entrant from the inhabitants. Going to make my own post.

Been suggested and killed before, use the thread provided.

@ISD_Bubblemoon Cleanup Isle 9.