Macintosh

Before you continue:

I had an issue, but eventually decided to figure out what it was by myself. I have logged my progress in this thread. Scroll down for the conclusion.

I've recorded how to use the exploit and posted the video on youtube: https://www.youtube.com/watch?v=vfbz213d8Xk

The video takes some time. It's my first time I recorded something in my life, so I"m a bit unexperienced. Hopefully the process is clear.

---

Hey Guys,

I'm having an issue that seem to get worse. I'm not sure what caused it or how I can fix it. Everyghing takes a lot of time. Here's a list of the things that take a lot of time:

-(Un)docking
-Accepting and turning in a mission
-Jumping from one system to another (takes forever!)

For example: I press undock. The undock button shows "undock confirmed", but it takes 40 seconds before I'm outside of the station. Or I press "dock", Aura tells me "docking request accepted", but I won't show up in the station until after 40 seconds.

This is very annoying. The weird thing is that everything else goes smooth. I can fly/warp/shoot without a problem.

Anyone has this problem too or know how to fix this? Thanks in advance.

It's persisting.

I tried clearing the cache. Seemed to work for 1 or 2 jumps, but after that the problem was back. I'm now doing a clean install of the EVE client. I deleted both the game from "applications" as the map in the directory "/library/application support/EVE". Re-installing right now.

In the folder as specified above, there are 2 (or more) subfolders. One is called "settings" and one is called "cache" (and cache_backup#). I put back the corrupted "settings" folder into the clean install and the problem reappeared. I deleted the folder and the problem was gone again. I assume the problem is with the "settings" folder. To further clarify, this is my new suspect:

~/Library/Application Support/EVE Online/p_drive/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings

This sucks, because I'm not in the mood to reset my whole UI, overview settings and site bookmarks, so I'll dig a little deeper.

Inside the corrupted "settings" folder are the following files (where # is a string of numbers):
- a subfolder called "Browser"
-7 files named "core_char_#.dat"
-3 files named "core_user_#.dat"
-1 file named "core_public_.yaml"
-1 file named "prefs.ini"

Inside my clean install "settings' folder are the following files:
-2 files named "core_char_#.dat"
-2 files named "core_user_#.dat"
-1 file named "core_public_.yaml"
-1 file named "prefs.ini"

I think that the "core_char" files are part of the character you log in with (in this case Xasnevian), that the "core_user" file is part of the computer you log in with and that the rest are standard files. I'm going to replace 2 files from my corrupted "settings" folder to the clean install folder . One for my character (Xasnevian) named "core_char_976011440.dat" and one for the computer I'm currently using named "core_user_5420669.dat". How do I know that these files are the ones related to Xasnevian and my current comptuter? Because they appeared in the clean install folder, after I logged in. I'll add them one at a time to see what happens.

All 4 files don't evoke the problem. This is good for me, because I can now replace all files in the clean install, with files from my corrupted folder with the same name, without any problem and I don't loose any settings. But because the problem is still not located, I'll turn my eye to the files other than the 6 that appear in the clean install folder on a first login with this computer on Xasnevian, that are still in the corrupted folder.

I'm now going to make sure the problem is still recreatable, so I'll put the whole corrupted folder back.

Alright, this is weird. When I add the 6 files above individually, the problem doesn't appear. However, when I add both core_char_976011440.dat and core_user_5420669.dat at the same time, I do get the problem.

I'm now going to create two scenario's.

Scenario 1:
core_char_976011440.dat
+
core_char__.dat
core_public__.yaml
core_user__.dat
prefs.ini

Scenario 2:
core_user_5420669.dat
+
core_char__.dat
core_public__.yaml
core_user__.dat
prefs.ini

Let's see what happens.

Conclusion

The issue:
After the first jump to another system after a login on character Xasnevian, the following actions take approximately 40 seconds to complete:

Docking and undocking at a station

Accepting and turning in a mission

Jumping from one system to another

When logged out and logged back in OR before the first jump to another system, these actions complete instantaneously (except for jumping from one system to another system, as this is the trigger of the problem).

Possible exploit:
When I jump into another system (as described above), I actually appear 1.000.000km away from the gate I just jumped through. This can be used to avoid gatecamps.

Reproduction
Can I reproduce this issue? YES! But only on character Xasnevian and on my current computer.

My computer
I'm playing on a late 2012 iMac with OS X 10.8.4 Mountain Lion installed.

The process of narrowing down the problem
I saved the folder with my user settings located at the following location on my desktop:

~/Library/Application Support/EVE Online/p_drive/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility

I shall refer to this desktop folder with user settings as the "corrupted folder: c_program_files_ccp_eve_tranquility".

I deleted EVE Online from my computer by deleting the following directories:

Applications/EVE Online (Not sure if there's more prefix. This is the folder where you drag the EVE Online icon when you want to install)

~/Library/Application Support/EVE Online

I reinstalled EVE Online by downloading the Mac client from your website. I test in the following way if the problem does or does not appear:

Open launcher, log in and launch game

Log in on character Xasnevian

Undock from Bahromab VIII - Moon 6 - Republic Security Services Assembly Plant

Jump through stargate into system Kudi

Jump back through stargate into system Bahromab

Dock to Bahromab VIII - Moon 6 - Republic Security Services Assembly Plant

Logout

The problem did not reappear with the clean install.

When I put back "corrupted folder: c_program_files_ccp_eve_tranquility" into the clean installation, the problem reappeared.

I restored the folder and combined files included in "corrupted folder: c_program_files_ccp_eve_tranquility" to determine what the corrupted file is. I narrowed the problem down to the following 6 files in the following directory:

~/Library/Application Support/EVE Online/p_drive/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings

1: core_char_9760114400.dat | The file I believe corresponds to character Xasnevian

2: core_user_5420664.dat | The file I believe corresponds to my current computer

3: core_char__.dat

4: core_public__.dat

5: core_user__.dat

6: prefs.ini | These last four files get created by the client when I log in and they are not present in this folder so they are somehow related

I tested these six files in the following combinations with the following results, by deleting all files from the clean install folder on “~/Library/Application Support/EVE Online/p_drive/Local Settings/Application Data/CCP/EVE/c_program_files_ccp_eve_tranquility/settings” and copying the named files to this folder from the corrupted folder I put on my desktop:

1 3456 – No problem

2 3456 – No problem

12 3456 – Yes problem

3456 – No problem

1 – No problem

2 – No problem

12 – Yes problem

This led me to believe the problem occurs when file 1 and 2 are together. Somehow their interaction creates the problem. To be sure it is not one (1) or the other (2), I logged in on another character and on another computer.

Logging in on my alt
Be switching to my alt, the following swap takes place:

core_char_9760114400.dat

becomes

core_char_93413042.dat | The file I believe corresponds to my alt

This gives no problem.

Logging in on a different computer
Be switching to a different computer, the following swap takes place:

core_user_5420664.dat

becomes

core_char_5420669.dat | The file I believe corresponds to my secondary computer

This gives no problem.

Closing thoughts
I believe the interaction between file 1 and 2 somehow creates the exploit.

I have no idea how my files got corrupt, but I do hope CCP can figure out what’s wrong. If I have to reset my settings to fix this, so be it, but I couldn’t help but try to find the problem myself. I shall save my corrupted folder for now and maybe CCP can investigate it.

Kind regards,

Xasnevian

Same for me. As the part you said about the gate and avoiding gate camps, I have been avoiding possible gate camps and this is exploiting a few times; I can't stop myself doing this, so CCP needs to fix this asap.

I do hope CCP checks this issue and not leave it alone for months and eventually forgetting about it, this is becoming a bigger issue for me and I have almost lost +1B ISK ships recently due to this lag.

If I'm in the middle of space, and EVE Freezes for a minute then unfreezes, in that minute I can be tackled.

Fix this ASAP CCP.

Computer type:
OSX Version 10.6.8
Processor - 2.53 GHz Intel Core 2 Duo
Memory - 4 GB 1067 MHz DDR3

Just to let you know, as of today's downtime I don't seem to have the problem anymore. I'm not able to recreate it in the way shown on my youtube movie. Call Rollard, did your problem get fixed as well?

Edit: I spoke to soon. It's back. I did like 5 jumps and two missions and the problem returned. It's now 30 minutes after downtime.

Today I was actually able to run a couple of missions, but on a next login the problem returned. I also noticed a dev blog explaining that the old bug reporting system wasn't being used anymore, so I've filed two new bug reports. One from the website with the files attached to recreate the problem and one in-game that adds stuff about your computer and a screenshot.

X Fingers crossed they find anything! X

No, not yet. But give it some time. They're still updating their bug report system and Odyssey 1.1 is coming up. I'm hoping for 1.1 to magically fix the issue, but I'm sure that if that's not the case, they'll get to it.