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

The new forums are live and can be found at

Test Server Feedback

  • Topic is locked indefinitely.

[Rubicon] Ships dropping from SMAs

First post First post
Alvatore DiMarco
Capricious Endeavours Ltd
#81 - 2013-11-10 12:55:12 UTC  |  Edited by: Alvatore DiMarco
Phoenix Jones wrote:
CCP Fozzie wrote:
Only 48 likes so far on Masterplan's post here. Not great so far but it will have to do for now.

Next announcement is:
To deal with the tactic of leaving a rookie alt in a reinforced starbase to unanchor CHAs and SMAs right as the starbase dies (and therefore deny all loot from the aggressors) we are increasing the unanchor delay on SMAs, XLSMAs, CHAs and PHAs to 1 minute.

Next your going to remove the ability for a rookie ship to light a cyno....

That is insane...

And then you are going to force titans to bridge with the fleet...


CCP Fozzie, joo be crazy!!!!

I don't pretend to know everything about the force projection issues that plague EVE and reduce New Eden to the size of a Large pepperoni pizza, but I fail to see how forcing a titan to bridge with the fleet could possibly be a bad thing.
#82 - 2013-11-15 03:50:22 UTC
Informing people which problems you are actually currently working on and with how much priority DOES NOT require you to reveal any details or to set dead lines.

Been part of billion dollar software programs where ends users were told which of their ranked problems where being worked on & a little of why certain projects weren't taken in strict order. Its pretty easy to say - these lower ranked items are thought to be related to the same code as a higher priority. Sometimes the reason was simply because we think we can quickly and easily solve this problem. Sometimes it was this item was chosen as the most difficult item this less experienced team can handle or this is suitable as train material for brand new people. Occasionally VIP users said "we would rather have nothing lower delivered if less competent people can speed higher priorities by 5 minutes as coffee gophers" -- but not very often.

Not infrequently work on an existing high priority project was suspended with the explanation that the solution was a lot more difficult than initially thought or even impossible under current hardware, time or budget constraints. Occasionally the user voted to sacrifice other projects to supply missing labor or budget. But again users did not often go against the recommendation of what the software thought was the best delivery schedule.

The point being CCP does not need to secretive about what issue-problems they are working upon -- only about specific solutions in the planning stages and deadlines. Even changing priorities will be accepted as long as the general reason is NOT self-generated changes in priorities (CCP got bored or saw something more exciting that had little user backing).

Telling people priority #3 is turning out to take 2-3 the expected time and labor -- and so CCP is considering suspending that to deliver #4, #5 and #6 items instead for the next release is acceptable. But CSM or not, you probably need to say how you plan to deal with priority item #3 -- i.e. work at lower intensity of priority #20 for the next year or more until the size of remaining work fits in to a single release package. Currently the perception is that CCP tends to just shelve oversized projects until some accident of technology advancement, other project code changes, or coder epiphany presents a serendipidious solution (which as a gaming company with next to no RL consequences is probably true and not that unreasonable if the player base is loyal enough).