Oberlus wrote:@Dilvish, I'm not sure you understood Geoff. 
It must not be possible to let a ship, that would usually require N turns to complete, to be finished in N-1 turns via the blocksize change mechanic.  Otherwise, what would be the reason to not let a new ship to be finished on N-1 turn from the start, regardless of blocksizes or current bathches? 

I understood him just fine.  Perhaps reread my explanation?  Allowing the build times to be averaged out in a particular circumstance is not equivalent to ignoring the build times. 

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Dilvish wrote:I don't personally see the need to require that example case to take an additional 4 turns to complete instead of 3 turns more

Dilvish wrote:Allowing the build times to be averaged out in a particular circumstance is not equivalent to ignoring the build times. 

Oh, indeed it is, in the examples we are dealing with here:
If you have a batch of two ship of 4 turns at 50% and you add two more ships and consider it at 25%, you are effectively building the two new ships in 3 turns, despite minimum time (if added to a fresh started batch) being 4 turns. 

You can introduce some kind of penalisation as you proposed in the first post of this thread to make it need the intended 4 turns to finish, but there are examples (as the one Geoff's pointed out in his first post in the thread) where it will still be violating the minimum required turns rule.  Moreover, what's the point of allowing blocksize increase if that implies a penalisation in PPs?  I would always preffer the micromanaging then. 

What I'm missing here? 

Also, if a single ship can be built in 3 turns instead of the intended 4, thanks to doing this blocksize increase, why we have the minimum of 4 turns? 

If you don't agree with the whole concept of minimum required turns, that's a whole different story. 

Per Dilvish's previous formula: Google doc (hard to check if editing is setup correctly for others, send name and I'll add)
I realize the formula was possibly just a starting point, this was just to preview the layout and workarounds needed without consideration of partial allocation or upkeep. 

To note, still prefer minimum build time is adhered to and, if not disabled, indicate when previous progress(cost-wise) will be lost. 
If the build time is averaged, there are likely corner cases with undesired outcomes, and may play havoc with some balance concern. 

Tracking each ship could allow for easy merging of queue blocks as well.  Without such an addition, what is the difference between splitting partial completion and just creating a new block? 

dbenage-cx wrote:If the build time is averaged, there are likely corner cases with undesired outcomes, and may play havoc with some balance concern. 

The averaging of build times is just the shorthand way I was referring to the general proportional allocation way that blocksize increases had been handled for the 2-3 years prior to the institution of this penalty.  I don't think that citing vague concerns about "likely corner cases with undesired outcomes" is appropriate or helpful, nor did we observe havoc from that previous handling. 

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

Oberlus wrote:...where it will still be violating the minimum required turns rule...What I'm missing here? 

Among other things, you are missing the fact that your argument assumes a particular interpretation of the "minimum required turns rule" which is contrary to how we had handled it for at least a couple years.  You are also missing the meaning of "ignore".  It appears to me you are missing knowledge of our general design paradigm. 

Moreover, what's the point of allowing blocksize increase if that implies a penalisation in PPs?  I would always preffer the micromanaging then. 

That's a major part of my point-- part of our design paradigm is to try to never create an incentive for micromanagement. 

Also, if a single ship can be built in 3 turns instead of the intended 4, thanks to doing this blocksize increase, why we have the minimum of 4 turns? 

But in no case are you actually building a single ship in 3 turns instead of 4.  I won't cite realism as a reason that something must be a particular way, but I will certainly cite it as a reason that things may be a particular way.  I'll assert that there are many real life situations when making a batch of something can take X amount of time, but increasing your batch size part way through does not totally start that time requirement over from zero, nor are you magically ignoring the time requirements to make things. 

If you don't agree with the whole concept of minimum required turns, that's a whole different story. 

[/quote]That is such a gross mischaracterization of the position taken by myself and MatGB that I have a hard time seeing it as part of an earnest discussion. 

If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0

em3 wrote:... or you could simply say, that once production has started (any PP were allocated) on a batch, its size cannot be modified. 

This way, there is no need for warnings, complicated formulas, fractional progress and PP loss. 

You know, KISS. 

And second one is Geoff proposal.  But I don't like it because of unnecessary complexity.  Not KISS, you know. 

Dilvish wrote:But in no case are you actually building a single ship in 3 turns instead of 4

If you add a ship (that needs 4 turns to complete) to an already started batch (50%, 2 turns completed) and that batch is finished in another 4 turns (6 in total), then it is counterproductive for the player (either because of a loss of invested PPs, if using a formula with penalisation, or because of a loss of time, if using a formula to delay the already started ships).  In such case, I wouldn't be using that feature since I personaly consider it pointless as explained before. 
If you add that ship and allow the batch to be finished in less than 4 turns then it violates the minimum required turns and introduces inconsistency in the game mechanics (wasn't MatGB refering to that as an exploit?).  And I thought that was your preferred way to solve this.  Quoting you:

I don't personally see the need to require that example case to take an additional 4 turns to complete instead of 3 turns more

Yeah, a particular one: if a ship is intended to need N turns to complete, then it must take N turns to complete. 

That is such a gross mischaracterization of the position taken by myself and MatGB that I have a hard time seeing it as part of an earnest discussion. 

I wasn't talking about MatGB's position, only yours.  From what I read in your posts (already quoted), I was assuming that you are proposing to allow the batch of the previous example to finish in less than the aditional 4 turns.  And since that would be against the mentioned rule (I think that would be a respectable position too), I thought you might be against that rule too.  I guess I misunderstood you, I'm sorry.  But cheers, since that means you must agree with Geoff.  Cool, right? 
In any case, I was being serious and trying to contribute, not to make a joke nor to offend you.  You have my respects. 

Oberlus wrote:
If you add that ship and allow the batch to be finished in less than 4 turns then it violates the minimum required turns and introduces inconsistency in the game mechanics (wasn't MatGB refering to that as an exploit?). 

No: with the old system you could scrap a large number of cheap/outdated ships in one turn and the next turn work in progress could be completed (extreme example: have 100 ships including comsats, queue a large order of expensive long-to-build ships like flagships and have them complete to half way, then scrap all the ships, upkeep costs halve so they're all now fully paid for: I used to do this sort of thing fairly regularly when waiting for Experimentors to open up before the Bore was introduced). 

The exploit was getting cheap ships or getting a large order in half time.  The change was designed to eliminate that and also remove the problem that most orders would complete in less than scripted time as upkeep increased: especially annoying if playing Organic where everything takes ages anyway. 

I have zero problem with an order still within the first bounds being increased at proportionate cost with no penalty—this is especially useful if you've got a repeat order going.  I don't actually see a problem with it being done at any point as long as costs are carried over proportionately and progress reduced proportionately: if you have an order 80% complete for 5 ships and change it to 10 ships then it should be 40% complete.  It's not really an exploit that I can see and never considered it a problem before the recent change was made, you were able to do this before the change and I never found a way to abuse it in a way I thought exploitative.  I can see complaints about realism but I never care about them (I do balance first, anything else is second). 

I don't actually mind if no change can be made once production has started, but make no mistake it is an unintended/undiscussed change that wasn't in the plan when it was discussed, and this change isn't needed for balance purposes: I don't actually see an exploit to it given opponents can't know what you're building anyway. 

Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project. 

em3 wrote:... or you could simply say, that once production has started (any PP were allocated) on a batch, its size cannot be modified. 

This way, there is no need for warnings, complicated formulas, fractional progress and PP loss. 

Then it would often be impossible to ever change the block size of a repeated production item after it starts being produced, because there will usually be rollover from just before completion to just after... eg.  minimum 10 turns to produce, at 95% just before and 5% on the turn after it's finished being produced. 

you should be able to change whether or not it keeps repeating though (I'm repeating a 10 ship package... I cancel the repeat and once it finishes the overflow goes to the next project, not another repeat)

Krikkitone wrote:you should be able to change whether or not it keeps repeating though (I'm repeating a 10 ship package... I cancel the repeat and once it finishes the overflow goes to the next project, not another repeat)

That's exactly what I do with the current mechanics. 

That made me think of another possible way to do this:

If you want to minimise queue management and be able to change the blocksize at any point of the work without having to add a new batch, while still keeping it simple and respecting the minimum times for ship designs, UI could allow to change the blocksize so that it takes effect once the current work is finished. 
No wiping out of production would be possible unless the player voluntarily removes the batch from the queue. 
It won't fix the case where you want to increase the blocksize to account for an increase of available PPs, in that case you'd still have to add another batch to soak those PPs. 

FASTER: You want to produce a part of a batch faster (You dont have enough PP to finish all of it parallel, but need something now). 

LESS: You want to finish only a part of a batch. ( e.g. You have new information that you will need only 10 comsats instead of the 100 ordered you ordered). 

MORE: You want to produce more of a certain batch item without the hassle of doing the workaround (finding the right production site, finding the right item, putting the item to the correct position in the production queue)

CLEAN: You want the production queue and sitrep to be less cluttered (This use case is somewhat contrived).  E.g. you have added the same item multiple times and want it to show up only once and want it all to be finished in the same turn (instead of seeing batches produced in the sitrep for multiple turns). 

If you really wanted to you could add UI options for
FASTER - UI option to split batches (Similar to fleet management)
LESS - UI option to decrease amount. ( Or UI option to split batches and then delete the other batch afterwards)
MORE - UI option to clone an order (Actually that would help also in other situations)
CLEAN - UI option to merge batches (Similar to fleet management; progress in turns of merged batch is the slowest current progress in turns of all merged batches; i guess to keep all PP, we would need to change the production items in the backend; or all excess PP get transferred to the imperial stockpile (using the appropiate multiplier/fraction)

em3 wrote:... or you could simply say, that once production has started (any PP were allocated) on a batch, its size cannot be modified. 

This way, there is no need for warnings, complicated formulas, fractional progress and PP loss. 

You know, KISS. 

Personally I would go for this.  I also think solution need to be compared against this one for judging benefits vs complexity. 

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project. 

I get the use case with repeated batch orders (it might be the most common use case when you'd want to adjust batch size), and see no KISS design that would allow modifying them (2-dimensional production queue?). 

There would need to be a way to visually separate the repeated order and the current iteration in order to allow modifying the former without modifying the latter. 

[...] for Man has earned his right to hold this planet against all comers, by virtue of occasionally producing someone totally batshit insane. -  Randall Munroe, title text to xkcd #556

I'm with Dilvish and Mat on this one.  I never considered it an exploit to be able to shorten the build time of some ships by increasing the batch size of a build order.  Because the only "exploit" here is that you can increase the size of a batch after a few turns and still get done in the same time as when you'd set the batch size to the increased amount from the start.  And even that will only work within very tight limits.  If you e.g. double the batch size, it will take substantially longer to finish.  You'll get the added amount of ships sooner than if you made a second batch, but you'll also get the original amount of the batch later than if the batch size hadn't been changed.  Which is, if I understand correctly, what Dilvish meant when talking about the build times averaging out. 

Meaning, even if you get some ships faster, you pay for that by getting the other ships of the batch later, so you don't really gain anything at the end of the day.  And that is good enough for me wrt the balance concerns that have been brought up. 

There might be some edge cases where you can tweak batch size increase in a way that you get a couple of ships for one or two turns faster without increasing the build time for the partially finished ships, or at least without build times perfectly averaging out, but I expect the possible gains to be marginal, nowhere near the exploit possible by the original mechanic (jumping an expensive batch which is halfway through to almost completion by scrapping 100 comsats).  A "gain" you'd got anyway if you'd set the batch size to the increased amount when you queued it, so, as said above, the real "gain" here is that you can readjust your planning without a penalty.  Which, considering the tight limits on the possible gains, is negligible IMO.  Certainly not enough to encourage any micromanagement. 

However, if you guys really see such a big problem with this, then I suggest to go with em3's proposal: make it impossible to change batch size after PPs have been spent on a build order.  And provide a context menu command which lets the player split the partially finished iteration of a repeated order, like LGM-Doyle suggested. 

But silently throwing away all progress if the batch size is increased is definitely a no-go.  This is worse than pointless, as it accomplishes absolutely nothing that would ever make sense to use, other than providing a means to players to accidentally throw away PPs.  If increasing batch size throws away current progress, why would a player ever want to do this?  This is the equivalent of deleting the original order and creating a new one.  Only, in the latter case I know what I'm doing, and can't do it accidentally (which is how it should be with operations that carry a severe penalty like loosing all progress of a production order). 

Bottom line: I consider the current implementation as seriously buggy, please fix.  Either by returning to the original behaviour (which would be my preference), or by disallowing batch size change after PP have been spent, and providing a context menu command to split a partially completed iteration from a repeated build order. 

After reading Vezzra's post I was between picking the way it was before (production is averaged) and the one disabling blocksize increases on already started projects (em3's). 

So I made calculations for some cases to see if there is any actual gaining interms of some useful acceleration of the production (when compared to add the blocksize increase as an extra batch). 
From what I tested, if it just gives a marginal gain (like 1/10 less turns than required for the added ships) the same would be accomplished by setting the total blocksize from start in a single batch (i.e. batch would be accomplished in the same turn), and if the gain is bigger (like 1/4 less turns) it always carries on a penalisation in terms of total turns to complete (since the batch was started) so that it would have been better to set total size from start (i.e. would have finished in less turns). 

Summing up, I couldn't find any real gain (and obviously no possible exploitation) when compared with setting bigger stashes from start, so that the only "exploit" is that it allows you to correct the mistakes in which you understimated how many ships should be ordered at start.  And certainly it minimises user clicks with respect to the alternative of not allowing blocksize increases after batch is started. 

As average player (not thinking about and checking mechanics) I expect (and always was) this feature to work like this:

I need 10 ships of x type with 8 turns minimum - put them in batch

4 turns later i need 10 more,
- if not in a hurry i add them to batch, timer gets reseted to 8 turns, new PP added to batch and everything is fine
- if in a hurry for first 10 i make new batch

4 turns later i need only 2 of 10, i remove them from batch, rest of PP is wasted but timer stays the same. 

Important thing is that calculation is made but not applied until i click next turn, if after 4 turns i change to 2 ships and see lot of waste PP, and put it back to 10 ships in same turn it should not reset timer.