Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 30 .. 30 :: one page |
|
Author |
Thread Statistics | Show CCP posts - 184 post(s) |
ItsmeHcK1
Kicked. Shadow Cartel
110
|
Posted - 2014.05.23 16:01:00 -
[421] - Quote
Yup, it seems all is well in the world. Any idea on a timeframe for these to hit TQ? |
|
CCP FoxFour
C C P C C P Alliance
3245
|
Posted - 2014.05.23 16:07:00 -
[422] - Quote
ItsmeHcK1 wrote:Yup, it seems all is well in the world. Any idea on a timeframe for these to hit TQ?
Kronos is the plan assuming someone doesn't point out a giant flaw with it all. :) CCP FoxFour // Game Designer // @regnerba
|
|
DoToo Foo
Weaponised FuGu
23
|
Posted - 2014.05.23 16:17:00 -
[423] - Quote
@ItsmeHcK1 : Regarding item id & location. Yes, I want to get my head around this. That looks like what I want, just not there yet.
@CCP FoxFour; Definitely better. I could do some systematic testing on Sisi to ensure that the correct data is coming through for different POCO's, but that will have to wait for a time not involving me falling asleep at keyboard. |
|
CCP FoxFour
C C P C C P Alliance
3245
|
Posted - 2014.05.23 16:21:00 -
[424] - Quote
ItsmeHcK1 wrote:Yup, it seems all is well in the world. Any idea on a timeframe for these to hit TQ?
[edit] For those interested, the planet the poco is on is actually contained in the name. (Available through Locations) (row itemID="xxxxx" itemName="Customs Office (Jita III)" x="x" y="y" z="z"/) (Imagine these are the right brackets.)
Oh ****... I didn't even think of that. HAHAHA! That makes it a bit easier since thats a eve system provided name and not one you can set. CCP FoxFour // Game Designer // @regnerba
|
|
Steve Ronuken
Fuzzwork Enterprises Vote Steve Ronuken for CSM
3318
|
Posted - 2014.05.23 16:25:00 -
[425] - Quote
ItsmeHcK1 wrote:Yup, it seems all is well in the world. Any idea on a timeframe for these to hit TQ?
[edit] For those interested, the planet the poco is on is actually contained in the name. (Available through Locations) (row itemID="xxxxx" itemName="Customs Office (Jita III)" x="x" y="y" z="z"/) (Imagine these are the right brackets.)
And as long as you trust me:
https://www.fuzzwork.co.uk/tools/api-map-data/
Has an api on it for working out the closest celestial.
select (pow(:x-x,2)+pow(:y-y,2)+pow(:z-z,2)) distance,itemName,itemID,typeID from mapDenormalize where solarsystemid=:solarsystemid order by distance asc limit 1
Is the heart of it. Woo! CSM 9! http://fuzzwork.enterprises/ Twitter: @fuzzysteve on Twitter |
ItsmeHcK1
Kicked. Shadow Cartel
111
|
Posted - 2014.05.24 02:03:00 -
[426] - Quote
Steve Ronuken wrote:select (pow(:x-x,2)+pow(:y-y,2)+pow(:z-z,2)) distance,itemName,itemID,typeID from mapDenormalize where solarsystemid=:solarsystemid order by distance asc limit 1 That is a very sexy query. I'll keep that as back-up in case the string parsing thing ever stops working. (I mean why abuse my own database when CCP already gives me the answer, amirite?) |
Llyona
Lazerhawks
46
|
Posted - 2014.05.24 22:22:00 -
[427] - Quote
Ab'del Abu wrote:Erica Dusette wrote:There are arguments in the other direction too, sure, but I'm confident if you took a physical poll you'd see the vast majority would be against the change.
If only forum activity mirrored wh population ...
It would be possible to have an in-game poll. I actually like this idea, as it allows a poll across the main userbase, rather than the vocal minority that frequent the forum. EVE is an illness, for which there is no cure. |
|
CCP FoxFour
C C P C C P Alliance
3250
|
Posted - 2014.05.26 15:58:00 -
[428] - Quote
There are some new things deployed to Sisi today for testing (release date TBA):
CCP FoxFour // Game Designer // @regnerba
|
|
Max Kolonko
High Voltage Industries Ash Alliance
416
|
Posted - 2014.05.26 16:53:00 -
[429] - Quote
CCP FoxFour wrote:There are some new things deployed to Sisi today for testing (release date TBA):
Any ways to limit the query to specific Corp/Alliance/Timeframe? Read and support: Don't mess with OUR WH's What is Your stance on WH stuff? |
|
CCP FoxFour
C C P C C P Alliance
3250
|
Posted - 2014.05.26 16:59:00 -
[430] - Quote
Max Kolonko wrote:CCP FoxFour wrote:There are some new things deployed to Sisi today for testing (release date TBA): Any ways to limit the query to specific Corp/Alliance/Timeframe?
No not at this time. At a later time once you guys have access to the corporation resources that will list their wars. No plans for anything time based. CCP FoxFour // Game Designer // @regnerba
|
|
|
Leebe
Aurora Armaments The Bastion
0
|
Posted - 2014.05.26 17:03:00 -
[431] - Quote
CCP FoxFour wrote:There are some new things deployed to Sisi today for testing (release date TBA):
Hmm.. looks very interesting .. but the overview link is just the id, so it's not really meaningfull. Maybe it would be possible to at least add the main parties to better help deciding if I'm interested to fetch the details ?
And will there be some kind of cache header we should obey ? |
|
CCP FoxFour
C C P C C P Alliance
3250
|
Posted - 2014.05.26 17:10:00 -
[432] - Quote
Leebe wrote:CCP FoxFour wrote:There are some new things deployed to Sisi today for testing (release date TBA): Hmm.. looks very interesting .. but the overview link is just the id, so it's not really meaningfull. Maybe it would be possible to at least add the main parties to better help deciding if I'm interested to fetch the details ? And will there be some kind of cache header we should obey ?
All CREST calls have a cache header, please obey it.
This resource is for those interested in wars. Not a specific corporations wars. Later once you guys have access to the corporation resource on CREST there will be a link to that corporations wars. This is all wars. CCP FoxFour // Game Designer // @regnerba
|
|
ItsmeHcK1
Kicked. Shadow Cartel
111
|
Posted - 2014.05.27 21:30:00 -
[433] - Quote
Will all the API changes be listed in the patch notes? I ask mainly because I am a lazy bastard. |
|
CCP FoxFour
C C P C C P Alliance
3252
|
Posted - 2014.05.28 09:06:00 -
[434] - Quote
ItsmeHcK1 wrote:Will all the API changes be listed in the patch notes? I ask mainly because I am a lazy bastard.
No. Watch this thread or specifically this post from this thread: https://forums.eveonline.com/default.aspx?g=posts&m=4384137#post4384137
I also will announce this stuff on my twitter and generally r/EVETech if you prefer to monitor those places.
The reason for this is because the API and CREST will very likely be deployed separately from the EVE server. Kronos goes out on Tuesday, the API and CREST will probably go out on Wednesday, but maybe Tuesday depending how things go, but mainly I am just not 100% sure.
Sorry! CCP FoxFour // Game Designer // @regnerba
|
|
Sentenced 1989
Quantum Anomaly Corporation
57
|
Posted - 2014.05.28 15:46:00 -
[435] - Quote
http://public-crest.eveonline.com/incursions/
How often is this updated
Atm there is new incursion up, spawned about 35 minutes. On crest it shows up every few minutes, stays on for 2-5 minutes then goes down for 2-5 minutes, then shows up again, etc
Can we get some clarification if its supposed to do that, or how long till it gets there and stays there after spawn, etc?
Regarding cache, where can I see how long the cache is for incursions?
|
|
CCP FoxFour
C C P C C P Alliance
3252
|
Posted - 2014.05.28 15:55:00 -
[436] - Quote
Sentenced 1989 wrote:http://public-crest.eveonline.com/incursions/
How often is this updated
Atm there is new incursion up, spawned about 35 minutes. On crest it shows up every few minutes, stays on for 2-5 minutes then goes down for 2-5 minutes, then shows up again, etc
Can we get some clarification if its supposed to do that, or how long till it gets there and stays there after spawn, etc?
Regarding cache, where can I see how long the cache is for incursions?
The cache time for that endpoint is 1 hour. 3600 second. You can see it in the headers as: Cache-Control GåÆpublic, max-age=3600
There really is no way for it to change every few minutes, that cache is on the nginx box. The server only gets asked once every hour. CCP FoxFour // Game Designer // @regnerba
|
|
Aquila Sagitta
Blue-Fire
312
|
Posted - 2014.05.28 16:42:00 -
[437] - Quote
============================================ Idea: Allow us to send isk via corp or personal wallet Description: I'm currently building tools for my wh based corp and I'd love it if you could send isk with one click instead of having to go to wallet, go to corp wallet, transfer isk, find the person your paying, double check its the right person, type in amount, and then pay them. When you have to do this with 10-20 people 1-3 times a week it gets quite tedious! ============================================
Blue-Fire Best Fire |
Sentenced 1989
Quantum Anomaly Corporation
57
|
Posted - 2014.05.28 16:55:00 -
[438] - Quote
CCP FoxFour wrote:Sentenced 1989 wrote:.... The cache time for that endpoint is 1 hour. 3600 second. You can see it in the headers as: Cache-Control GåÆpublic, max-age=3600 There really is no way for it to change every few minutes, that cache is on the nginx box. The server only gets asked once every hour.
That's what I figured. I'll update my end of stuff so it doesn't ask every time, just once per hour, however you have some error then.
So far I haven't obeyed cache (just implemented the functionality first time, so my bad, sorry, I'll fix it asap), but CREST was reporting 5 incursion up, then a minute or two later 6 incursions up, then a minute or two later 5 incursions up, etc...
If server is asked once every hour, how come I've got different result every few minutes out of CREST?
One more thing though, if I might ask, how is this handled on multiple queries from different locations? As in I know dotlan does the query as well, will their query produce same cache result for rest of us? (if I'm not making sense I apologize, but like I've said, I'm kind of a noob here :D)
|
Tek Handle
Vanishing Point. The Initiative.
54
|
Posted - 2014.05.28 18:40:00 -
[439] - Quote
Idea: Complete the /corp/OutpostList by missing station settings Description: useAllianceStanding=1/0 reprocessingOutputDivision=someDivisionFlag reinforcedModeTime=0000...2300
Idea: Add an endpoint which allows us to fetch existing clone contracts on a player outpost Description: This should return rowsets with a corpID attribute and characterIDs as nested rows
Idea: Add an endpoint which allows us to fetch a list of offices in a player outpost Description: rows with attributes officeNumber=1...n publiclyAvailable=1/0 rentedByCorporationID=12345789 startDate=someTimestamp rentPeriod=always30anyway?!
Idea: Add an endpoint which allows us to read the reinforcement time configured for iHubs (and a state as well as the stateTimestamp comparable to the /corp/StarbaseList endpoint)
Idea: Add an endpoint which allows us to fetch a list of customs offices and their setting (standings+reinforced time) |
Wollari
Dirt Nap Squad Dirt Nap Squad.
73
|
Posted - 2014.05.29 10:39:00 -
[440] - Quote
Question for the WAR API
when the attacker or defender joins or leaves an alliance: how will this be displayed in the war data? Will the attacker change from a corporation to an alliance? Does the alliance become an ally or does this war gets closed and a new war pops up for the alliances? Same applies to allies. If an ally joins an alliance or leaves an alliance during the war.
That's a question when tracking wars I've to be aware what data CAN change and which data IS static DOTLAN EveMaps-á| Your out-of-game map, navigation toolset, sov database, etc. since 2008 |
|
|
CCP FoxFour
C C P C C P Alliance
3254
|
Posted - 2014.05.29 12:54:00 -
[441] - Quote
Wollari wrote:Question for the WAR API
when the attacker or defender joins or leaves an alliance: how will this be displayed in the war data? Will the attacker change from a corporation to an alliance? Does the alliance become an ally or does this war gets closed and a new war pops up for the alliances? Same applies to allies. If an ally joins an alliance or leaves an alliance during the war.
That's a question when tracking wars I've to be aware what data CAN change and which data IS static
So, take this with a grain of salt as I don't know for sure, some testing will be required.
However from what I understand for attacker: If a corp is in an alliance the alliance declares the war. A corp leaving will not change the attacker as it doesn't matter who in the alliance declared it, the alliance is the attacker.
If an attacking corp leaves an alliance though I believe a new war is started. Same with if a defending corp joins or leaves an alliance. There should be, I think I included it, a fromWarID or fromWar field if that happens... not 100% sure as its a day off here and I don't have the code or docs in front of me. CCP FoxFour // Game Designer // @regnerba
|
|
|
CCP FoxFour
C C P C C P Alliance
3254
|
Posted - 2014.05.29 13:01:00 -
[442] - Quote
Aquila Sagitta wrote:============================================ Idea: Allow us to send isk via corp or personal wallet Description: I'm currently building tools for my wh based corp and I'd love it if you could send isk with one click instead of having to go to wallet, go to corp wallet, transfer isk, find the person your paying, double check its the right person, type in amount, and then pay them. When you have to do this with 10-20 people 1-3 times a week it gets quite tedious! ============================================
This MAY happen with CREST but definitely not anytime soon and even then we really don't know if we want to allow this. CCP FoxFour // Game Designer // @regnerba
|
|
|
CCP FoxFour
C C P C C P Alliance
3257
|
Posted - 2014.05.29 13:29:00 -
[443] - Quote
Sentenced 1989 wrote:CCP FoxFour wrote:Sentenced 1989 wrote:.... The cache time for that endpoint is 1 hour. 3600 second. You can see it in the headers as: Cache-Control GåÆpublic, max-age=3600 There really is no way for it to change every few minutes, that cache is on the nginx box. The server only gets asked once every hour. That's what I figured. I'll update my end of stuff so it doesn't ask every time, just once per hour, however you have some error then. So far I haven't obeyed cache (just implemented the functionality first time, so my bad, sorry, I'll fix it asap), but CREST was reporting 5 incursion up, then a minute or two later 6 incursions up, then a minute or two later 5 incursions up, etc... If server is asked once every hour, how come I've got different result every few minutes out of CREST? One more thing though, if I might ask, how is this handled on multiple queries from different locations? As in I know dotlan does the query as well, will their query produce same cache result for rest of us? More in detail, all I see in header is Cache-Control: public, max-age=3600, I don't see exact time when it is over as in "cached until", so what I am asking will somebodies else call trigger this countdown, or does every caller get desperate cache file with his own timer?
I really shouldn't have posted, I was clearly very tired.
TL;DR yes, that makes sense, it can happen, just obey the cache timer.
Long version: We have 2 nginx boxes serving public CREST on a DNS round robin. The incursion endpoint is very rarely hit. What likely happened is someone made a single GET which hit one of the nginx boxes. A while later someone made another GET which hit the second nginx box. The second one got newer data. I was under the impression that once a person started making requests they would only get one of the nginx boxes which is why I said you should not be getting different results. If however you were looking up the IP every request and going back and forth between boxes there is a chance you would be getting different results.
This should basically answer your second question though. The two nginx boxes have local caches, they can be out of sync, depends where you end up.
We very much on purpose don't tell you when the cache expires. This is pretty standard from my knowledge of the web. If we told everyone when the cache expires everyone would query at that time. Instead we just tell you how long the cache lasts and you obey that. It does mean you may not get the data at exactly the newest possible time, but for us it means the load is spread instead of our servers getting crushed. :)
Hope that helps! :D
CCP FoxFour // Game Designer // @regnerba
|
|
Sentenced 1989
Quantum Anomaly Corporation
58
|
Posted - 2014.05.29 14:02:00 -
[444] - Quote
CCP FoxFour wrote:
I really shouldn't have posted, I was clearly very tired.
TL;DR yes, that makes sense, it can happen, just obey the cache timer.
Long version: We have 2 nginx boxes serving public CREST on a DNS round robin. The incursion endpoint is very rarely hit. What likely happened is someone made a single GET which hit one of the nginx boxes. A while later someone made another GET which hit the second nginx box. The second one got newer data. I was under the impression that once a person started making requests they would only get one of the nginx boxes which is why I said you should not be getting different results. If however you were looking up the IP every request and going back and forth between boxes there is a chance you would be getting different results.
This should basically answer your second question though. The two nginx boxes have local caches, they can be out of sync, depends where you end up.
We very much on purpose don't tell you when the cache expires. This is pretty standard from my knowledge of the web. If we told everyone when the cache expires everyone would query at that time. Instead we just tell you how long the cache lasts and you obey that. It does mean you may not get the data at exactly the newest possible time, but for us it means the load is spread instead of our servers getting crushed. :)
Hope that helps! :D
Yep, helped a lot, thanks for taking your time to explain it. Anyways, I've redone some stuff on my end, so now I pull your response into local file and my server won't check for new data in 60 minutes. Also to even more limit the load, I didn't tie it to cron job, so only on request of data (when somebody actually opens my page) it asks for new data if the local copy is older then 60 minutes, should make everybody happy :)
And I've even learned how to add user agent to my request :D \o/
|
|
CCP FoxFour
C C P C C P Alliance
3257
|
Posted - 2014.05.29 14:04:00 -
[445] - Quote
Sentenced 1989 wrote:CCP FoxFour wrote:
I really shouldn't have posted, I was clearly very tired.
TL;DR yes, that makes sense, it can happen, just obey the cache timer.
Long version: We have 2 nginx boxes serving public CREST on a DNS round robin. The incursion endpoint is very rarely hit. What likely happened is someone made a single GET which hit one of the nginx boxes. A while later someone made another GET which hit the second nginx box. The second one got newer data. I was under the impression that once a person started making requests they would only get one of the nginx boxes which is why I said you should not be getting different results. If however you were looking up the IP every request and going back and forth between boxes there is a chance you would be getting different results.
This should basically answer your second question though. The two nginx boxes have local caches, they can be out of sync, depends where you end up.
We very much on purpose don't tell you when the cache expires. This is pretty standard from my knowledge of the web. If we told everyone when the cache expires everyone would query at that time. Instead we just tell you how long the cache lasts and you obey that. It does mean you may not get the data at exactly the newest possible time, but for us it means the load is spread instead of our servers getting crushed. :)
Hope that helps! :D
Yep, helped a lot, thanks for taking your time to explain it. Anyways, I've redone some stuff on my end, so now I pull your response into local file and my server won't check for new data in 60 minutes. Also to even more limit the load, I didn't tie it to cron job, so only on request of data (when somebody actually opens my page) it asks for new data if the local copy is older then 60 minutes, should make everybody happy :) And I've even learned how to add user agent to my request :D \o/
Awesome! That is exactly the way it should work and huge thanks for the user agent! :D
Any chance of sharing a link to what you are working on? CCP FoxFour // Game Designer // @regnerba
|
|
Ideki
E.A.D Alliance Omega Vector
207
|
Posted - 2014.05.29 18:41:00 -
[446] - Quote
Hey FoxFour, love the Dev Spolight. always nice to be able to put a real face on a name Creator of The EVE Planetary Planner and The EVE Ships Skills Planner Author of Immortal Warriors |
|
CCP FoxFour
C C P C C P Alliance
3272
|
Posted - 2014.05.29 18:51:00 -
[447] - Quote
Ideki wrote:Hey FoxFour, love the Dev Spolight. always nice to be able to put a real face on a name
:) Glad you enjoyed it. CCP FoxFour // Game Designer // @regnerba
|
|
Malus Sentio
Oberon Incorporated RAZOR Alliance
2
|
Posted - 2014.05.29 21:11:00 -
[448] - Quote
Idea: Allow us to query entire killmail history Description: We need to be able to pull entire killmail histories to be able to develop better killboards that can compete with the existing ones. Killboards play a massive part in telling the stories that happen in EVE. |
|
CCP FoxFour
C C P C C P Alliance
3272
|
Posted - 2014.05.29 21:56:00 -
[449] - Quote
Malus Sentio wrote:Idea: Allow us to query entire killmail history Description: We need to be able to pull entire killmail histories to be able to develop better killboards that can compete with the established ones. Killboards play a massive part in telling the stories that happen in EVE.
Thats not a very good argument considering established killboards (aka zKillboard) offers an API to pull all the killmails they have.
You don't need us to help you compete.
To be honest, they also store them in a slightly better and more efficient way. If they were not offering an API to get killmails, which is actually easier than getting them from us because you don't need API keys and such, then I would be more considering of this. CCP FoxFour // Game Designer // @regnerba
|
|
Ogir Tenno
Marvel-Yukon
8
|
Posted - 2014.05.29 22:13:00 -
[450] - Quote
CCP FoxFour wrote:Malus Sentio wrote:Idea: Allow us to query entire killmail history Description: We need to be able to pull entire killmail histories to be able to develop better killboards that can compete with the established ones. Killboards play a massive part in telling the stories that happen in EVE. Thats not a very good argument considering established killboards (aka zKillboard) offers an API to pull all the killmails they have. You don't need us to help you compete. To be honest, they also store them in a slightly better and more efficient way. If they were not offering an API to get killmails, which is actually easier than getting them from us because you don't need API keys and such, then I would be more considering of this.
There's a clear argument against that: We are dependent from those APIs then. zKillboards shuts us down - we're screwed. Supporting that there should be a neutral API. |
|
|
|
|
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 [15] 16 17 18 19 20 30 .. 30 :: one page |
First page | Previous page | Next page | Last page |