The, hoped for, Future of EVEMon

CCP destroyed a lot of software yesterday that was working but not supported in a professional way. Yes - I know this was announced an eternity ago. Still a big blow to the EVE ecosystem. They must have had some really good reasons not to keep the old system running. Can anybody tell me those reasons?

20-40% less db load. Sounds like a penetrating blow.

Yes, less app working so it’s normal.

But time passes and less and less content outside of the game, remain… That’s not for the better…

1 Like

I’m not a software or database engineer, but a major point of all this effort to move to ESI was to shift the demands of API users off the game servers and host them on virtual AWS servers which used a mirror of the database. A third less demand on the main game database sounds huge to me and probably will translate into better game play for all of us.

Yes, a bunch of third-part tools broke, never to be seen again. And a bunch more will break with the upcoming changes to killmails, so change doesn’t come without cost. I hope the right people have looked at this and decided it was worth it (and have every reason to believe they did), but sticking with an inefficient status quo that prevent new things from being added doesn’t appear to be a perfect choice either.

It’s a shame many developers didn’t make the deadline, but that is a reality of changes to standards like this, especially unpaid volunteers. They will move fast now, and while some things will be left behind, in 1-3 months there will be replacement tools for everything important and we will carry on as before.

1 Like

A “mirror” of the database? Documentation like “This route is cached for up to 300 seconds” suggests fairly recent data. It would be a live mirror then. And why can’t the old APIs use those new servers? Don’t tell me CCP did not have the manpower to migrate them when they demand everybody else to migrate.

Yes, some sort of live mirror as I understand it. Then the ESI functions are hosted on external servers to make the calls and serve the data.

I guess they could have, but it does seem reasonable to me to stop supporting three different APIs and just unify to one, and an industry standard one that should be easier to maintain at that. It would cost a non-zero, I don’t know how much but some, amount of developer time to re-implement the XML API in the cloud using this mirror. But yes, they could have.

XML was already partially broken and CCP seemed unable (or maybe just unwilling) to fix the problems that were accumulating there. I am sure they just wanted to wash their hands of it and go with something built properly from the ground up, and that didn’t have problems they would have to spend time fixing. Without speaking with them or peeking behind the curtain it is hard to second-guess the decision, but maybe you will find a clue in this round-table that was just posted and I haven’t listed to:

It’s not the API team, but perhaps they address the technical reasons behind the migration. Or maybe @Steve_Ronuken can provide some insight into the how the decision was made.

The XML API made direct calls to the Database. Which is why some things just weren’t possible. Game state that didn’t get persisted to the database, for example.

CREST had you make connections to the SOL nodes (which run the simulation) Which let it get at game state. But it acted as a second login for that user. Which caused some issues.

ESI has a whole other layer. You connect to ESI which sits (now. used to be google) in Amazon’s AWS. It has a communications channel for game data which can send requests to the Eve cluster (The Monolith), and get responses back. These are then chopped up appropriately, and sent to you. With a caching layer between you and the thing which makes the requests to the Monolith.

ESI doesn’t talk directly to the Eve Database, as that’s not live data. may be of some interest. It’s a little out of date now, due to the switch to AWS (it was accurate at the time. They were A/B testing) You want the slide titled “How ESI works now”


New fork and test pre-release

Cheers, mate!

Trying to get this all set up, but I don’t see any documentation on what to set the Callback URI to when I create my app on the EVE Developer website.

Russian lang instruction

Thanks Olbanets, works like a charm.

For anyone you can’t figure out the instructions:

  • go to
  • login and accept the conditions
  • click on manage application and then create application
  • enter a name and a description for the ‘application’ (e.g. MyEveMon)
  • select ‘Authentication & API Access’
  • in the permissions list on the left click everything until all rights are on the right side
  • enter the callback URI: http://localhost:4916/callback
  • create application and the click View application
  • copy the client id and the secret key (do not share them!! you are responsible for it)
  • enter them in EveMon (Tools -> option). Download the Pre-release EveMon from Olbanets Post above (atm it has 3.0.4 versionnumber which will change to 4.0)
  • select file -> manage api keys and switch to tab ESI keys
  • click add and then the Eve Link.
  • in Browser window login with you account and click authorize on the char you want to add.
  • close window go back to EveMon and click Import.
  • repeate that for all chars, if you have more accounts just click cancel instead of authoritze and you can relog in with another account.

I’m not sure if the final EveMon version will need your App ID or if the EveDevTeam will use a centralized EveMon ID encrypted in the application like it is meant to.

But still, EveMon is Alive again. All Hail to the DevTeam!!

1 Like

Thank you very much, the missing information was the port number.

Thanks again.

I just followed your instructions but once it was installed there was no ESI Tab.

I will try again late today when I have time. I must have downloaded the wrong file as it did not change to 4.0

Thanks for the guide.

Is there a way to use the new evemon without registering your own AppId? I will never understand why the silly restrictions that you need to have paid for your account.

1 Like

Its the nature of how oauth works and how ccp is implementing it. There are some other ways to do it but it would require evemon host their own keys on a server the developer pays for or do something like what jeveassets did which I think requires some cooperation with ccp to make a special exception or something else.

Right now I think its best that the development of evemon focuses on making it work better and down the road sort out a better way to handle the secret app keys.

As to the reasons you can look no further then CCPs legal team and the nature of how oauth works.

You’ve understood perfectly: OAuth 2.0 is a bad protocol.

and probably this thread is better continued on EVEMon 4.0.1 BETA - Under New Ownership - Conversion for ESI so we can let this one die quietly



ESI is completely useless for desktop tools.
I don’t understand, why nobody want to see it?