We don't have a workable solution right now that answers all the issues, that's pretty much the problem. Sometimes that's a thing that happens, unfortunately.

We don't have a workable solution right now that answers all the issues, that's pretty much the problem. Sometimes that's a thing that happens, unfortunately.

i have to admit ive not tried this as i heard someone in local say you cant, but can you reprocess them?

OK, so here's what happened.
We knew we needed at least two weeks between Crucible going live and us patching in the change, so people had time to sort out their logistics.

We can't safely do the switch between ~Decembec 17th and ~January 15th due to various key people leaving the country for Christmas, and the need for a clear run-up to the patch.

Our original test plan would've seen us squared away weeks ago, but a series of various unforeseen events meant our critical "upgrade test" (requires a spare "full-sized" test server) got repeatedly bumped back in the schedule.

We finally ran the test earlier this week, and the thing we were most anticipating breaking, broke. The fix is relatively straightforward, but it requires us running another upgrade test to confirm that the fix works.

We weren't expecting the second test to be ready until today or Monday, and in the unlikely event that that didn't go smoothly it'd leave way too little time for you all to sort your towers out. Therefore we made the decision to push the deployment of the change back.

As above, once we miss the 14th we can't safely patch for at least a month. Given that we already had a small post-Crucible tidy-up patch scheduled for the 24th, we opted to bundle the fuel switch into that patch rather than running two "serious business" patches (ie, full client/server patch) less than a fortnight apart, because it's safer and causes less overhead.


It's not the way we wanted to do it, but it's the best option we have available to us right now. We're obviously very sorry for the trouble this is causing.

a) Run a script to melt all fuel already added to towers. This will require a bare minimum of QA as it cannot cause towers to go offline, the worst that can happen is that they become overfilled for a few hours until the fuel burns off.
This means that there is no manual correction needed by players in time or ISK
b) Spend the remaining time you have before Jan 24th either sorting a final handover script, or pushing in an extra fuel-block-only bay to towers to cover the switch over.

Voila, fixed with a minimal amount of player intervention.

Can I have your job?

That script involves, in practice, removing all the fuel in towers and then adding new fuel to the towers (you're altering types and quantities, and the final quantities have to be larger because of the number of isotopes and so on in the mix, so it's got to be effectively to be a remove and an add). The worst that happens is that the remove happens but the add doesn't and everything goes offline, and testing this requires an upgrade test which (as we've established) is risky in and of itself and takes a lot of time to prepare.

An extra fuel bay, switching the tower to run on dual fuel types or anything else of that nature requires us to make major changes to the starbase code, which is both risky in and of itself as a major code change, and doubly risky because the starbase code is pretty failure-prone. Plus, making sure that towers ran smoothly when we threw the switch would require another upgrade test; see above.

That script involves, in practice, removing all the fuel in towers and then adding new fuel to the towers (you're altering types and quantities, and the final quantities have to be larger because of the number of isotopes and so on in the mix, so it's got to be effectively to be a remove and an add). The worst that happens is that the remove happens but the add doesn't and everything goes offline, and testing this requires an upgrade test which (as we've established) is risky in and of itself and takes a lot of time to prepare.

An extra fuel bay, switching the tower to run on dual fuel types or anything else of that nature requires us to make major changes to the starbase code, which is both risky in and of itself as a major code change, and doubly risky because the starbase code is pretty failure-prone. Plus, making sure that towers ran smoothly when we threw the switch would require another upgrade test; see above.

WTF? So you guys knew you were slipping the deadline f'ing weeks ago?
And you said.......NOTHING?

[quote=CynoNet Two][quote=CCP Greyscale]
An extra fuel bay, switching the tower to run on dual fuel types or anything else of that nature requires us to make major changes to the starbase code, which is both risky in and of itself as a major code change, and doubly risky because the starbase code is pretty failure-prone. Plus, making sure that towers ran smoothly when we threw the switch would require another upgrade test; see above.

a) Run a script to melt all fuelblocks already inside towers back into their materials. This will require a bare minimum of QA as it cannot cause towers to go offline. The worst that can happen is that they don't melt and you try again the next day, or the towers become overfilled for a few hours until the fuel burns off. Or they turn into Rifters, whatever.

b) Spend the remaining time you have before Jan 24th either sorting a final handover script, or pushing in an extra fuel-block-only bay to towers to cover the switch over.

Voila, fixed with a minimal amount of player intervention.

Can I have your job?

Fuel blocks should already reprocess to their component parts, although only in multiples of 40.

All I'm hearing is excuses about the amount of effort.

Have you considered simply doubling the capacity of fuel bays until the patch, then reverting them afterwards? That way we can all fuel block up our POS and otherwise still fuel them as normal until the patch comes along, and doing this is clearly not a big technical problem because you've already increased their capacity once.

You owed it to this section of your playerbase to treat their part of the game slightly more carefully, rather than busting out the snark with, "Sometimes this is a thing that happens."

Then I'm sorry, because we're having an irreconcilable communication breakdown. From our point of view this decision is concerned pretty much exclusively with risk, not effort.

Fuel blocks should already reprocess to their component parts, although only in multiples of 40.

That script involves, in practice, removing all the fuel in towers and then adding new fuel to the towers (you're altering types and quantities, and the final quantities have to be larger because of the number of isotopes and so on in the mix, so it's got to be effectively to be a remove and an add). The worst that happens is that the remove happens but the add doesn't and everything goes offline, and testing this requires an upgrade test which (as we've established) is risky in and of itself and takes a lot of time to prepare.

An extra fuel bay, switching the tower to run on dual fuel types or anything else of that nature requires us to make major changes to the starbase code, which is both risky in and of itself as a major code change, and doubly risky because the starbase code is pretty failure-prone. Plus, making sure that towers ran smoothly when we threw the switch would require another upgrade test; see above.

Actually, no, and that's a pretty reasonable suggestion. I would assume for now that it's too late to get this in under the wire, but I'll ask about it at least. Please understand that this is 95% likely to be too late at this point though.

If the risk is because of a poorly written pos code base then it does come down to effort/money/man hours to fix it.

Are they reprocessable at POS refineries with 0% waste, like ice blocks? Is that a quick fix you could manage to put in?

and just to say, i'm more comfortable with the delay till january than i am with the risk in everything going offline, i'm simply irritated that you guys couldn't have communicated better with us about the status of this.

Solution: Remove the need for fuel until the changeover.

Can I have your job now CCP Greyscale?

Solution: Remove the need for fuel until the changeover.

Can I have your job now CCP Greyscale?

There's a huge difference between "effort" and "money and man-hours".