Thread: Developers Blog

In response to my devblog two weeks ago, Incarna, welcome to your future, there were some concerns raised on what kind of performance was to be expected, especially since the minimum hardware requirements for EVE are still pretty accomodating when it comes to old hardware.

Well, we always aimed at getting acceptable performance at what we consider acceptable visual standards in our supported hardware range. That goal has never changed. As we progressed in development we started hitting all of our targets for both high-end and medium spec machines while still making the entire thing look absolutely amazing.

But we have a bit of a unique situation to deal with that not all game developers have to take into account. People love EVE so much that they don‘t just want to play one EVE, they want to play two EVEs at once...and sometimes even more!

So the only place we really ran into trouble was with low-end machines and then only when running multiple clients in an Incarna environment. We still marched on and tried to squeeze all we could out of the graphics engine without making everything look like an 8-bit brick.

However we‘ve unfortunately hit a bit of a wall when it comes to running multiple clients on low-end machines while docked. For the sake of a smooth transition we therefore decided to temporarily add the option to not load the Incarna interiors while stilll retaining full access to all options and menus. This allows us to accomodate users with old and gnarly hardware, a group we‘ve been proud to be able to serve in the past, while for some limited time also develop for those with top-of-the-line gaming computers.

This simple option will primarily benefit players with Nvidia 6000 series, or low-end 7000 series cards or compatible hardware, trying to run multiple clients while docked.

To highlight this and to future proof ourselves a bit we‘re in the process of revising and updating the EVE minimum and reccommended hardware specification.

Again, to be really clear; running a single client works fine on all hardware supported by us. This is a temporary solution for your convenience that we intend to solve more gracefully in future deployments. We are still determined to make Incarna a seamless part of the EVE experience so that one day there will be no Incarna, there will only be EVE.

Arnar Hrafn Gylfason

Senior Producer of EVE Online











More...

Monetizing 3rd Party Apps

tr.v. mon·e·tized, mon·e·tiz·ing, mon·e·tiz·es

• To establish as legal tender.
• To coin (money).
• To convert (government debt) from securities into currency that can be used to purchase goods and services.
• Cha-Ching.

At this year's Fanfest CCP hosted the first Dev Track in what we hope will be a regular event. To kick off the event I gave an exciting announcement about monetization, which has up to this point been a sore point for EVE Online 3rd party software development, since it has been against the ToS to charge for applications or services which use the EVE Online Intellectual Property.

Starting this summer you will be able to charge people for usage of your applications, websites and services for EVE Online.

This new system was introduced at the Dev Track and discussed at the Fanfest round tables. We got a lot of good feedback at Fanfest and would like to get more before finalizing the service.

Highlights

• Simple process - Sign up on a webpage, get started straight away
• Inexpensive - $99 per year, no other fees
• Developer-friendly - Very few restrictions
• Open-ended - You can charge subscription fees, receive donations, sell your app in an app-store and more
• Non-commercial websites and apps will now require a (free) license

Grueling legal details

• CCP will license 3rd party developers to create commercial applications and services created using the EVE API, In-Game Browser, Static Data Export, Image Export and Eve Image server.
• To become a licensee, developer must enter into a commercial license agreement with CCP. The fee for a commercial license is $99, payable annually by credit card or wire transfer (for identification purposes). We do not require further payments from developer or royalties.
• Developer can choose how they monetize their app or service, provided that they conform with the EVE EULA and ToS. Examples of monetization could be donations, one-time purchase, in-app purchase, subscriptions or ad-supported sites or apps.
• For ad-supported ventures, we require that licensed applications or services not be associated with ISK selling/buying, macros or bots. An example of unacceptable monetization would be accepting Google AdWords from sites violating our EULA and ToS. (this is essentially similar to our terms for fansites)
• CCP may at its discretion, list developers' application or service, and provide other publicity.
• Developer may not market their application or service as being associated with CCP in any way, other than to include a logo and credit line identifying application or service as a licensed application for EVE. Or similar attribution as may be required by CCP from time to time.
• We will continue to provide technical assistance via the Technology Lab forum and IRC channel, but CCP does not offer formal technical support to developers or warrant the API in any way. It's provided as is.
• 3rd Party applications and services may not accept PLEX.
• CCP also allows non-commercial apps and services, subject to simple clickwrap agreement substantially similar to the one that is provided to registered fansites.

Questions

Here are some questions that we have received so far. Please use the feedback thread to add your own questions about this program and we will do our best to answer them and add them to this list.

Will corporation and alliance websites require a commercial license?

No, private websites do not need a license. However, if you have an external facing part of the website that uses the EVE IP you will require a non-commercial or a commercial license, depending on your use.

Will services for in-game currency require a commercial license?

Yes, if you require any sort of payment for your services you will need a commercial license.

Will website ads require a commercial license?

Yes, for ad-supported websites you will require a commercial license.

Will donations require a commercial license?

Yes, for donation supported websites you will require a commercial license.

Will I be able to charge real life currency for in game services?

No, the commercial license does not allow you to charge real life money for any in-game services.

Why charge for the license at all?

The licensing fee is there to partially cover expenses from this initiative and more importantly, we need to charge a fee so that we get proper non-spoofable information about the applicant. We have kept the fee as low as possible and hope that the $99 fee is low enough to not dissuade serious developers from participating in the program.

When will this happen?

This program is something we're hoping to get up and running this summer so if things go well, you'll be able to sign up in the next few months (as always though, we can't make any promises).

The feedback to this blog is an important input into the process of finalizing the details.

Parting words

That's about it. This is a pretty simple program and hopefully it will help you convincing your significant other that developing applications for a space game until 3am in the morning is a good idea.

For us at CCP this is an important step in getting more exposure of the tremendous possibilities that the various hooks into the game provide.

I'm sure we will have plenty to talk about in the discussion thread. :-)

Jon Bjarnason
Technical Director
EVE Online, CCP Games









More...

Monetizing 3rd Party Apps

tr.v. mon·e·tized, mon·e·tiz·ing, mon·e·tiz·es

• To establish as legal tender.
• To coin (money).
• To convert (government debt) from securities into currency that can be used to purchase goods and services.
• Cha-Ching.

At this year's Fanfest CCP hosted the first Dev Track in what we hope will be a regular event. To kick off the event I gave an exciting announcement about monetization, which has up to this point been a sore point for EVE Online 3rd party software development, since it has been against the ToS to charge for applications or services which use the EVE Online Intellectual Property.

Starting this summer you will be able to charge people for usage of your applications, websites and services for EVE Online.

This new system was introduced at the Dev Track and discussed at the Fanfest round tables. We got a lot of good feedback at Fanfest and would like to get more before finalizing the service.

Highlights

• Simple process - Sign up on a webpage, get started straight away
• Inexpensive - $99 per year, no other fees
• Developer-friendly - Very few restrictions
• Open-ended - You can charge subscription fees, receive donations, sell your app in an app-store and more
• Non-commercial websites and apps will now require a (free) license

Grueling legal details

• CCP will license 3rd party developers to create commercial applications and services created using the EVE API, In-Game Browser, Static Data Export, Image Export and Eve Image server.
• To become a licensee, developer must enter into a commercial license agreement with CCP. The fee for a commercial license is $99, payable annually by credit card or wire transfer (for identification purposes). We do not require further payments from developer or royalties.
• Developer can choose how they monetize their app or service, provided that they conform with the EVE EULA and ToS. Examples of monetization could be donations, one-time purchase, in-app purchase, subscriptions or ad-supported sites or apps.
• For ad-supported ventures, we require that licensed applications or services not be associated with ISK selling/buying, macros or bots. An example of unacceptable monetization would be accepting Google AdWords from sites violating our EULA and ToS. (this is essentially similar to our terms for fansites)
• CCP may at its discretion, list developers' application or service, and provide other publicity.
• Developer may not market their application or service as being associated with CCP in any way, other than to include a logo and credit line identifying application or service as a licensed application for EVE. Or similar attribution as may be required by CCP from time to time.
• We will continue to provide technical assistance via the Technology Lab forum and IRC channel, but CCP does not offer formal technical support to developers or warrant the API in any way. It's provided as is.
• 3rd Party applications and services may not accept PLEX.
• CCP also allows non-commercial apps and services, subject to simple clickwrap agreement substantially similar to the one that is provided to registered fansites.

Questions

Here are some questions that we have received so far. Please use the feedback thread to add your own questions about this program and we will do our best to answer them and add them to this list.

Will corporation and alliance websites require a commercial license?

No, private websites do not need a license. However, if you have an external facing part of the website that uses the EVE IP you will require a non-commercial or a commercial license, depending on your use.

Will services for in-game currency require a commercial license?

Yes, if you require any sort of payment for your services you will need a commercial license.

Will website ads require a commercial license?

Yes, for ad-supported websites you will require a commercial license.

Will donations require a commercial license?

Yes, for donation supported websites you will require a commercial license.

Will I be able to charge real life currency for in game services?

No, the commercial license does not allow you to charge real life money for any in-game services.

Why charge for the license at all?

The licensing fee is there to partially cover expenses from this initiative and more importantly, we need to charge a fee so that we get proper non-spoofable information about the applicant. We have kept the fee as low as possible and hope that the $99 fee is low enough to not dissuade serious developers from participating in the program.

When will this happen?

This program is something we're hoping to get up and running this summer so if things go well, you'll be able to sign up in the next few months (as always though, we can't make any promises).

The feedback to this blog is an important input into the process of finalizing the details.

Parting words

That's about it. This is a pretty simple program and hopefully it will help you convincing your significant other that developing applications for a space game until 3am in the morning is a good idea.

For us at CCP this is an important step in getting more exposure of the tremendous possibilities that the various hooks into the game provide.

I'm sure we will have plenty to talk about in the discussion thread. :-)

Jon Bjarnason
Technical Director
EVE Online, CCP Games













More...

Monetizing 3rd Party Apps

tr.v. mon·e·tized, mon·e·tiz·ing, mon·e·tiz·es

• To establish as legal tender.
• To coin (money).
• To convert (government debt) from securities into currency that can be used to purchase goods and services.
• Cha-Ching.

At this year's Fanfest CCP hosted the first Dev Track in what we hope will be a regular event. To kick off the event I gave an exciting announcement about monetization, which has up to this point been a sore point for EVE Online 3rd party software development, since it has been against the ToS to charge for applications or services which use the EVE Online Intellectual Property.

Starting this summer you will be able to charge people for usage of your applications, websites and services for EVE Online.

This new system was introduced at the Dev Track and discussed at the Fanfest round tables. We got a lot of good feedback at Fanfest and would like to get more before finalizing the service.

Highlights

• Simple process - Sign up on a webpage, get started straight away
• Inexpensive - $99 per year, no other fees
• Developer-friendly - Very few restrictions
• Open-ended - You can charge subscription fees, receive donations, sell your app in an app-store and more
• Non-commercial websites and apps will now require a (free) license

Grueling legal details

• CCP will license 3rd party developers to create commercial applications and services created using the EVE API, In-Game Browser, Static Data Export, Image Export and Eve Image server.
• To become a licensee, developer must enter into a commercial license agreement with CCP. The fee for a commercial license is $99, payable annually by credit card or wire transfer (for identification purposes). We do not require further payments from developer or royalties.
• Developer can choose how they monetize their app or service, provided that they conform with the EVE EULA and ToS. Examples of monetization could be donations, one-time purchase, in-app purchase, subscriptions or ad-supported sites or apps.
• For ad-supported ventures, we require that licensed applications or services not be associated with ISK selling/buying, macros or bots. An example of unacceptable monetization would be accepting Google AdWords from sites violating our EULA and ToS. (this is essentially similar to our terms for fansites)
• CCP may at its discretion, list developers' application or service, and provide other publicity.
• Developer may not market their application or service as being associated with CCP in any way, other than to include a logo and credit line identifying application or service as a licensed application for EVE. Or similar attribution as may be required by CCP from time to time.
• We will continue to provide technical assistance via the Technology Lab forum and IRC channel, but CCP does not offer formal technical support to developers or warrant the API in any way. It's provided as is.
• 3rd Party applications and services may not accept PLEX.
• CCP also allows non-commercial apps and services, subject to simple clickwrap agreement substantially similar to the one that is provided to registered fansites.

Questions

Here are some questions that we have received so far. Please use the feedback thread to add your own questions about this program and we will do our best to answer them and add them to this list.

Will corporation and alliance websites require a commercial license?

No, private websites do not need a license. However, if you have an external facing part of the website that uses the EVE IP you will require a non-commercial or a commercial license, depending on your use.

Will services for in-game currency require a commercial license?

Yes, if you require any sort of payment for your services you will need a commercial license.

Will website ads require a commercial license?

Yes, for ad-supported websites you will require a commercial license.

Will donations require a commercial license?

Yes, for donation supported websites you will require a commercial license.

Will I be able to charge real life currency for in game services?

No, the commercial license does not allow you to charge real life money for any in-game services.

Why charge for the license at all?

The licensing fee is there to partially cover expenses from this initiative and more importantly, we need to charge a fee so that we get proper non-spoofable information about the applicant. We have kept the fee as low as possible and hope that the $99 fee is low enough to not dissuade serious developers from participating in the program.

When will this happen?

This program is something we're hoping to get up and running this summer so if things go well, you'll be able to sign up in the next few months (as always though, we can't make any promises).

The feedback to this blog is an important input into the process of finalizing the details.

Parting words

That's about it. This is a pretty simple program and hopefully it will help you convincing your significant other that developing applications for a space game until 3am in the morning is a good idea.

For us at CCP this is an important step in getting more exposure of the tremendous possibilities that the various hooks into the game provide.

I'm sure we will have plenty to talk about in the discussion thread. :-)

Feeback thread discussion



thank you all for your input so far. Based on your comments, I feel I should step in to clarify a few things and address some concerns.

1) The blog represents the first draft of what our bizdev department is thinking of in terms of the license agreement. We published it to get feedback from you guys. This is not the final word on the matter and we want to build this service up with you so that it's fair and empowers you to build these applications and services which better the game.

2) Regarding this clause: Q: Will services for in-game currency require a commercial license? A: Yes, if you require any sort of payment for your services you will need a commercial license. I've spoken to Biz Dev and this is something that might be revised, possibly to exclude ISK payments. I'll let you know as soon as I know more.

3) This project is not about CCP making money. Whether we charge $100 or $50 or $10 for a commercial license won't make a big difference to our balance sheet. $99 is the lowest that we estimated that we could reasonably go and still justify the cost of the service. If this is too high for app developers, this is something that could possibly be revisited.

4) Nothing is set in stone. We're willing to reconsider anything you deem unfair about the program. Donation and ad supported ventures is a tricky thing to allow without any sort of a commercial license though and that's a legal slippery slope. Whether that license needs to be $99 per year is something we might reconsider.

Please help us by continuing to give constructive feedback into how you want this service to be since our motives are really to empower 3rd party development and not to try to squeeze money out of starving programmers.

Our Biz Dev department will give us some more answers and clarify ambiguity. Rest assured this will change to suit your needs and our aim is to make you want to develop software and services for EVE and not to throw obstacles in your way.

Jon Bjarnason
Technical Director
EVE Online, CCP Games













More...

Team Gridlock continues to work hard against the demons of fleet lag and could-do-better code. At the end of April we activated a couple of optimisations on Tranquility, and now we've had a few weeks of operation, we can see some measurable results. After sharing these results with the CSM during their recent summit visit, we decided to release them to an even wider audience. So, stand by for some more graph-and-pseudo-code porn.
First a graph, because everybody loves graphs:

Click image to enlarge
What I'm showing here is the CPU-per-User metric across all Tranquility server nodes over a period of eight weeks. The vertical scale is of somewhat arbitrary units, but is consistent providing the hardware remains constant. This metric basically shows how much computer power we are burning for each connected user at any given time. The lower this number gets, the better. The red horizontal lines show the trend before and after the changes, whilst the blue lines show the dates of the changes. The changes are labelled by the actual names of the flags we used in the code. (This dev-blog itself is based on an internal report I wrote-up, so I'm going to keep it as similar as possible)
Each flag enables a particular optimisation, without requiring a patch to the server. This is good as we can turn on the flag for a subset of nodes and then monitor those closely for undesirable fallout, before later turning it on cluster-wide.
The flags

On April 26^th, we activated a server flag 'ballparkUsesInventorySelfLocal'. In the days after this change, the CPU-per-User metric across the whole cluster dropped by approximately 8%. This is a pretty nice win, for what was actually a very small change in terms of lines-of-code altered. (There was still quite a lot of work homing in to figure out the change in the first place, and then a fair bit of testing and profiling afterwards to verify it)
On May 2^nd we activated a server flag 'crimewatchUsesInventorySelfLocal'. This didn't make much change to the overall CPU-per-User, but that is expected. I expect the gains from this flag would only be noticeable in the specific cases of fleet-fights and low-sec, so they won't show up when averaged across the whole cluster.
If all you're interested in is seeing that we're still making progress in The War Against Lag, then you can stop reading here. The graph above shows everything you need to know. The hamsters are 8% happier. If you're more curious about what actually changed, keep going.
A moniker primer

Both changes were along the same theme: Replacing a moniker to a bound-object with a direct reference to that object. What does that mean? Well, gather around the whiteboard. I'm going to explain a lot of stuff, and then show why getting rid of that stuff is sometimes a good thing to do.
The main communication mechanism between server components is via monikers and bound-objects. A moniker is a handle to a bound-object. A bound-object is a frontend to a component, and is responsible for keeping track of how many monikers are pointing to it. This is basically an implementation of the proxy design pattern.
Things get interesting when you realise that the moniker and the bound-object can be in different processes. They can even be on different server nodes. (The Tranquility server cluster is currently made up of around 200 nodes.) In fact, they can even be on opposite sides of the Earth - your EVE client uses the same tools for interacting with objects on our servers. Programmers will recognise this as an implementation of an RPC mechanism. This is great as it means we can distribute logical parts of the server on to different nodes, and they can communicate using a programming interface that is almost identical to if they were on the same node. Monikers do come with a performance cost however - every access through a moniker requires a few extra checks and look-ups compared to a regular function call. This overhead is because of the extra features that monikers provide, such as lifetime-management (what happens if either end of the connection goes down, or one of the objects is destroyed?), call synchronisation (I can make sure that there are never two concurrent calls into the same bound-object, for example), and per-function permission controls (any user can call function A, but only a GM can call function B)

The diagram above shows a generic object 'ServiceObject' that is being accessed by two user objects. Each access is via a Moniker, and all the incoming Moniker connections are looked after by a BoundObject interface. The black arrows indicate the logical connections, which could either be in the same memory space, between machines in the same local network, or ever across the internet.
Putting it into action

Within the server, each solar system is handled by a number of inter-related components. The three components related to this discussion are called Ballpark, CrimewatchLocation and InventoryLocation. For each solar system, there is a particular instance of each of these. Ballpark handles stuff in space (such as the Destiny physics engine, sending state updates to clients, jumping through gates and lots more). CrimewatchLocation tracks aggression-flagging, war rules, kill-mails and CONCORD spawning. InventoryLocation tracks what item is located where, and acts as a front-end to the item database.
The InventoryLocation for a given solarsystem is available from any other node via a moniker, providing you know the ID of the node hosting it, and have suitable permissions. The Ballpark and CrimewatchLocation game systems were using this facility, and accessing the InventoryLocation via a moniker object.

This diagram shows the connection between the Ballpark, CrimewatchLocation and InventoryLocation objects before and after the change. In the before case, the moniker connections were constrained to being in the same process due to shared dependencies on other objects.
This is great. At first glance the desirable approach might be to move each component onto its own node, attempting to make gains via parallelism. However, for any solar system, these three components have always lived together on the same node. Over time they have grown roots into each other via other, non-monikered, components. As such, separating them out is a major undertaking. In effect, Ballpark, CrimewatchLocation and InventoryLocation have become such close friends that they share a few organs. They are also very chatty between each other, so without significant restructuring, the communications overhead of their interactions might massively outweigh any savings due to parallelism.
Refactoring to eliminate these links is still something we want to do, but there are other, lower-hanging fruit that can give us good bang-for-buck.
The fix

So, we have three components communicating via an RPC mechanism, yet they always live together. After establishing that the overhead of going through monikers was noticeable, I set about removing this intermediate step. Changing the moniker to a direct reference was easy enough - it already has functionality to do that.
Here's what the change looked like
Before:
At initialisation:

# Get the moniker to an inventory location:
inv = GetInventoryMoniker(solarsystemID) During runtime:

# Use the inventory to get stuff from the DB:
item = inv.SelectItem(itemID) After:
At initialisation:

# Get the direct reference to an inventory location:
inv = GetInventoryMoniker(solarsystemID).GetSelfLocal() During runtime:

# Use the inventory to get stuff from the DB:
item = inv.SelectItem(itemID) That's it. Fifteen extra characters, which disable a piece of functionality, for an 8% saving across the cluster. Not bad, huh?
The fix for the fix

But wait! Remember how I mentioned earlier that moniker also does some useful things in addition to providing an RPC mechanism, such as lifetime management by reference-counting? Bound-objects only live as long as there are monikers somewhere in the world referencing them. Take away the last moniker and the bound-object is cleaned-up and removed. This was a problem we discovered during testing. It turns out that CrimewatchLocation's moniker to InventoryLocation was the only thing keeping it alive. This led to some strange bugs where a solar system would be fine as long as someone had aggression flags, but once there was nothing for CrimewatchLocation to do, a sequence of events would lead to InventoryLocation shutting down even if Ballpark was still using it via a direct reference.
Once we'd found and fixed this issue, we went through a series of mass-tests with the flags enabled, and also let it soak on Singularity for a while to flush out any other edge cases.
Conclusion

Once we had satisfactorily finished the testing phase, these changes were deployed to Tranquility in an inert state. At the end of April, we had a quiet week (in that no hotfix changes were scheduled for release) and so activated the changes - firstly to Ballpark on 26^th April, and then to CrimewatchLocation on 2^nd May. We chose this time because the lack of any other changes meant we could observe any gain (and possibly any fallout) in isolation, and easily revert by disabling one or both optimisation flags.
After a few days, the numbers on the CPU-per-user graph were looking good, and we hadn't seen any adverse issues. A few weeks later, we had enough data to make the claim of a cluster-wide 8% saving from just an extra 30 characters of code (not counting fixing up some object-lifetime issues). Pretty good, huh?
This story is an example of some of the work that Gridlock does. We also do things like organise the mass-tests, profile up-and-coming features from other teams to make sure we're not going backwards, and look to the future with plans such as improved live-remapping (where we take a solar system featuring a fleet-fight, and move it on to a dedicated node) and Time Dilation.





More...

Hello space ladies and gents
The security of the forum package we delivered to you in April was regrettably not as bulletproof as we had hoped. Though we were fortunate not to suffer any damage, I want to extend an apology on behalf of all of us that worked on the new forums.
Our trusted Senior Security Administrator, CCP Sreegs, did a great job of explaining in his dev blog the extent to which the "new forum exploit" compromised security. In a following blog, CCP Rhayger walked readers through the reasons why we went with the YAF software solution as a base for our new EVE Online forums. The difficulties we had with our new forum system led to some soul-searching and prompted us to bring our internal and external processes under comprehensive scrutiny. We immediately set to work to fix the problem at hand and gulped down the helpful medicine of your feedback.
In this blog, I want to introduce you to some improvements we are rolling out with this rerelease of the new EVE forums that you can try out now on testforums.evegate.com.
In the unlikely event that you encounter any security issues as you explore the new forums, please send an email to security@ccpgames.com and file a bug report. Please note two things that are paramount to us having the information we need to respond to your security feedback:

1. Please provide us with details regarding the issue, including reproduction steps when possible.
2. You must not abuse an exploit should you discover one, whether as a "prank" or otherwise. CCP is a corporation and we must treat all exploitation of our corporate assets with extreme seriousness. What may be humorous to you may also be a crime in whatever country you're pulling your masterful prank from.

For more of CCP's Sreegs advice on how to file a good bug report, please go to his dev blog.
New Forum features
In addition to addressing the security issues with the "old new" forums, we took some time to squeeze in changes based on your feedback. We are rolling out some UI improvements that we hope make for a better user experience for you on the new EVE forums.



Beside your Normal view that we introduced in our last release, you now have an option to view threads in a Compact view (above). These settings are located in the thread title bar where you can easily switch between them. Once you set your view of choice, it stays that way until you change it again. The avatar image has been reduced from size 128x128 to 64x64 and all other character information can be accessed by clicking the user name, which takes me to the next feature I want to tell you about: the Character Dropdown List.



When clicking on the character name, you will get a dropdown list of handy links and information to help you keep in contact and follow your forum friends and trolls. With one simple click, you can send an EVE Mail to a forum user, show all of his/her forum posts or go directly to their EVE Gate profiles. The dropdown list shows you the name and logo of the Corporation/Alliance he or she is a member of and the number of Likes the user has received overall. It also provides the next feature on my list: the ability to HIDE posts (image below) from characters that you simply don't wish to see.



By clicking "Hide posts" in the Character Dropdown List, all posts by this specific user will appear hidden on the forums. Yes, you heard me right. If someone is leaving you steaming and stomping every time you go onto the forums, you can simply HIDE the user's posts. The posts will then appear collapsed. You will see if the hidden user posts a reply in a thread and can choose to read it by clicking "View post". If you feel ready to unhide the posts you can click "Show posts" which will then make all posts by that user visible again.
In addition, based on your feedback, we did a lot of UI tweaks touching font size and color, quotes, buttons, design and performance. We will be adding more requested features in the future. I can safely say that we have some pretty nifty things up our sleeves for you.
Deployment schedule and migration
The current (AKA original) EVE forums will remain on eveonline.com in an archived state for read-only reference. There will be a grace period between the opening the new forums and freezing the old ones, giving you advance notice for when the migration will happen. Exact dates are TBA; we will keep you posted on the exact time of when the old forums will close.
We hope you will join us for the public testing. If everything goes smoothly we are scheduled to release the new forums to EVE Gate again within the next few weeks. Keep providing us with your much appreciated feedback!
Cheers,
CCP Elais









More...

Monetizing 3rd Party Apps

tr.v. mon·e·tized, mon·e·tiz·ing, mon·e·tiz·es

• To establish as legal tender.
• To coin (money).
• To convert (government debt) from securities into currency that can be used to purchase goods and services.
• Cha-Ching.

At this year's Fanfest CCP hosted the first Dev Track in what we hope will be a regular event. To kick off the event I gave an exciting announcement about monetization, which has up to this point been a sore point for EVE Online 3rd party software development, since it has been against the ToS to charge for applications or services which use the EVE Online Intellectual Property.
Starting this summer you will be able to charge people for usage of your applications, websites and services for EVE Online.
This new system was introduced at the Dev Track and discussed at the Fanfest round tables. We got a lot of good feedback at Fanfest and would like to get more before finalizing the service.
Highlights

• Simple process - Sign up on a webpage, get started straight away
• Inexpensive - $99 per year, no other fees
• Developer-friendly - Very few restrictions
• Open-ended - You can charge subscription fees, receive donations, sell your app in an app-store and more
• Non-commercial websites and apps will now require a (free) license

Grueling legal details

• CCP will license 3rd party developers to create commercial applications and services created using the EVE API, In-Game Browser, Static Data Export, Image Export and Eve Image server.
• To become a licensee, developer must enter into a commercial license agreement with CCP. The fee for a commercial license is $99, payable annually by credit card or wire transfer (for identification purposes). We do not require further payments from developer or royalties.
• Developer can choose how they monetize their app or service, provided that they conform with the EVE EULA and ToS. Examples of monetization could be donations, one-time purchase, in-app purchase, subscriptions or ad-supported sites or apps.
• For ad-supported ventures, we require that licensed applications or services not be associated with ISK selling/buying, macros or bots. An example of unacceptable monetization would be accepting Google AdWords from sites violating our EULA and ToS. (this is essentially similar to our terms for fansites)
• CCP may at its discretion, list developers' application or service, and provide other publicity.
• Developer may not market their application or service as being associated with CCP in any way, other than to include a logo and credit line identifying application or service as a licensed application for EVE. Or similar attribution as may be required by CCP from time to time.
• We will continue to provide technical assistance via the Technology Lab forum and IRC channel, but CCP does not offer formal technical support to developers or warrant the API in any way. It's provided as is.
• 3rd Party applications and services may not accept PLEX.
• CCP also allows non-commercial apps and services, subject to simple clickwrap agreement substantially similar to the one that is provided to registered fansites.

Questions
Here are some questions that we have received so far. Please use the feedback thread to add your own questions about this program and we will do our best to answer them and add them to this list.
Will corporation and alliance websites require a commercial license?
No, private websites do not need a license. However, if you have an external facing part of the website that uses the EVE IP you will require a non-commercial or a commercial license, depending on your use.
Will services for in-game currency require a commercial license?
Yes, if you require any sort of payment for your services you will need a commercial license.
Will website ads require a commercial license?
Yes, for ad-supported websites you will require a commercial license.
Will donations require a commercial license?
Yes, for donation supported websites you will require a commercial license.
Will I be able to charge real life currency for in game services?
No, the commercial license does not allow you to charge real life money for any in-game services.
Why charge for the license at all?
The licensing fee is there to partially cover expenses from this initiative and more importantly, we need to charge a fee so that we get proper non-spoofable information about the applicant. We have kept the fee as low as possible and hope that the $99 fee is low enough to not dissuade serious developers from participating in the program.
When will this happen?
This program is something we're hoping to get up and running this summer so if things go well, you'll be able to sign up in the next few months (as always though, we can't make any promises).
The feedback to this blog is an important input into the process of finalizing the details.
Parting words
That's about it. This is a pretty simple program and hopefully it will help you convincing your significant other that developing applications for a space game until 3am in the morning is a good idea.
For us at CCP this is an important step in getting more exposure of the tremendous possibilities that the various hooks into the game provide.
I'm sure we will have plenty to talk about in the discussion thread. :-)
Feeback thread discussion

thank you all for your input so far. Based on your comments, I feel I should step in to clarify a few things and address some concerns.
1) The blog represents the first draft of what our bizdev department is thinking of in terms of the license agreement. We published it to get feedback from you guys. This is not the final word on the matter and we want to build this service up with you so that it's fair and empowers you to build these applications and services which better the game.
2) Regarding this clause: Q: Will services for in-game currency require a commercial license? A: Yes, if you require any sort of payment for your services you will need a commercial license. I've spoken to Biz Dev and this is something that might be revised, possibly to exclude ISK payments. I'll let you know as soon as I know more.
3) This project is not about CCP making money. Whether we charge $100 or $50 or $10 for a commercial license won't make a big difference to our balance sheet. $99 is the lowest that we estimated that we could reasonably go and still justify the cost of the service. If this is too high for app developers, this is something that could possibly be revisited.
4) Nothing is set in stone. We're willing to reconsider anything you deem unfair about the program. Donation and ad supported ventures is a tricky thing to allow without any sort of a commercial license though and that's a legal slippery slope. Whether that license needs to be $99 per year is something we might reconsider.
Please help us by continuing to give constructive feedback into how you want this service to be since our motives are really to empower 3rd party development and not to try to squeeze money out of starving programmers.
Our Biz Dev department will give us some more answers and clarify ambiguity. Rest assured this will change to suit your needs and our aim is to make you want to develop software and services for EVE and not to throw obstacles in your way.
Addendum from CCP Guard: Don't miss CCP Zulu's update regarding your feedback in this post
Jon Bjarnason
Technical Director
EVE Online, CCP Games







More...

Hello again! How have you been?
I for one have had an eventful year and a half, to say the least, but let's not get into that here. I'll see if I can hack the whole story into a slideshow next Fanfest, worst case you buy me a beer and I spill my guts.
Anyway. We just want to give you some information about the coming release, Incarna, where we'll be deploying a few updates to the API. These updates are likely to affect your applications, my apologies for how late you're getting this information as we have been extremely busy little bees lately, and writing this up kinda fell through the cracks.

Bigger Data
As you probably know from reading recent devblogs, our data-hamsters have been changing datatypes here and there in order to extend the capacity of various datasets. This is of course something we have to follow up on in the API, and you too if you're working in a strongly typed environment or your application has anything limiting these variables' sizes, e.g. validation logic. So here are the changes by pages:
MarketOrders - orderID is now a 64bit integer instead of 32, and typeID is now a 32bit integer instead of 16.
WalletTransactions - transactionID is now a 64bit integer instead of 32. This applies to both char/ and corp/ pages, .csv and .xml.

Smaller Data
MarketOrders will now only return a list of active and non-expired orders. This call was fetching way too much information from the datastore and we decided to alter the query in a simple way, filtering out all expired and processed orders. This is potentially a big change but we figured most people are calling this to watch their active orders and for historic information they get their transactions. We're also quite sure that you'll let us know if we're wrong, as you always so diligently do.

Transaction Walking
As you may or may not know, we've refactored the inner workings of the transaction walker which is used on all the WalletTransactions pages to page back through transactions. The new implementation had a problem where getting the latest transactions had a "speed limit". If you or your corporation produced more than X transactions between cache refreshes then the API would only give you the oldest X of those. Now, on the other hand, the API will give you the latest X and then you can page back to get the rest of the latest transactions.

Error Throttling
We are constantly looking at how we can make the API run better and ensure a consistent quality of service. Usually we look inside the API at how it queries and caches data, but this time we took a look at it from the outside, specifically how erroneous API traffic is affecting the API's performance. Turns out there is a substantial amount of calls creating errors that can be avoided so we came up with a way to minimize them. It is quite simple and works like this: If your IP produces X errors in Y minutes the API will block you for Z minutes. If your IP gets blocked then you'll get an error message with the new error code 904, it would look something like this:

2011-06-21 13:18:52
Your IP address has been temporarily blocked because it is causing too many errors. See the cacheUntil timestamp for when it will be opened again. IPs that continually cause a lot of errors in the API will be permanently banned, please take measures to minimize problematic API calls from your application.
2071-06-21 13:21:50
We are going to be pretty strict about this but we'll ease up on it if the forums catch fire. The basic theory we used here is that if nobody is complaining then we're not strict enough. It's the same thing governments use when introducing new taxes - to find a good balance you need to be able to measure! So we're going to start with: if your IP passes 3 errors a minute your IP gets blocked for 3 minutes. We decided against 60 year blocks as the example above suggests, we're not sure our servers have that kind of an up- and/or life-time, although they are doing wonderful things with hot-swapping these days.
Note that the IP will NOT be blocked in the game itself or on other websites. The throttling only applies to the API.
The Error Throttling may very well affect your application, especially if it is fetching a lot of data from the API for many different players and corporations. By doing this we aim to protect the API from erroneous traffic that can be avoided by forcing 3rd party developers to design their applications in a way that minimizes repeated calls that return errors. This means better quality of service for everyone so we hope this will be well received by the masses.

At the time I'm writing this, we've deployed this to the SISI API so that you can test the changes. Note that this version will NOT support Customizable API Keys because we are not deploying that in this release. After the release we'll integrate the CAK back into the API and set that up on SISI so you should have plenty of time to play around with it until its late August release.
I think that's it for now. Again, my apologies for the tardiness of this blog, the Error Throttling alone may take time to tackle but that's something we can easily tune down for a while if you're having problems running your applications.
Happy coding!

- CCP Elerhino






More...

With the ninth alliance tournament drawing to a close this weekend, we in research wanted to take a look at the last four and see exactly how much of what has been blown up over the years. With over 2,400 people taking part in the last four tournaments and over 4,500 kill reports registered with CONCORD, there's quite a lot to dig into!
So, without further ado...

Tournament	5	6	7	8	Total
Assault Ship	9	87	108	36	240
Battlecruiser	39	99	207	131	476
Battleship	87	131	198	110	526
Black Ops			12	3	15
Capsule	7	11	23	23	64
Combat Recon Ship	34	29	121	69	253
Command Ship	5	86	119	91	301
Cruiser	194	333	123	35	685
Destroyer	4	4	99	46	153
Electronic Attack Ship	17	62	87	27	193
Force Recon Ship	3	3	5	2	13
Frigate	171	126	106	126	529
Heavy Assault Ship	51	144	115	11	321
Heavy Interdictor			2	1	3
Industrial			11	5	16
Interceptor	6	11	52	30	99
Interdictor	1	1	31	55	88
Logistics	60	3	94	107	264
Marauder	5	19	34	5	63
Stealth Bomber	35	24	13	74	146
Strategic Cruiser			46	64	110
Totals	728	1,173	1,606	1,051	4,558

Ships destroyed by ship group for tournaments 5 through 9.
Cruisers were by far the favourite damage dealing component of tournament groups in tournaments five and six, but with changes to the points system this swapped over to both battlecruisers and battleships for seven and eight. Frigates have consistently been very popular "filler" ships to use up any remaining points and ensure each team has as many pilots as they can field. The substantial spike in tournament seven could be attributed to the rule changes implemented in that tournament, such as the restriction of only allowing a maximum of two of the same ship type in each fight. This made creating strategies much more complex, helping create some additional carnage.

Tournament	5	6	7	8	Total
Griffin	119	63	59	7	248
Ishtar	32	98	69	6	205
Drake	23	55	63	44	185
Ishkur	6	75	66	25	172
Rook	16	14	74	41	145
Abaddon	19	43	53	15	130
Kitsune	15	46	55	11	127
Caracal Navy Issue		91	30		121
Hurricane	4	22	37	47	110
Stabber Fleet Issue	1	88	16		105

Top ten ship types destroyed throughout the tournaments.
ECM ships have been popular through these tournaments, as can be seen from the Griffin, Rook and Kitsune all being in the top ten. These ships are known for their very powerful ECM bonuses. Which makes sense; if an enemy can't target you their options for inflicting damage become rather restricted.

Tournament	5	6	7	8	Total
Tech 1	502	704	767	476	2,449
Tech 2	226	469	793	511	1,999
Tech 3			46	64	110
Tech 2/3 %	31.0%	40.0%	52.2%	54.7%

Ships destroyed by tech level.
There has been a very clear move over time towards higher tech level ships, which can be put down both to rule changes regarding the points required for various ships and the increased sums of ISK people seem to be willing to invest into the tournament

Alliance	Kills		Alliance	Losses
Pandemic Legion	221		Atlas Alliance	82
Dead Terrorists	112		The Star Fraction	79
Cry Havoc.	98		Manifest Destiny.	71
The Wrong Alliance	93		Unaffiliated	69
Ev0ke	93		HUN Reloaded	68
Ushra'Khan	91		The Kadeshi	67
HUN Reloaded	85		The Wrong Alliance	67
Unaffiliated	77		Ushra'Khan	66
The Kadeshi	76		Dead Terrorists	63
Atlas Alliance	76		Morsus Mihi	63

The top ten alliances who have lost and destroyed ships throughout the last four tournaments.
Pandemic Legion, the winners of tournaments six, seven and eight are clearly the highest on the list with just under double the number of kills than Dead Terrorists at number two.

Tournament	Ship total	Value of ships	Average ship value
5	728	36,745,267,244	50,474,268
6	1,173	97,882,298,992	83,446,120
7	1,606	157,296,529,291	97,943,044
8	1,051	147,515,739,964	140,357,507
Grand Total	4,558	439,439,835,491	96,410,670

Current value of ships lost in the last four tournaments. All values are based on the May 2011 market price of those ships.
Each of the last four tournaments has seen an increase in the average value of the ships destroyed, with losses in tournament eight being over two and a half times the average value of losses in tournament five when the ships are valued at their May 2011 market price and for the purposes of this, "unique" ships (such as the Freki) and capsules are considered to have no value.

Ship group	Total destroyed	Value
Assault Ship	240	4,769,181,429
Battlecruiser	476	13,524,132,706
Battleship	526	119,532,489,067
Black Ops	15	7,987,331,627
Capsule	64
Combat Recon Ship	253	26,412,301,687
Command Ship	301	58,765,768,530
Cruiser	685	33,329,515,719
Destroyer	153	108,032,838
Electronic Attack Ship	193	3,777,332,125
Force Recon Ship	13	1,663,143,513
Frigate	529	9,064,252,742
Heavy Assault Ship	321	37,231,927,176
Heavy Interdictor	3	528,031,703
Industrial	16	22,375,077
Interceptor	99	1,296,127,101
Interdictor	88	3,482,220,146
Logistics	264	31,694,342,272
Marauder	63	40,970,841,213
Stealth Bomber	146	3,000,435,293
Strategic Cruiser	110	42,280,053,527
Grand Total	4,558	439,439,835,491

The ISK value of each of the ship groups destroyed.
Again, these prices are calculated from the average market price of those ships as of May 2011. This gives a better way of measuring the relative value between tournaments but is not a perfect measurement for the value each year. However, CPI has not changed drastically since then having been relatively stable since 2008. The bulk of the money lost in the tournaments has been spent on the battleship class vessels; almost 120 billion ISK.
Lastly, our congratulations to the two players who have lost the most ships in these tournaments. Koronos came at the top of the scoreboard with 10 losses and NTRabbit a close second with 9.
Don't forget to follow the action this weekend as tournament nine is wrapped up, all broadcast live on EVE TV!
- CCP Diagoras


More...