These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

EVE Technology Lab

 
  • Topic is locked indefinitely.
 

Devsite Blog: Aegis Sovereignty API changes

First post
Author
Previous Topic Next Topic
CCP Logibro
C C P
C C P Alliance
#1 - 2015-07-06 15:36:50 UTC  |  Edited by: CCP Phantom
With Aegis Sovereignty nearly upon us, CCP FoxFour takes us on a tour of what you can expect for the new API endpoints regarding the new system. You can find all the details here.

CCP Logibro // EVE Universe Community Team // Distributor of Nanites // Patron Saint of Logistics

@CCP_Logibro
CCP FoxFour
C C P
C C P Alliance
#2 - 2015-07-07 10:59:58 UTC
These changes are now live on Duality. A quick comment on campaigns. This has been an internal name and never mentioned publicly. For clarity it refers to reinforcement events. I would prefer that we, third-party devs and CCP, are communicating using the same terminology and these campaigns may in the future be used for more than just reinforcements. So when building your applications you may still want to refer to this as reinforcements to your end users.

https://public-crest-duality.testeveonline.com/sovereignty/campaigns/
https://public-crest-duality.testeveonline.com/sovereignty/structures/

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Crestor Markham
Sebiestor Tribe
Minmatar Republic
#3 - 2015-07-07 23:11:02 UTC
So I have one overwhelmingly big concern here: Does the API in fact expose all campaigns in New Eden?

If it does, then I think there is a huge problem, as somebody can write a super simple tool that provides a menu of all the possible fights to third party at any given time, as well as their (constellation) location. It devalues scouting (flying a ship into a system and looking for timers) and intel gathering (talk to your people to see if they know of any good timers coming up) by automating the process--and moving it completely out of game!

It also allows powerful alliances to know right where to go and when to be there to **** on smaller entities fighting for their corner of space. It seems to be acknowledged (by playerbase and tacitly by CCP) that powerful alliances can still project force a little too effectively across the map (cf wormhole connectivity changes just made).

I know my alliance has made decisions about what to field for timers based on who we thought knew about it. That answer will now be "literally everyone in eve" for every campaign. Can't roll the dice on a cap escalation, can't tailor your fleet to counter your opponent; gotta field a fleet to counter PL (or whoever else might have a WH leading to the next consto over)

I'm hearing that this info is available via the "show info" window, so you could technically do all of this from Jita using the map. That is brutal as well and needs to change, but at least it doesn't offer a (within the TOS) method of automatically checking every single system in sov null.

Exposing info on all campaigns in the API will substantially impair the goals of fozzie sov by hurting small entities' ability to fight for space. Please do not add this endpoint, and please get it removed from the show info window as well.
Powers Sa
#4 - 2015-07-08 17:47:11 UTC  |  Edited by: Powers Sa
Could someone explain to me in what universe you'd want to take away the fog of war by exposing every timer publicly via the api requiring no one to log in and check them?

You remove the reward for hard work and attention to detail done by the meticulous recon teams and fcs. You remove the burden of effort for hostile entities to crash the party, you take away the ability to invite the right friends when you create the right opportunities via stress, effort, attrition, espionage, etc. You remove a VERY powerful meta objective: Confusion.

A big part of the Reddit Bads vs CFC fountain war that yielded one of the biggest fights of all time was timer warfare and meta involving timers. Funky ihub timer creep issues from ccp and one side's ability to adapt and ensure their timer recon team could keep up while also messing with the org who managed the timers in the other entity ensured lots of leeway on forming up and not demoralizing our draw. I mean it was a really big part of it. Watching them stand down because they hurfed their ass off for a timer they didn't bother double checking was hilarious. Then watching them do it a few more times was just sadistic, but it worked.

Chaos in the fog of war is important, especially when you break up the objectives.

Help me out here?

Do you like winning t2 frigs and dictors for Dirt Cheap?https://eveninggames.net/register/ref/dQddmNgyLhFBqNJk

Remeber: Gambling addiction is no laughing matter unless you've lost a vast space fortune on the internet.
Crestor Markham
Sebiestor Tribe
Minmatar Republic
#5 - 2015-07-10 21:01:37 UTC
What say you, devs? I feel like even if I'm wrong, what I'm saying is cogent/plausible enough that it deserve a response telling me why my fears are overblown.
Commander Spurty
#6 - 2015-07-12 15:35:10 UTC
Killmails show where fights are happening as well, but also give who is there and what they are flying.

If your concern is really about letting people get 'information', then you are many years too late and a dollar short.

There are good ships,

And wood ships,

And ships that sail the sea

But the best ships are Spaceships

Built by CCP
Wollari
Dirt Nap Squad
#7 - 2015-07-14 00:14:33 UTC
There's a problem with the structures CREST API. Stations that are currently in a freeport mode event, are omitted in the structures listing. I understand that they're not counting towards to sovereignty and therefore are omitted.

But this confuses devs and maybe users that are looking into the structures and wondering where the station currently is. The main problem is tracking. When a structure is missing in the API, usually it's destroyed (IHUB/TCU) but this doesn't apply to the station. It's just has no owner.

Can't you just included the all the conquerable stations and just removed the owner (alliance) from the dataset like you removed the vulnerable* attributes in other cases?

DOTLAN EveMaps | Your out-of-game map, navigation toolset, sov database, etc. since 2008
Servanda
Liga Freier Terraner
Northern Coalition.
#8 - 2015-07-14 01:09:21 UTC
Wollari wrote:
There's a problem with the structures CREST API. Stations that are currently in a freeport mode event, are omitted in the structures listing. I understand that they're not counting towards to sovereignty and therefore are omitted.

But this confuses devs and maybe users that are looking into the structures and wondering where the station currently is. The main problem is tracking. When a structure is missing in the API, usually it's destroyed (IHUB/TCU) but this doesn't apply to the station. It's just has no owner.

Can't you just included the all the conquerable stations and just removed the owner (alliance) from the dataset like you removed the vulnerable* attributes in other cases?



It will show up as a Station freeport event in the campaign endpoint
Kali Izia
GoomWaffe
#9 - 2015-07-14 05:42:25 UTC
Wollari wrote:
There's a problem with the structures CREST API. Stations that are currently in a freeport mode event, are omitted in the structures listing. I understand that they're not counting towards to sovereignty and therefore are omitted.

But this confuses devs and maybe users that are looking into the structures and wondering where the station currently is. The main problem is tracking. When a structure is missing in the API, usually it's destroyed (IHUB/TCU) but this doesn't apply to the station. It's just has no owner.

Can't you just included the all the conquerable stations and just removed the owner (alliance) from the dataset like you removed the vulnerable* attributes in other cases?

It's a sov structure endpoint, so a structure that doesn't contribute to sov not showing up in it sounds like it's working by design.

The endpoint you're looking for is https://api.eveonline.com/Eve/ConquerableStationList.xml.aspx
Wollari
Dirt Nap Squad
#10 - 2015-07-14 19:55:58 UTC  |  Edited by: Wollari
Kali Izia wrote:
It's a sov structure endpoint, so a structure that doesn't contribute to sov not showing up in it sounds like it's working by design.

The endpoint you're looking for is https://api.eveonline.com/Eve/ConquerableStationList.xml.aspx

Thanks for pointing out where to look at ... didn't know that such a list exists.

Not counting to sovereignty is one thing ... but when open up the showInfo window of a system in "freeport" mode, you'll see that the station is still listed in the "sovereignty" tab including it's reinforcement timer .... according to your statement CCP should remove it there as well ... cause it's not a sov structure anymore ...

DOTLAN EveMaps | Your out-of-game map, navigation toolset, sov database, etc. since 2008
Wollari
Dirt Nap Squad
#11 - 2015-07-14 22:06:43 UTC
Quote:
vulnerableEndTime: The time at which the next or current vulnerability window ends. At the end of a vulnerability window the next window is recalculated and locked in along with the vulnerabilityOccupancyLevel. If the structure is not in 100% entosis control of the defender, it will go in to 'overtime' and stay vulnerable for as long as that situation persists. Only once the defenders have 100% entosis control and has the vulnerableEndTime passed does the vulnerability interval expire and a new one is calculated.


You don't go into overtime. Just tested on TQ. At the end of the vuln-window the tcu was at 50% control, but it did not went into overtime. Gameplay != Dev Blog Description

DOTLAN EveMaps | Your out-of-game map, navigation toolset, sov database, etc. since 2008
CCP FoxFour
C C P
C C P Alliance
#12 - 2015-07-16 07:43:10 UTC
Wollari wrote:
Quote:
vulnerableEndTime: The time at which the next or current vulnerability window ends. At the end of a vulnerability window the next window is recalculated and locked in along with the vulnerabilityOccupancyLevel. If the structure is not in 100% entosis control of the defender, it will go in to 'overtime' and stay vulnerable for as long as that situation persists. Only once the defenders have 100% entosis control and has the vulnerableEndTime passed does the vulnerability interval expire and a new one is calculated.


You don't go into overtime. Just tested on TQ. At the end of the vuln-window the tcu was at 50% control, but it did not went into overtime. Gameplay != Dev Blog Description


We are still unable to reproduce this and have tested it on TQ and it did work as expected. Can you let us know when and where this happened and if it happens again.

@CCP_FoxFour // Technical Designer // Team Tech Co

Third-party developer? Check out the official developers site for dev blogs, resources, and more.
Wollari
Dirt Nap Squad
#13 - 2015-07-17 12:11:02 UTC
CCP FoxFour wrote:
We are still unable to reproduce this and have tested it on TQ and it did work as expected. Can you let us know when and where this happened and if it happens again.

We tested it. We started before the end of the window of a vulnerable structure. After we run over the endtime, the cycle sucessfully finished it's work, but we were unable to continue. The structure was already invulnerable.

I think we completed at least one successfull entosis cycle (after the warmup) and were in our 2nd cycle. I don't know how the structure calculates it's next vul-timer if somebody is entosis it.

--

next topic: The sovereignty structures api doesn't provide the corporationID of the structure owning corp.

The Sovereignty XML API still contains the corporationID. If I want to replace the sov-xml-api fully with the crest result, I'm loosing the corporation information.

DOTLAN EveMaps | Your out-of-game map, navigation toolset, sov database, etc. since 2008