EVE Information Portal

Typically the best insight is obvious in hindsight (iow, good post). That distinction that the patch day can come and go on schedule while the DB script can be written and tested later is important.

The expected argument here is that the developer time after patch day is itself already schedule for other tasks, however I think folks would be content to give up a day's work on the patch after this one in exchange for this changeover being less of a headache. Even if it means the changeover happens three, four, or six weeks after patch day instead of the planned two.

Just want to add my part of story which is probably true for most people running POSes in WH space

This does NOT simplify anything. It complicates things for me.

Firstly I believe most people in WH space do use their planets for PI to cut costs on running POS and to CUT the amount they need to howl.

With this "feature", I either have to add additional step of producing those cubes

or simply howl from known space, and therefore instead of howling just ice products I have to howl everything.

You must have a really sore throat after all that howling.

All that pushing the testing* into the future achieves is to add more uncertainty and risk, unfortunately. We'd still need to spend a significant amount of testing time on making sure the script works, we'd still have to prioritize testing the upgrade over testing other stuff, which would still mean cutting a bunch of features to get this in - and it still probably wouldn't be worth it. It's not a case of "having time available", because we had "time available" for this expansion - it's a case of "being worth spending the time on this rather than something else".

*Anyone saying that writing the script should be trivial is, uh, not speaking from a position of authority, but it's the testing time that's the real workload, because every time we want to test if it works (which we need to do at least once and potentially two or three times to test fixes for problems caught in earlier runs) we have to actually run the upgrade on a copy of TQ, which takes a large amount of setup and prep time. (And before anyone says "surely that's really simple", it's not, and that's really all there is to say about it :P)

Why, what features do you have planned for January?

We're always working on something

to be honest, 5 minutes instead of 10 is simply no change.

I mean what is the point in introducing the need for manufacturing in the first place? why before you did not have to manufacture anything to fuel a starbase, and now you have? what kjnd of nerf is that?

If this is supposed to be a usability upgrade (instead of a usability nerf as it is now), just make this conversion free, or take some symbolic time, like 1 minute for 400 cubes.

With what it is now, we'll have all the high sec manufacturing facilities taken by only the fuel cubes production for years to come.

You might just say so if you wanted to nerf high sec manufacturing, not disguise it as a 'boost' to starbase management.

Cutting the manufacturing time in half is a large change. This feature is a usability improvement, but it also offers industrialists something new to do. It's sort of like why have guns use ammo when you could just have all the basic minerals in the cargo hold and guns would automaticly convert them to pew-pew. IT's not strictly necessary to have ammo, but it makes sense, is a lot more convenient than calculating how much of what minerals you need to carry for your ammo needs and it offers industrialist a new thing to produce and a new product to make profit from.

The effect on manufacturing facilities won't be as big as you think, because POSs will also produce them and there is no more fuel savings for not using up all your CPU and powergrid on a POS. This means people who didn't have their POSs fully utilized are now looking to make use of that extra capacity in some way, since they are going to be paying for it anyway. One good use for it is going to be a facilty, that is capable of producing fuel blocks for their own consumption and for sale to the market.

So, confirming those of us with large towers running with low PG/CPU usages will pay more for fuel.

I am glad with your analysis that the overall fuel cost impact will be relatively minimal - I had not hard calculated the actual impact yet - but in any event, we will be paying more at our large low-intensity POSs, but perhaps not as much as I had feared.

Of course the QA time is more than the script. I could write the script in 10 minutes or so; I can't imagine how long I'd want to estimate for the QA. With you 100% on that.

But -- without it, I think this entire FEATURE is not worth it. Or, at the very least, it will be a LONG time before the extra hassle is made up by any savings in subsequent hassle.

And without a volume adjustment, I think it is a serious PITA for WH operators. I brought this up before; others have brought it up, too. That, I think, you could take care of in a single stroke; you'd spend more time discussing the exact value than implementing and testing.

I think you've fallen in love with both the feature and the schedule. I think you need to back off and not rush this.

As it is, I would MUCH rather just not have it, and continue with the status quo. If you want to make my life easier, just reduce the volume on the ice fuels. Save yourselves a bunch of QA work.

I spend FAR more time hauling fuel, than I do calculating how much of each fuel. The complexity really doesn't bother me. The volume does. The volume of these blocks is FAR higher than the volume of ice fuels alone, which is all I current have to haul.

Can we get you, CCP Omen, and a bunch of other devs to go live in a WH for a couple months? It would be both fun for you, and educational.