EVE Technology Lab

With January 2016 we will see a large update to CREST bringing us new exciting features such as:

* Read and write of personal contacts
* Write of autopilot routes
* Updated alliance resources
* Dogma information

Get all the details in CCP FoxFour's latest blog CREST Updates For January 2016!

Happy New Year!

This writeable CREST stuff is rather exciting.

On the subject of waypoints, when we have citadels will we also be able to have waypoints and courier contracts to them? If one use case for citadels might be player market hubs, it seems rather desirable to be able to create waypoints or courier contracts that terminate at these hubs.

Just road it and it sounds awesome, i would like to thank you for the awesome work you do :) .

Will test the new futeres and Crest at all with the new patch and when my study starts (more time).

Kind Regards

Shegox

edit: if you work in this speed, maybe wallet transactions by summer 2016

sorry wrong comments /devblog

Hey FoxFour! Really cool with the contacts mutability exposure, looking forward to using that.

Any thoughts about opening the /corporations/* route to include alliance history information? As of right now it is impossible to programmatically determine whether a character was in an alliance/war with exposed APIs...

Writing autopilot routes looks exciting. Did reading autopilot waypoints already exist? I'd love to see dotlan show my current route on their maps.

Hey people,

So for the most part the deployment has gone OK. The POST resource for contacts goes live with downtime today and hopefully that goes as well as most of the rest of this release.

There is however a defect with the locations resource. I feel like explaining this, not sure why, probably because I know how much I would like reading this if I didn't work here. So here we go:

The way this resource currently works is when the incoming request lands on a proxy node service CREST we make a service call (service context vs character context, as in I haven't spun up a session on this proxy for the character, just using the CREST service session to make the MachoNet call) to the character node for the specified character.

On the character node I check to see if the specified character ID is in the sessions this node has in memory (sessions are essentially just stored in a python dictionary in memory) and if it is there I return the solar system.

Easy. Except to understand where this falls apart you need to understand a bit more of how sessions work. The only place that is guaranteed to have an up to date session is the proxy that created that session and where the session now lives. When a call from the client reaches that proxy the proxy makes the appropriate call to the backend and passes the session along with the call. The backend node receiving the call then stores that session in the dictionary I talked about before. If that backend node calls another node the session is propagated to whatever node it is calling as well. If a client disconnects for whatever reason the proxy it was connected to sends a notification to all nodes that the session should be cleared and it is removed from the in memory cache.

What this really means is that the character node we are calling potentially has a stale session and not the correct location information. When we started down this path we believed that there was enough network communication between the character node and other nodes along with the client that this would essentially always be up to date.

Initial testing showed that when a character jumped from one solar system to another that solar system would make a request to the character node, therefor propagating the updated session. The problem is however that it only seems to do this when you jump into a solar system for the first time. After that the information the solar system needs is cached by the solar system and not requested again. So when you jump back into a solar system after the first time that cross node call is not made. It also turns out that simply changing solar systems doesn't really make the client do any requests to the character node.

Whelp.

If you try out the location resource right now and the character being tracked is actually doing things than generally speaking this information will be correct. If however the pilot is just flying between systems, some of which they have visited, and isn't interacting with the client in any meaningful way than this is likely to be incorrect at times.

I am working on a solution to this, there are many including writing a service just to handle the location or just forcing the services that handle jumping to update the session on the character node, but do not have an ETA. I hope in the coming weeks but no promises.

I would still encourage developers to work towards integrating this functionality as it will be fixed. Getting this information correct and out via CREST is essential to us being able to nuke the IGB so you can be assured this will be fixed.

Anyways... that was my morning. Onto other stuff for a bit while I think.

Assuming you're using json_encode, try disable slash escaping by passing JSON_UNESCAPED_SLASHES
Reference: http://php.net/manual/en/function.json-encode.php

oh that looks, then like a problem on my side.

Here is the gist, i got the auth_code over the call form a js with Get Parameters.

Here is the gist from my code: https://gist.github.com/anonymous/cf83e6d04f84c49ca826

Edit: Found the problem, i forget to send a content-type Header. Thanks for testing it out though.

You are truly awesome!

Thank you very much.
The content-type was the problem, i fixed and now it works. Testing now for characters though :)

Otherwise i found not in the Read or Write is folders, is it able to post to folders ?