CCP_Explorer

Please file a support request with customer support to get help on this issue.

According to the Avast Customer Care Team then this issue has been resolved. Please update your Avast or AVG software to the latest virus definition files.

If you have any issues restoring the EVE Launcher then please send us a technical support request, or file a technical support request with Avast or AVG, or consult the documentation with your antivirus product.

Hey @Kalbuir_Skirate: Can you confirm that you are still fetching this data? And if so, can you let us know when you are done?

Internally we got alerts on

• SkillHandler.GetAllSkills_External
• SkillHandler.GetSkillPoints_External
• SkillHandler.GetFreeSkillPoints_External
• SkillHandler.GetAttributes_External
• SkillHandler.GetImplants_External
• SkillHandler.GetRespecInfo_External
• charMgr.GetClones_External

and it looks like the corresponding external calls are

• eve.character.skill.GetLearnedSkillsRequest
• eve.character.skill.GetCharacterAttributesRequest
• eve.character.implant.GetActiveImplantsByCharacterRequest
• eve.character.clone.GetClonesByCharacterRequest

Please also note the ESI changelog here esi-issues/changelog.md at master · esi/esi-issues · GitHub

To confirm, the only change made today (after delays) was the removal of /v4/characters/
{character_id}.

To be clear, the root cause is not with chat. It did not, however, recover from another outage. There were other systems that did not properly recover as well but the most noticeable symptoms to players are issues with chat and to resolve them a reboot is needed.

This update includes bug fixes to Faction Warfare complex completion, to the new New Player Experience, and then we were updating our message bus ( RabbitMQ). That last part was potentially expected to last an hour but was complete in 20 minutes.

We didn’t want to underestimate how much time we might need. We could have been done in 6 minutes but I jumped between a couple of asteroid belts to make sure all was good, so it took 8 minutes.

At 15:00 EVE Time / UTC.

Indeed, and while unfortunate and we’re sorry that it happened, it exposed that that we can only fix such oversights with a downtime (it’s more specifically processing that only happens during server startup). That’s a valuable observation for us to fix our tools.

Hey @Daryl_Noban, can you send us a bug report about this issue, please, and post the EBR number here. We want to look at this in more detail.

Not seeing that in the online population numbers. Dotted line is comparison to last week:

image1369×637 66.3 KB

The regular asteroid belts only replenishing during downtime was a known issue going into this test. This is why we decided this morning, after a discussion since last night, to extend the test from 48 hours to 52 hours as we investigate some technical buildup we are seeing, rather than repeating the test later. Downtime is in 2 hours.

Thanks for the feedback; this type of test is impossible to do on the test servers. We don’t get the scale, randomness, and various edge cases in real player behavior there. We deeply appreciate your patience.

Thanks, located.

Thanks, located.

Yep, we already have a few bug reports and have verified what code behaviour is causing this.

What is the EBR number of the bug report?

I read the detailed bug report (thanks!) and in fact this new behaviour is what was always intended. With downtime then the dungeon needs to be respawned and since we don’t store detailed information on the state of the dungeon in the database, then we must respawn it from authored data, including the ore that has been mined. With no downtime, once you have mined the ore, the dungeon is just still there waiting for you to complete it.

Thanks, I’ve added these details to the defect for the team to review.