open All Channels
seplocked EVE Information Portal
blankseplocked Blog: Fixing Lag: And I, for one, welcome our new automaton overlords
 
This thread is older than 90 days and has been locked due to inactivity.


 
Pages: 1 [2] 3 4

Author Topic

RentableMuffin
Posted - 2010.08.18 17:53:00 - [31]
 

I want a thin client!

Hexxx
Minmatar
Posted - 2010.08.18 18:01:00 - [32]
 

Originally by: CCP Oveur

However, we fully intend to allow the thin clients to take over the earth if it deems it necessary to do so to save it.



Yes. A thousand times yes.Twisted Evil

Faolan Fortune
Posted - 2010.08.18 18:04:00 - [33]
 

Whoah, that's pretty impressive stuff.

So I take it with these little helpers, you'll be able to test new game mechanics and such and their performance impact while in development?

Also are you thinking of developing something similar for Incarna, to test the performance impact of a stupid amount of avatars in a station? You think Jita is laggy on the outside... Laughing

dracozna
Posted - 2010.08.18 18:31:00 - [34]
 

Interesting read :)
polish it up with interesting:"It is pitch black. You are likely to be eaten by a grue." and we have a working linux client ;-)
(had to say it)

Wasn't orchestrator also used for the Tyrannis and Dominion trailers? I believe it was mentioned in one of the movies during the last alliance tournament.

CCP Oveur

Posted - 2010.08.18 18:31:00 - [35]
 

Originally by: Luke S
I'm not sure If I fully understand. When you mean by testing the code. do you mean testing the code on the server side or client side?

It can be used for both to certain extent but it's primarily thought for simulating load on the server.
Originally by: Luke S
Just out of curiosity. But has someone in CCP said the doomed words yet? "why not start from scratch and rebuild a new eve?"

So if you thought 18 months was a long time ...

Bomberlocks
Minmatar
CTRL-Q
Posted - 2010.08.18 18:34:00 - [36]
 

Thank you too for the interesting and detailed, Blog, Atropos. I have one small question:

1. I assume you already do this, but do you have tests with the thin client where the client is simply set to roam around a set of systems or regions for long periods of time? The reason I ask this is because I wonder it wouldn't help you on the elusive issue of narrowing down the issue of lag occurring in even empty systems that are not even on the same node as a heavily loaded system?

CCP Atropos

Posted - 2010.08.18 18:43:00 - [37]
 

Originally by: Bomberlocks
Thank you too for the interesting and detailed, Blog, Atropos. I have one small question:

1. I assume you already do this, but do you have tests with the thin client where the client is simply set to roam around a set of systems or regions for long periods of time? The reason I ask this is because I wonder it wouldn't help you on the elusive issue of narrowing down the issue of lag occurring in even empty systems that are not even on the same node as a heavily loaded system?

This is where we're aiming for, so, no, we don't have these tests, yet. We're working on the framework to control the clients such that we can set up nightly jobs gathering the performance data, of various activities. The whole idea is to do it in a structured manner so we can methodically narrow down what the issues are.

CCP Oveur

Posted - 2010.08.18 18:49:00 - [38]
 

Originally by: Aldariandra
Originally by: Larkonis Trassler
Quite interesting. A pity you're not putting it out to the masses. I was rubbing my hands with glee, as I'm sure were many of our Oriental brothers, at the thought of a 'lite' client for certain tasks but it's probably for the best.


By the sounds of it, you need other software to control its actions. It probably doesn't even have command-line instructions to make things happen in the game but instead an API that outside control software talks to to make it do things. All I would ever expect to see on the console screen was "Running.." and maybe some commands to run it in different modes or connect to a different cluster.

Releasing something like this to the public would cause all kinds of problems. First and foremost, because its made to be programatically controlled, it could be exploited and used as farming bots very easily, far more easily that is possible with the current GUI client. Due to its small size, it could be mass-deployed and used in combination with trail accounts create massive insta-fleets, and the like. It really isn't a tool you want out there.


Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.

Traspace
Caldari
School of Applied Knowledge
Posted - 2010.08.18 18:50:00 - [39]
 

How about for the thin client control pull a page from Enders game and the whole remote fleet battles.

Some sort of RTS-like controller then have in office fleet fights :D While it's a p.i.t.a. to manage dozens or hundreds of ships as one person would add an element of unpredictability for fleet fights. Bringing it that much closer to simulating 500 Humans™ going crazy on each other.

Lykouleon
Wildly Inappropriate
Goonswarm Federation
Posted - 2010.08.18 18:52:00 - [40]
 

Quote:
If you start up a normal EVE client it doesn't suddenly start trying to take over the world ala SkyNet (hopefully)


Lies and slander, its in CCP's founding documents that the company will slowly take over the world using a massive combination of EVE clients and the awesome/fearful power of the Tranquility cluster.

Get out of my head, Charles! [/tinfoil]

Kurisu Makkashi
Posted - 2010.08.18 18:52:00 - [41]
 

Originally by: Manfred Rickenbocker
Awwww maaaaaaan! I wanna play EVE Text Adventure too!ugh


Hahahaha, it would be cool to have a client that was "flat".

CCP Oveur

Posted - 2010.08.18 19:02:00 - [42]
 

Originally by: Ban Doga
Edited by: Ban Doga on 18/08/2010 17:49:18
Once the feature page for Tyrannis contained a hint about an automated stress testing framework using "Thin clients", as preserved in a user postings here or here.

I assume the thin clients mentioned in this blog are exactly those.
Is there a reason you removed them from the feature page and re-advertise them now?

Yes they are. Why they were removed, I have no idea. Probably because it's an internal tool and they don't really belong on a feature page.

Luke S
Zeta Corp.
Posted - 2010.08.18 19:14:00 - [43]
 

Originally by: Luke S
Just out of curiosity. But has someone in CCP said the doomed words yet? "why not start from scratch and rebuild a new eve?"

So if you thought 18 months was a long time ...


Ok so, you are doing a MAJOR fix expansion. Not tossing the old client and start over. GOOD LUCK! you'll need it!

Alain Kinsella
Minmatar
Posted - 2010.08.18 19:35:00 - [44]
 

Originally by: CCP Oveur

Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.


[bolded notable part.]

OK, that got me very curious. Sounds like you're considering some re-work of API after all? Question

As for the post itself, thanks. Though I saw the basic notes for this in the GD thread, its nice to have it fleshed out a bit more. Smile

Sessym
Amarr
Posted - 2010.08.18 19:35:00 - [45]
 

I wonder if you are already thought about what I'm going to say, but reading the blog and the posts above, an idea popped into mind. What if you introduced some way to record the requests of the individual clients and then feed them back to one of the control methods on these thin clients? I imagine that would very resource-intensive during the time of recording but, on the other hand, you'd get to play the real thing with the 'robots' over and over. Or even go further, and record a full-scale fight (or market traffic or whatever) from TQ. How does that sound?

Sered Woollahra
No Fixed Abode
LEGIO ASTARTES ARCANUM
Posted - 2010.08.18 19:43:00 - [46]
 

I have just logged off my company VPN where we concluded a load and stress test using generated load, so this blog appeals to me. I love reading the technical details in these blogs, thanks and keep them coming..

CCP Oveur

Posted - 2010.08.18 19:59:00 - [47]
 

Originally by: Alain Kinsella
Originally by: CCP Oveur

Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.


[bolded notable part.]

OK, that got me very curious. Sounds like you're considering some re-work of API after all? Question

As for the post itself, thanks. Though I saw the basic notes for this in the GD thread, its nice to have it fleshed out a bit more. Smile


EVE Gate and the API have been for many years and will continue be part of our strategy for world domination.

What we're experiencing now is that the backend to EVE for the API, EVE Gate etc. has to mature, be secure and scale before they can move forward. This will take a lot of time of trial and error and we are currently doing that through EVE Gate which is moving forward the bi-directional use of said backend (as opposed to the single-direction API).

CCP Atropos

Posted - 2010.08.18 20:22:00 - [48]
 

Originally by: CCP Oveur
Originally by: Aldariandra
Originally by: Larkonis Trassler
Quite interesting. A pity you're not putting it out to the masses. I was rubbing my hands with glee, as I'm sure were many of our Oriental brothers, at the thought of a 'lite' client for certain tasks but it's probably for the best.


By the sounds of it, you need other software to control its actions. It probably doesn't even have command-line instructions to make things happen in the game but instead an API that outside control software talks to to make it do things. All I would ever expect to see on the console screen was "Running.." and maybe some commands to run it in different modes or connect to a different cluster.

Releasing something like this to the public would cause all kinds of problems. First and foremost, because its made to be programatically controlled, it could be exploited and used as farming bots very easily, far more easily that is possible with the current GUI client. Due to its small size, it could be mass-deployed and used in combination with trail accounts create massive insta-fleets, and the like. It really isn't a tool you want out there.


Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.

Actually, CCP Oveur, you didn't answer the question, and have kind of confused the issue now Rolling Eyes
The Thin Client is a wrapped version of the game, to control it we've had to create an API, as you correctly surmised, that interfaces with the the game code. The API we use is still considered as part of the game, in that it is in the same codebase, but is only used to do simple things such as dock/undock/activate module and so on.

As I mentioned in my blog, we can run it in one of two ways, either being dictated to from a central controller, or by being given a simple script to execute. I want to extend this to allow more room for the clients to make up their own mind on what activity to undertake, so that they can form arbitrary fleets, and go roaming, or if fitted with, say, mining lasers, go find a belt and mine, and so forth.

CCP Atropos

Posted - 2010.08.18 20:23:00 - [49]
 

Originally by: Lykouleon
Quote:
If you start up a normal EVE client it doesn't suddenly start trying to take over the world ala SkyNet (hopefully)


Lies and slander, its in CCP's founding documents that the company will slowly take over the world using a massive combination of EVE clients and the awesome/fearful power of the Tranquility cluster.

Get out of my head, Charles! [/tinfoil]

Hence the title of my blog Wink

CCP Oveur

Posted - 2010.08.18 20:24:00 - [50]
 

Originally by: CCP Atropos
Originally by: CCP Oveur
Originally by: Aldariandra
Originally by: Larkonis Trassler
Quite interesting. A pity you're not putting it out to the masses. I was rubbing my hands with glee, as I'm sure were many of our Oriental brothers, at the thought of a 'lite' client for certain tasks but it's probably for the best.


By the sounds of it, you need other software to control its actions. It probably doesn't even have command-line instructions to make things happen in the game but instead an API that outside control software talks to to make it do things. All I would ever expect to see on the console screen was "Running.." and maybe some commands to run it in different modes or connect to a different cluster.

Releasing something like this to the public would cause all kinds of problems. First and foremost, because its made to be programatically controlled, it could be exploited and used as farming bots very easily, far more easily that is possible with the current GUI client. Due to its small size, it could be mass-deployed and used in combination with trail accounts create massive insta-fleets, and the like. It really isn't a tool you want out there.


Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.

Actually, CCP Oveur, you didn't answer the question, and have kind of confused the issue now Rolling Eyes
The Thin Client is a wrapped version of the game, to control it we've had to create an API, as you correctly surmised, that interfaces with the the game code. The API we use is still considered as part of the game, in that it is in the same codebase, but is only used to do simple things such as dock/undock/activate module and so on.

As I mentioned in my blog, we can run it in one of two ways, either being dictated to from a central controller, or by being given a simple script to execute. I want to extend this to allow more room for the clients to make up their own mind on what activity to undertake, so that they can form arbitrary fleets, and go roaming, or if fitted with, say, mining lasers, go find a belt and mine, and so forth.

I said unicorns died when I got technical.

CCP Atropos

Posted - 2010.08.18 20:28:00 - [51]
 

Originally by: Sessym
I wonder if you are already thought about what I'm going to say, but reading the blog and the posts above, an idea popped into mind. What if you introduced some way to record the requests of the individual clients and then feed them back to one of the control methods on these thin clients? I imagine that would very resource-intensive during the time of recording but, on the other hand, you'd get to play the real thing with the 'robots' over and over. Or even go further, and record a full-scale fight (or market traffic or whatever) from TQ. How does that sound?

It certainly is something we've considered. We've got tools, internally, that allow us to record the visual aspects of a client, such as play this visual effect, then play this one, but as I say, they're only for the visual effects.

In the scenario you talk about we would want to tackle the technical causes of lag, and so we would have to record the actual commands sent to the server, which is a much more involved task. It's by no means impossible, and it's something I want to do, just not now Confused

Ix Forres
Caldari
Righteous Chaps
Posted - 2010.08.18 20:31:00 - [52]
 

Originally by: CCP Oveur
Originally by: Alain Kinsella
Originally by: CCP Oveur

Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.


[bolded notable part.]

OK, that got me very curious. Sounds like you're considering some re-work of API after all? Question

As for the post itself, thanks. Though I saw the basic notes for this in the GD thread, its nice to have it fleshed out a bit more. Smile


EVE Gate and the API have been for many years and will continue be part of our strategy for world domination.

What we're experiencing now is that the backend to EVE for the API, EVE Gate etc. has to mature, be secure and scale before they can move forward. This will take a lot of time of trial and error and we are currently doing that through EVE Gate which is moving forward the bi-directional use of said backend (as opposed to the single-direction API).


What are your thoughts on sensible use of developer time invested in the API versus EVE Gate, where you get a huge magnification effect on actual end user experience improvement through developing the API further compared to developing EVE Gate?

Is a bi-directional API on the table? What timescale are you considering for making the current EVE Gate functionality available in real APIs for developers? Given the slow (Some would say abysmal) take-up of EVE Gate within the community, have your intentions changed on that project? Given the team of (10?) developers who took years to produce it, compared to the one-man-few-months-on-the-side approach that was all the API required, what realistically is the point in pouring considerable resources into EVE Gate or at least what is the justification for not providing similar resources to the API?

I'm genuinely curious and would love to strike up a conversation here, given that myself and others have spent the best part of two years trying to communicate our views to CCP and the result has been essentially silence.

It's nice to hear $words on how CCP wants to improve the API and such, but we old cynics (third party developers) have been hearing the same song for several years now with nearly no change whatsoever to the API since the first major iteration by CCP Garthagk back in the good 'ol days. I know I speak for a few when I say that we're a little tired of the song, and we could use a change.

Kyra Felann
Gallente
The Scope
Posted - 2010.08.18 20:47:00 - [53]
 

Man, I for one, would like a thin client. Text-only would be nice so I could log on to chat or something on my netbook or in a console window while doing something else.

Plus, I could pretend I was playing EVE MUD (TM).

CCP Oveur

Posted - 2010.08.18 20:51:00 - [54]
 

Originally by: Ix Forres
Originally by: CCP Oveur
Originally by: Alain Kinsella
Originally by: CCP Oveur

Pretty much. Also, we simply intend to provide the asynchronous and simplified functionality you are looking for on different platforms and you'll see it first on EVE Gate.

This is actually one of the main purposes for EVE Gate. It's the springboard for new platforms. Exposing EVE functionality for EVE Gate and the API means it's easier to extend to new platforms.


[bolded notable part.]

OK, that got me very curious. Sounds like you're considering some re-work of API after all? Question

As for the post itself, thanks. Though I saw the basic notes for this in the GD thread, its nice to have it fleshed out a bit more. Smile


EVE Gate and the API have been for many years and will continue be part of our strategy for world domination.

What we're experiencing now is that the backend to EVE for the API, EVE Gate etc. has to mature, be secure and scale before they can move forward. This will take a lot of time of trial and error and we are currently doing that through EVE Gate which is moving forward the bi-directional use of said backend (as opposed to the single-direction API).


What are your thoughts on sensible use of developer time invested in the API versus EVE Gate, where you get a huge magnification effect on actual end user experience improvement through developing the API further compared to developing EVE Gate?

Is a bi-directional API on the table? What timescale are you considering for making the current EVE Gate functionality available in real APIs for developers? Given the slow (Some would say abysmal) take-up of EVE Gate within the community, have your intentions changed on that project? Given the team of (10?) developers who took years to produce it, compared to the one-man-few-months-on-the-side approach that was all the API required, what realistically is the point in pouring considerable resources into EVE Gate or at least what is the justification for not providing similar resources to the API?

I'm genuinely curious and would love to strike up a conversation here, given that myself and others have spent the best part of two years trying to communicate our views to CCP and the result has been essentially silence.

It's nice to hear $words on how CCP wants to improve the API and such, but we old cynics (third party developers) have been hearing the same song for several years now with nearly no change whatsoever to the API since the first major iteration by CCP Garthagk back in the good 'ol days. I know I speak for a few when I say that we're a little tired of the song, and we could use a change.

The irony is that what took so long to get EVE Gate out is the backend work required to enable the bi-directional capabilities to Tranquility, making it scale, the associated quite hefty hardware investment in caching and other infrastructure is what will enable the API to move forward.

We wouldn't have started putting these resources on doing that had it not been for EVE Gate and then API would never have evolved to even remotely bi-directional.

So while you might not see or appreciate the long-term potential and ambition behind EVE Gate right now, it is paving the way for the API moving beyond something a "one-man-few-months-on-the-side" effort would have given.

My second point in my previous answer was also scalability and security. We canceled EVE Mobile, the first bi-directional interface to the cluster. Not because the client was difficult but because it could crash the Tranquility cluster, it could hack it, it could easily topple it with load. So the work required to get that part working was tremendous.

That's why doing it through EVE Gate first, creating the infrastructure around it is the prudent way of doing it.

So yeah, let's not hate EVE Gate, it's paving the way for many things which otherwise wouldn't have happened or would have happened much slower.

Trhamp Sthamp
Caldari
Robot Tech Labs
Posted - 2010.08.18 21:01:00 - [55]
 

That client is fine and dandy but why go through so much trouble describing it if we aren't actually going to use it? Hell, I'd use that client at work if I could use text commands to do most things. Even if I had to remain in a station, it's still useful. Imagine making a thin client like that to do skill swaps nearly anywhere or even update market orders and contracts.

-TS

Emo Dodo
Posted - 2010.08.18 21:10:00 - [56]
 

Since you have the control part of the client de-coupled - that surely could be the basis for leightweight clients? It is an awesom idea. Imagine for instance a client that weights only like 100mb, or streams whatever small art content it needs. It could accessed in a browser enviroment.

Ix Forres
Caldari
Righteous Chaps
Posted - 2010.08.18 21:14:00 - [57]
 

Originally by: CCP Oveur
Originally by: Ix Forres
What are your thoughts on sensible use of developer time invested in the API versus EVE Gate, where you get a huge magnification effect on actual end user experience improvement through developing the API further compared to developing EVE Gate?

Is a bi-directional API on the table? What timescale are you considering for making the current EVE Gate functionality available in real APIs for developers? Given the slow (Some would say abysmal) take-up of EVE Gate within the community, have your intentions changed on that project? Given the team of (10?) developers who took years to produce it, compared to the one-man-few-months-on-the-side approach that was all the API required, what realistically is the point in pouring considerable resources into EVE Gate or at least what is the justification for not providing similar resources to the API?

I'm genuinely curious and would love to strike up a conversation here, given that myself and others have spent the best part of two years trying to communicate our views to CCP and the result has been essentially silence.

It's nice to hear $words on how CCP wants to improve the API and such, but we old cynics (third party developers) have been hearing the same song for several years now with nearly no change whatsoever to the API since the first major iteration by CCP Garthagk back in the good 'ol days. I know I speak for a few when I say that we're a little tired of the song, and we could use a change.

The irony is that what took so long to get EVE Gate out is the backend work required to enable the bi-directional capabilities to Tranquility, making it scale, the associated quite hefty hardware investment in caching and other infrastructure is what will enable the API to move forward.

We wouldn't have started putting these resources on doing that had it not been for EVE Gate and then API would never have evolved to even remotely bi-directional.

So while you might not see or appreciate the long-term potential and ambition behind EVE Gate right now, it is paving the way for the API moving beyond something a "one-man-few-months-on-the-side" effort would have given.

My second point in my previous answer was also scalability and security. We canceled EVE Mobile, the first bi-directional interface to the cluster. Not because the client was difficult but because it could crash the Tranquility cluster, it could hack it, it could easily topple it with load. So the work required to get that part working was tremendous.

That's why doing it through EVE Gate first, creating the infrastructure around it is the prudent way of doing it.

So yeah, let's not hate EVE Gate, it's paving the way for many things which otherwise wouldn't have happened or would have happened much slower.


Okay, I accept that improving bidirectional intracluster communication infrastructure is a sensible move for CCP, and yes, the API requires infrastructure to be added for it to develop. But why choose EVE Gate as the prime mover when the API would have sufficed? "We're going to put 10 people on making this awesome IPC tech for the cluster to talk to the API" would've probably made far more people happier than "We're making Spacebook!".

My original question was really as to why the API has not been given the same or higher level of priority within CCP as EVE Gate when the end result for the playerbase is much, much more positive than EVE Gate. This isn't hating on EVE Gate- EVE Gate is very useful for me as someone who doesn't log in except for EVEmails, and I'm sure lots of people like it- but it is a statement of fact that we'd have achieved the same functionality ten times over with more bells and whistles on like IMAP/POP/SMTP to EVEmail gateways etc if it'd been done in APIs. And you'd have had less internal development time taken up with it, and if you wanted to make a website after the fact, your devs have all the APIs they need already!

Jason Edwards
Internet Tough Guy
Spreadsheets Online
Posted - 2010.08.18 21:49:00 - [58]
 

Release the thin client so we can use it?

CCP Oveur

Posted - 2010.08.18 21:54:00 - [59]
 

Edited by: CCP Oveur on 18/08/2010 21:55:05
Originally by: Ix Forres

Okay, I accept that improving bidirectional intracluster communication infrastructure is a sensible move for CCP, and yes, the API requires infrastructure to be added for it to develop. But why choose EVE Gate as the prime mover when the API would have sufficed? "We're going to put 10 people on making this awesome IPC tech for the cluster to talk to the API" would've probably made far more people happier than "We're making Spacebook!".

My original question was really as to why the API has not been given the same or higher level of priority within CCP as EVE Gate when the end result for the playerbase is much, much more positive than EVE Gate. This isn't hating on EVE Gate- EVE Gate is very useful for me as someone who doesn't log in except for EVEmails, and I'm sure lots of people like it- but it is a statement of fact that we'd have achieved the same functionality ten times over with more bells and whistles on like IMAP/POP/SMTP to EVEmail gateways etc if it'd been done in APIs. And you'd have had less internal development time taken up with it, and if you wanted to make a website after the fact, your devs have all the APIs they need already!

Sorry, was pretty sure I answered that, still at work and very tired. I'll try to be more clear.

EVE Mobile was something we controlled and bi-directional. It didn't justify the investment to the cluster.

API was born in the meantime out of the character sheet. It's usage is not under our control. We have learnt that it can easily crash the cluster in many shapes and form. And that's read only. It alone does not justify the cost in the cluster.

EVE Gate is something we control. It does justify the cost and investment in the cluster.

So it wasn't a choice between EVE Gate OR the API because EVE Gates purpose is far more than it's bi-directional connection to EVE. The choice was, "with this approach we can accelerate any devices bi-directional access to Tranquility while doing EVE Gate", which has to be done regardless. It could have been to "let's make EVE Gate" and not have the API benefit from this work.

So no, it isn't a statement of fact that you would have had evemail up and running faster had we put the EVE Gate team on just developing the API. You would have lots of more options and you could read a lot more data but it would most certainly not be a bi-directional service today.

Why? Because even after all this effort, the scalability and security is achieved in a very purpose built and controlled environment and considerable work is still required to turn all that work into an open API.

And I prefer finishing that work while minimizing risk to the Tranquility cluster.

I don't know how I can put it simpler than that and I hope it answered your question. If not, feel free to continue asking Wink

wr3cks
Reliables Inc
BricK sQuAD.
Posted - 2010.08.18 22:05:00 - [60]
 

These book reports on anti-lag efforts are interesting. We look forward to seeing the results.

Meanwhile, many of us are expecting some sort of update on content priorities:

When are you going to "iterate" PI? (clickclick clickclick clickclick...)

Has the relative priority of Eve:Walking in Vampires been reconsidered in light of the more numerous and pressing issues with current gameplay?


Pages: 1 [2] 3 4

This thread is older than 90 days and has been locked due to inactivity.


 


The new forums are live

Please adjust your bookmarks to https://forums.eveonline.com

These forums are archived and read-only