Pages: 1 2 :: [one page] |
|
Author |
Thread Statistics | Show CCP posts - 5 post(s) |
|
CCP Guard
C C P C C P Alliance
|
Posted - 2011.07.29 14:41:00 -
[1]
Please check out CCP Elerhino's new dev blog about the contract API features due at the end of summer.
And if you have questions for CCP Elerhino and friends about the contents of the blog, leave them right here in the thread as always.
-CCP Guard
|
|
Tork Norand
Mechanical Eagles Inc. The Ancients.
|
Posted - 2011.07.29 15:12:00 -
[2]
Edited by: Tork Norand on 29/07/2011 15:12:16 As a thought, why not move completed contracts and orders to a new database.
This would greatly reduce the amount of data that has to be looked up "live" and still retain a large amount for "after the fact". Then, you start with the live lookup when doing queries of any sort, and if you need to drill down, you can do a slower query against the stored data from the other database. The only time duplication would arise is when something sold between the two, and an identifier can be used to exclude what's already been viewed.
Just a thought.
Edit: Holy crap! I had an accidental "First" post. People must not like database stuff. --Tork Norand, CEO. |
SencneS
Rebellion Against Big Irreversible Dinks
|
Posted - 2011.07.29 15:17:00 -
[3]
If Corporate contracts have to be locked behind a Director API then that is OK. If a lacky wants to see the corporate contracts he can login and look at them.
I am also not completely understanding how the items in the contract show up in the API. The way it reads is you'll get ContractID from one API, and on another you'll have items listed according to ContractID?
Originally by: Dev Blog The contract lists themselves will not include items, bids or notifications. We'll have separate pages for items and bids but most likely completely skip notifications. The item page will display a list of items for a specified contract, the information will contain things like type ID, quantity and whether the item is being asked for or is included.
I also slight agree with Tork Norand, having the users market and contracts combined together might be easier. I don't think it's own database would solve issues with getting the data, but combining Market Orders and Contracts on the same API might be a good solution. For Contracts just add an extra column to this already light API pull, for "Order Assignment". You could then use the already existing "buy", "Sell" column and add "Contract".
If it's "contract" then it reads the extra argument column which contains the ContractID.
Make the users of applications that read that API sort out the Contracts from the Market Orders.
---
Thinking outside the box is good, but when the Box has everything you need, no need to create something new... |
|
Chribba
Otherworld Enterprises Otherworld Empire
|
Posted - 2011.07.29 15:53:00 -
[4]
Interesting
/c
Secure 3rd party service | in-game 'Holy Veldspar' Now /w voice |
|
Dierdra Vaal
Caldari Veto. Veto Corp
|
Posted - 2011.07.29 16:44:00 -
[5]
Good news! Contracts have long been requested as an api feature.
Veto #205 * * * Director Emeritus at EVE University * * * CSM1 delegate, CSM3 chairman and CSM5 vice-chairman
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.29 16:49:00 -
[6]
I would love the ability to view historical data. Can you please provide a way to walk market orders, wallet transactions/journal, and contracts that are older than a month? This data doesn't change and you could write it out in month chunks to flat files and server it up. What do you say?
|
Zirse
Minmatar ZED Industries
|
Posted - 2011.07.29 16:51:00 -
[7]
Quote: member of the corporation but in the API we're locking it behind a corporation key which only directors and CEOs can create. This is a kind of a security measure in the sense that it prevents members from accidentally giving corporate information to a 3rd party.
Now maybe I'm misunderstanding here, but knowing how meta EVE gets, I don't think it'll be long before anybody who wants access to the corporation data will have it. Is there a way to only send corporate data to API keys associated with that corporation?
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.07.29 17:30:00 -
[8]
Originally by: Zirse
Quote: member of the corporation but in the API we're locking it behind a corporation key which only directors and CEOs can create. This is a kind of a security measure in the sense that it prevents members from accidentally giving corporate information to a 3rd party.
Now maybe I'm misunderstanding here, but knowing how meta EVE gets, I don't think it'll be long before anybody who wants access to the corporation data will have it. Is there a way to only send corporate data to API keys associated with that corporation?
That's exactly what it will do if we keep it like this, this data will only be available to corporate keys.
CCP Elerhino CCP Software - API
|
|
Shepard Book
|
Posted - 2011.07.29 17:43:00 -
[9]
Will we eventually have access to market and contract data in evegate?
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.07.29 17:45:00 -
[10]
Originally by: Marcel Devereux I would love the ability to view historical data. Can you please provide a way to walk market orders, wallet transactions/journal, and contracts that are older than a month? This data doesn't change and you could write it out in month chunks to flat files and server it up. What do you say?
This is actually something we thought about doing instead of the get-latest approach we ended up with. A get-latest solution is what we wanted to do to begin with, the reason why we thought about doing a walking/paging solution was that the method we used in the market orders recently has holes in it. But fetching single items to fill the holes is a better solution because it's a very fast query (by ID) and for some items you might have to page through a mountain of items to get to the single one you need because the paged items would be ordered by creation date and the single items you need can get quite old.
But this is not final and is actually something we'd really like to see some discussion on here.
CCP Elerhino CCP Software - API
|
|
|
Thebriwan
LUX Uls Xystus
|
Posted - 2011.07.29 19:51:00 -
[11]
This is good news.
In my opinion the corp contract should be secured with corp - keys.
What I would like to know how you want to implement the listing of the contents of a contract. Like with containers?
And if you are looking into more functionality for the API - would it be possible to have the assets from a single station with a shorter timer? That would be fabulous!
|
Golden Gnu
Gallente The Golden Gnu Corp
|
Posted - 2011.07.29 20:25:00 -
[12]
I'm sure this will make a lot of people happy. I'll let the smart guys/girls find your perfect solution ;)
I love all the work the API is getting... It's awesome, you know, the API. _________________ Download is the meaning of life, upload is the meaning of intelligent life EVE.NiKR.NET - home of jEveAssets |
Durin Sarga
|
Posted - 2011.07.29 21:05:00 -
[13]
Most of this looks good. I got a little confused on what exactly the API output would 'look' like. The devblog was short on graphs, charts, figures, etc. : )
What are the chances of being able to export market item historical data. The stuff we can find on the second page of the Market details window when we select Table instead of Graph. THAT information would be a HUGE +1.
My 2 ISK.
Durin
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.29 23:05:00 -
[14]
Sounds good, any information on what the calls might be? I want to look. :)
PS, I would like an employment history api.
POS-Tracker 3.0 Hosting |
Risingson
|
Posted - 2011.07.29 23:13:00 -
[15]
I wish you would do an api delivering info on ongoing Icursions ! // Eveeye.com :: IPS Solarsystem Intel & Info |
Andski
GoonWaffe Goonswarm Federation
|
Posted - 2011.07.29 23:36:00 -
[16]
I'm so glad that this is finally being implemented. MY SPREADSHEETS thank you.
|
Ydnari
Gallente Estrale Frontiers
|
Posted - 2011.07.29 23:46:00 -
[17]
Useful.
I hope the items part of this will include items inside courier contracts, will make it much easier to keep track of stuff in flight.
|
SirHarryPierce
|
Posted - 2011.07.30 03:53:00 -
[18]
Great! As mentioned above: my spreadsheets will thank you :).
|
Ikaef Giasep
|
Posted - 2011.07.30 05:56:00 -
[19]
Originally by: Tork Norand Edited by: Tork Norand on 29/07/2011 15:12:16 As a thought, why not move completed contracts and orders to a new database.
This would greatly reduce the amount of data that has to be looked up "live" and still retain a large amount for "after the fact". Then, you start with the live lookup when doing queries of any sort, and if you need to drill down, you can do a slower query against the stored data from the other database. The only time duplication would arise is when something sold between the two, and an identifier can be used to exclude what's already been viewed.
This is a solution that would really help. Just constantly copy new data to a separate server once in while and have the API operate on it instead. Every major company I know uses such a mechanism (for reporting). An additional benefit would be that the database of the other system could be specifically designed for API purposes. This could help to speed up API access
|
Cyaxares II
|
Posted - 2011.07.30 07:14:00 -
[20]
got my hopes up when seeing the devblog title but was of course disappointed.
market orders don't need a history because journal & transactions log keep track of everything that happens.
guess CCP is now playing "corrupt a wish" with us - "yes, you can have that contracts API you have been asking for for years but we will change one little detail to make it useless"
maybe try some of your own "agile" methodology and read the forums to see what use cases people actually have in mind and then think about how to implement them. Not "oh they want a contracts API, let's create some API for contracts (that is easy to implement) and everything will be fine!"
|
|
Thebriwan
LUX Uls Xystus
|
Posted - 2011.07.30 09:27:00 -
[21]
Originally by: Cyaxares II A bunch of stuff
I really had have it with this "I am f*** angry at CCP because they do not exactly as I wish"-attitude.
Was is really necessary to write a half a posting with a whine and an attack at CCP? Do you really think that this is doing your POV any good? And last but not least do you really think that anyone can imagine all the things that people want to do with the API?
This dev blog is clearly stating why they can not do to much history. AND you could have presented you POV in a friendly, constructive manner. Then maybe there could have been some movement in you direction.
|
Abdiel Kavash
Caldari Paladin Order Fidelas Constans
|
Posted - 2011.07.30 11:47:00 -
[22]
So, as far as I understand, this is for my contracts only? Meaning, I can't ask the API "show me all the contracts for Estamel's Modified Thingamajig in Jita"? ---
|
Desmont McCallock
|
Posted - 2011.07.30 11:58:00 -
[23]
Originally by: Abdiel Kavash So, as far as I understand, this is for my contracts only? Meaning, I can't ask the API "show me all the contracts for Estamel's Modified Thingamajig in Jita"?
Nope, it's not a contract finder.
|
Zaxix
Daisy Hill Puppy Farm
|
Posted - 2011.07.30 14:08:00 -
[24]
Red Frog/Black Frog has been one of the long time proponents of the contract API. How will the API handle courier contracts? From our viewpoint, historical data is essential, since we can use that data in so many different ways (e.g., rewarding pilots for meeting benchmarks, rewarding clients for repeat business, figuring out the best placement of resources, etc etc.). Will we simply have to create our own database and log the data once the API goes live?
Still its good to see the Contracts API taking off!!! |
Consortium Agent
|
Posted - 2011.07.30 15:13:00 -
[25]
o/ CCP
Nice devblog and it raises one question:
Quote: the datasets simply aren't optimized for this kind of a query
Why not optimize the datasets then? Doesn't this seem like the most logical approach to addressing performance problems instead of limiting what players can do because your dataset was poorly designed?
I know, I know... it's a lot of development work blah, blah, blah - there are ways around this. I presume your API dataset is a replicant of your core dataset in some fashion? If so, DTS is a wonderful thing - you could build new, optimized, tables and procedures and then just have DTS translate the replication from the 'old' core dataset to the new API tables.
Having said all of that, however, I personally have an interest in a contracts API and will take whatever you'll give us, frankly. I would prefer to be able to get finished contracts from the API for some period of time (say 2 days perhaps) as, from the perspective of checks and balances, it would make things easier, but I could live without them if I had to ;)
And one more question - would corporate contracts not fall under a corp key in the new API you're working on? Doesn't this, by its very nature, eliminate the possibility of a luser giving away corp details to people he shouldn't?
Good work... keep it up!
|
Cyaxares II
|
Posted - 2011.07.30 21:31:00 -
[26]
Edited by: Cyaxares II on 30/07/2011 21:37:19
Originally by: Thebriwan This dev blog is clearly stating why they can not do to much history. AND you could have presented you POV in a friendly, constructive manner. Then maybe there could have been some movement in you direction.
sure, I'll take the blame for preventing CCP from reworking this proposal into something useful (because they feel insulted by my unfriendly feedback).
Originally by: Thebriwan And last but not least do you really think that anyone can imagine all the things that people want to do with the API?
People have been asking for a Contracts API for several years now - hardly a secret why they want one. There have been countless threads on this topic, proposals in F&I, it has been discussed by CSM and ranked fairly high in their crowd-sourcing ("One of the more common applications for the API is collecting data for book keeping of your wallet. However, the lack of contracts API means there is a large gap in the data.", " We need a full contracts API. Currently the only information you can get about contracts is from the Wallet, and contract related entries don't list the items contained within or even who you were interacting with. This is important because much of the expenditures and transport of goods in large alliances are through contracts, and adding the system will help greatly with auditing and stuff like that. "), ...
The only explanation how they could be ignorant to the reasons why people want that API so much would be if they never spend time on the S&I, MD & F&I forums and don't listen properly to the CSM.
I think CCP did decide to react to the latest CSM request by implementing a API that they can call "contracts API" but that is actually useless. Gets rid off one item in their backlog without causing them a lot of work. Nice & cheap success story about listening to player requests while actually ignoring them.
I also don't like how you label my post as "unconstructive" - it's not like I made these use-cases up (see quotes above), I took some care to wrap them into nice user-centric stories that don't foreclose the solution of the problem, I even laid out how imo nothing would be better than the proposed solution...
|
Marcel Devereux
Aideron Robotics
|
Posted - 2011.07.31 03:22:00 -
[27]
Originally by: CCP Elerhino Edited by: CCP Elerhino on 29/07/2011 17:47:36
Originally by: Marcel Devereux I would love the ability to view historical data. Can you please provide a way to walk market orders, wallet transactions/journal, and contracts that are older than a month? This data doesn't change and you could write it out in month chunks to flat files and server it up. What do you say?
This is something we thought about doing instead of the get-latest approach we ended up with. A get-latest solution is what we wanted to do to begin with, the reason why we thought about doing a walking/paging solution was that the method we used in the market orders recently has holes in it. But fetching single items to fill the holes is a better solution because it's a very fast query (by ID) and for some items you might have to page through a mountain of items to get to the single one you need because the paged items would be ordered by creation date and the single items you need can get quite old.
But this is not final and is actually something we'd really like to see some discussion on here.
I'm fine with a API that provides just the recent and out standing contracts as long as we can someone get at the older contracts. Is there a way to go from journal refID to contractID and look up single contracts that way? We would of course still need a way to get at historical journal entries so we could retrieve the refID of completed contracts.
|
Desmont McCallock
|
Posted - 2011.07.31 08:22:00 -
[28]
I think that this line in the devblog answers your question.
Originally by: CCP Elerhino
Similar to the Market Orders, the Contract list will contain contracts that are outstanding or in progress, as well as recently issued contracts. We'll also have a separate page or a contractID parameter so that you can look up a single contract.
|
Thebriwan
LUX Uls Xystus
|
Posted - 2011.07.31 09:29:00 -
[29]
Originally by: Cyaxares II I think CCP did decide to react to the latest CSM request by implementing a API that they can call "contracts API" but that is actually useless. Gets rid off one item in their backlog without causing them a lot of work. Nice & cheap success story about listening to player requests while actually ignoring them.
I don't see where the contracts API would be useless. For my use cases the way they described it, it would fit perfect.
And what you did not see is that they cannot give access to all contracts (or orders) because of the db stress this would generate.
That is called a compromise.
Originally by: Cyaxares II I also don't like how you label my post as "unconstructive" - it's not like I made these use-cases up (see quotes above), I took some care to wrap them into nice user-centric stories that don't foreclose the solution of the problem, I even laid out how imo nothing would be better than the proposed solution...
In everything that is communicated the "how" is as important as the "what". You have your good and valid points brought into context with a rant - even if the dev can see your point it will be tainted. That's all I'm saying.
|
Matthew
Caldari BloodStar Technologies
|
Posted - 2011.07.31 15:22:00 -
[30]
So, if we take it as read that queries against contract/order end date are expensive, but those against start date are reasonable, and that this cannot easily be changed, then the proposed solution seems reasonable. Given this, there seem to be three key design parameters to consider:
Minimum Query Frequency
This is defined by the time window of recently issued orders included in the API response. If the API only includes the last weeks worth of recently issued orders, then the user must query the API at least once every not-quite-a-week to be sure of having seen all records.
Note that the IndividualContract API does not cover this issue, because even if it allows the specified contract to be retrieved, the user has no API method of knowing the missing contractIDs.
So, the question here would be, is it reasonable for a user to end up with holes in their records if they do not query the API at least once every week? What would be a reasonable minimum interval?
Start-Up History Pull
Long-term users of the API can build up a history. But where a new user starts to use the API, or a new API is introduced, the ability to retrieve older historical information is limited.
With the currently proposed API, the ability to build up a history would be limited by the time window of recently issued orders. In this case, you would only be guaranteed a complete history going back one week from the point at which you start to use the API.
This is where Marcel's suggestion would come in. Once a contract/order is completed the record no longer changes. So the API server could archive this information into some sort of static cache, rather than troubling TQ for it every time. We could then get three API calls:
CurrentContracts - as proposed in the dev-blog, non-expired items as well as items issued less than X time ago.
ArchivedContracts - All expired items, ordered by creation date, with a paging mechanism to go back 1+ month. (this would just require filtering by isExpired, rather than ordering by ExpiryDate, which is hopefully a less costly query)
IndividualContract - as proposed in the dev-blog, give a contractID and get that individual contract back.
The new user starting to use the API can then use ArchivedContracts to retrieve an initial "boot-strap" historic dataset. They can then keep it updated using CurrentContracts, filling in gaps with IndividualContract.
The other advantage of ArchivedContracts is that it would act as a failsafe against the Minimum Query Frequency issue above. If the user does miss the Minimum Query Frequency for some reason, they can use ArchivedContracts to recover the missing contract details.
Bulk vs Individual Update of Contract Status
This point is about the efficiency of retrieving updates via CurrentContracts vs having to make a lot of calls to IndividualContract.
For example, if CurrentContracts returns the most recent week of issued contracts, but the typical life of your contract is 10 days, then you are going to have to use IndividualContract to update the majority of your completed contracts, leading to a lot of spamming of the IndividualContract API. In this case it may be more efficient to extend the time interval returned by CurrentContracts.
This is probably something best determined by looking at the distribution of time-to-expiry on all contracts to determine a suitable minimum coverage of CurrentContracts. ------- There is no magic Wand of Fixing, and it is not powered by forum whines. |
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.07.31 15:37:00 -
[31]
Originally by: Cyaxares II Edited by: Cyaxares II on 30/07/2011 07:48:11 from my POV there are three major areas of application for a contracts API
(a) "I want an application that gives me an overview over my revenue, profits, most profitable items, ... for the last week/month/quarter/... . Part of my business relies on buying from and selling to contracts." (b) "I have this guy's Full API key and want to check if he had any financial connections to hostiles, possibly undisclosed alts, ... in the recent to mid-term past" (c) "Do I have to log in to renew my filled/expired contracts already?"
The proposed API does (c) well but (c) is the scenario that is centered around cheap convenience the most. It fails completely at (b). It is mostly useless when used for (a) which is imo the prime use-case.
It may be possible to work around the API to arrive at some sort of solution for (a) - but then we are at "I have to run this tool multiple times per day to create my own local contracts history. If I forget to run it for a few days my whole accounting for that time period will be screwed up." But even then we still face the problem that only "me selling with WTS/Auction contracts" is covered. "Me selling to WTB" or "me buying from WTS" leaves no tracks.
For B, journal is going to be better for this anyway. For A, if your looking to do that, your tool should be checking in and downloading and storing data anyway or its not worth the space required to install it. This api has nothing to do with that, even the journal only goes back so far.
Yes, this api could be better, I hope it will get better. At least it is something and maybe we can get more later. I am actually more disappointed that this is the only api related item in the CSM thing. I am guessing every player, or at least there corporation, uses some app that pulls info from the api, yet it has the least resources devoted to it. I want more APIs, especially that employment history api, a ramsan for the api servers, and faster responses and shorter cache timers. It would also be nice if more then one or two people where assigned to work on the api.
POS-Tracker 3.0 Hosting |
Locin WeEda
Gallente Red Frog Investments
|
Posted - 2011.07.31 22:50:00 -
[32]
Needless to say, we in Red Frog/Black Frog are very happy about the contract api!
Quote: This is something we wanted to get your opinion on, the corporation contracts are visible in-game to any member of the corporation but in the API we're locking it behind a corporation key which only directors and CEOs can create. This is a kind of a security measure in the sense that it prevents members from accidentally giving corporate information to a 3rd party.
I think it is a very good idea to lock the corporate contract api to CEO and directors. Either that, or tie it to a role. It should not be accessible for ALL members of the corporation.
Once we have played around with the api some more, we should be back with some more feedback.
Red Frog Freight Service -
|
Ryomanni
Red Frog Investments
|
Posted - 2011.08.03 23:42:00 -
[33]
Perhaps I filed my results and questions that specifically relate to the contract API in an ineffective place, the custom API keys forum (http://www.eveonline.com/ingameboard.asp?a=topic&threadID=1554297&page=3#67).
I'm sure someone is thinking about the questions regardless. I'll monitor both these forums in case new details emerge, and I can try them out in very short notice - again, very exciting news! - Ryo.
|
Callean Drevus
Caldari Icosahedron Crafts and Shipping Silent Infinity
|
Posted - 2011.08.04 09:29:00 -
[34]
Question Will the contract details & contents API be open to for every contract? That is, if you've got the ID, will you be able to get the data specific for that contract? Contract information is open pretty much by default, so I should think this is a possiblity. --- "A fool flatters himself, a wise man flatters the fool."
Chief Developer of EVE Marketeer. |
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.08 10:27:00 -
[35]
Originally by: Callean Drevus Question Will the contract details & contents API be open to for every contract? That is, if you've got the ID, will you be able to get the data specific for that contract? Contract information is open pretty much by default, so I should think this is a possiblity.
As long as the authenticated character is a part of that contract in some way - yes and yes.
CCP Elerhino CCP Software - API
|
|
|
CCP Elerhino
Minmatar C C P C C P Alliance
|
Posted - 2011.08.08 11:04:00 -
[36]
Originally by: Ryomanni
Q. Will the contracts results include a weeks worth of contracts, rather than just outstanding and in progress? It would make it easier to record the contracts that are finished, failed, or rejected.
Q. Regarding the recent dev blog post, "We'll also have a separate page or a contractID parameter so that you can look up a single contract." - Will that work on finished contracts?
Q. I see an approximate one hour cachedUntil time on the test server data. Is it possible this cached time could be lessened so new contracts can be recorded more quickly?
Q. Does the "title" element of the XML hold the user defined contract description?
Q. I noticed there are contracts that have a dateAccepted value even though they have a status of "Outstanding" - should that be a blank string like the dateCompleted value is?
Q. Will there be any change to the "showContract" IGB JavaScript method so only a contractID is required, instead of also having to supply the solarSystemID? And if not, could each contract API row also include a solarSystemID (this would save having to look up the solarsystemID of the startStationID in the data dump).
The contract list will include items created within the last week as well as all outstanding and inprogress contracts. You'll be able to fetch any of your contracts (also finished contracts, yes) using a contractID parameter on the contract list page. Most likely we'll start with a 1 hour cache time, we'd of course like to get it down but as always we need to be careful when it comes to performance. The title element should hold the custom description, yes. We are currently looking at special cases in the date columns, the dateAccepted is one of them.
CCP Elerhino CCP Software - API
|
|
Locin WeEda
Gallente Red Frog Investments
|
Posted - 2011.08.09 07:21:00 -
[37]
Originally by: CCP Elerhino
The contract list will include items created within the last week as well as all outstanding and inprogress contracts. You'll be able to fetch any of your contracts (also finished contracts, yes) using a contractID parameter on the contract list page. Most likely we'll start with a 1 hour cache time, we'd of course like to get it down but as always we need to be careful when it comes to performance. The title element should hold the custom description, yes. We are currently looking at special cases in the date columns, the dateAccepted is one of them.
Thanks for the answers.
Will the contractID be visible somewhere ingame? For instance as a column in My contracts? Currently the steps you need to take to find the contractid on a given contract ingame is a bit convoluted. First, I need to drag the contract to a chat channel, then I have to copy the line, and then I have to paste it into notepad in windows to see the contract id.
If the contractID could be passed to the chat log it would be even better, as we would then have a way to find out what contracts have been mentioned in our chat-rooms when reading the logs.
Red Frog Freight Service -
|
Locin WeEda
Gallente Red Frog Investments
|
Posted - 2011.08.12 10:17:00 -
[38]
After reviewing the api-data, I realized that from the API data alone, there is no way to separate between these two situations:
- contract is overdue, and get failed by the pilot that accepted the contract - contract is overdue and get failed by the issuer of the contract
While the effect is the same, how we act as a corp in the two situations can be very different.
It is easy to find out when the contract is not overdue, as the accepting pilot is the only one allowed by game mechanics to fail a contract then.
Is it possible to add something, so we can see whether the contract was failed by the issuer of the contract, or failed by the pilot that accepted the contract?
for example failedbyContractor with state 0 or 1
Red Frog Freight Service -
|
Callean Drevus
Caldari Icosahedron Crafts and Shipping Silent Infinity
|
Posted - 2011.08.17 10:54:00 -
[39]
Originally by: CCP Elerhino
Originally by: Callean Drevus Question Will the contract details & contents API be open to for every contract? That is, if you've got the ID, will you be able to get the data specific for that contract? Contract information is open pretty much by default, so I should think this is a possiblity.
As long as the authenticated character is a part of that contract in some way - yes and yes.
In regards to what I meant, this is probably a no. But why are we not allowed to query contract information that is public in-game anyway. We're not able to get a list of all public contracts, I understand that, since it would be insanely resource intensive, but why not the details (for a public contract) if we obtain the ID from a different source? Or do all character count as involved in a public contract by default?
Thank you for the information in any case . --- "A fool flatters himself, a wise man flatters the fool."
Chief Developer of EVE Marketeer. |
Bob Niac
Gallente freelancers inc Imperial 0rder
|
Posted - 2011.08.18 13:39:00 -
[40]
Originally by: CCP Elerhino .... the database is not optimized [for certain api features] ...
So.. silly question here, but: Why not proxy the TQ database to a web server database? Have the web server pull transactions in real-time. Or, better yet, have a process to sync the TQ database (from the backup server?) during downtime, and be the "man in the middle" when a client requests real-time api data, caching the changed data.
|
|
Ezra Larkyn
Quafe Logistics
|
Posted - 2011.08.22 11:43:00 -
[41]
Could we get an update for the release timeline, please?
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.22 21:58:00 -
[42]
Originally by: Ezra Larkyn Could we get an update for the release timeline, please?
Since there is a patch on Aug 30 and that is when Custom API Keys was scheduled to release, plus the fact that its on SISI with the CAK updates. I would be willing to bet Aug 30.
EVEVERIFY Recruitment API Verifier |
Ezra Larkyn
Quafe Logistics
|
Posted - 2011.08.23 06:17:00 -
[43]
I really really hope so.
But i'm a little bit nervous because only the customiced API and not the contract API is announced for the 30.8. .
So let us hope the best.
|
Iam Widdershins
Project Nemesis Moar Tears
|
Posted - 2011.08.25 10:56:00 -
[44]
As long as this is released alongside custom API keys, and not as something that is suddenly available to everyone with your Full API, I'm all for it. Otherwise, please implement major restrictions.
|
Vessper
Indicium Technologies Hephaestus Forge Alliance
|
Posted - 2011.08.26 19:00:00 -
[45]
Courier contracts should really have as associated ContractItems XML to list those items that are being transported. Currently, an error code is returned:
<error code="134">Invalid or missing contractID.</error>
EveHQ Character App |
Ezra Larkyn
Quafe Logistics
|
Posted - 2011.08.29 05:53:00 -
[46]
Originally by: Johnathan Roark Since there is a patch on Aug 30 and that is when Custom API Keys was scheduled to release, plus the fact that its on SISI with the CAK updates. I would be willing to bet Aug 30.
When i see the patch notification it seems that the contract API will not come tomorrow i fear.
|
Johnathan Roark
Caldari The Graduates Morsus Mihi
|
Posted - 2011.08.29 16:12:00 -
[47]
Originally by: Ezra Larkyn
Originally by: Johnathan Roark Since there is a patch on Aug 30 and that is when Custom API Keys was scheduled to release, plus the fact that its on SISI with the CAK updates. I would be willing to bet Aug 30.
When i see the patch notification it seems that the contract API will not come tomorrow i fear.
Its in the patch notes for tomarrow:
Quote: Contracts
Contract updates are now available to third-party applications. For more information, please read this dev blog. Three new pages were added to the API (in both /char and /corp): Contracts.xml.aspx, ContractItems.xml.aspx and ContractBids.xml.aspx.
EVEVERIFY Recruitment API Verifier |
Ezra Larkyn
Quafe Logistics
|
Posted - 2011.08.29 18:21:00 -
[48]
You see me dancing!
|
|
|
|
Pages: 1 2 :: [one page] |