FreeOrion

Forums for the FreeOrion project
It is currently Sun Dec 17, 2017 3:40 pm

All times are UTC




Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Tue May 16, 2017 11:07 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
I've opened an issue on what looks to me like wrongful/excessive production loss if you increase the blocksize of a ship-type production item-- currently ALL past progress is lost in that case.

Goeff's response there was that
Quote:
Working as intended I think... If you want to produce 2 ships, and it takes minimum 4 turns to produce any given ship, you can't take a half-produced ship and turn it instantly into two quarter-produced ships. Regardless, it's probably a forum discussion, not a bug.


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, but even if you accept the premise that any increase to the blocksize should require the full base number of turns to complete, then losing all past progress is still an excessive penalty. Reducing the % completion from the adjusted 25% down to 24.9%, so that it would still take an additional 4 turns to complete, meets that goal while only wasting a very tiny amount of the previously spent PP instead of all of it. And then there are a myriad of cases, like changing from one 4-turn ship to four or more of the ships, in which case they would necessarily still take an additional 4 turns to complete without throwing away any of the previous progress.

So, if you have a ship that takes a minimum of k turns to complete, with X% currently finished, and you increase the blocksize from M to N, then the adjusted % completion Y could be calculated as
Code:
Y = min( X*M/N, 1.0/(k-1) - 0.001)


so that a minimum of progress would be thrown out while still always requiring it to take at least k turns thereafter to complete.

But I'll also circle back to the base question -- perhaps this had already been discussed and agreed upon, but if not, what are people's current thoughts on, that an increase to blocksize requires that there be a penalty so that the base min number of turns is needeed after the adjustment before completion?

**edit the above calculation is assuming that as part of switching over to % completion you also did away with the pre-loading and topping-up provisions we previously had put into place to account for changing costs; if those still exist in some form then some further adjustment could be needed.

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


Top
 Profile  
 
PostPosted: Tue May 16, 2017 11:43 pm 
Offline
Space Dragon
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 258
I think as you, Dilvish.

If you have 2 ships half finished and then you realise that you want 4 instead, you can halt the production of the two half ships, start to build another batch of two ships until they are half done, and then continue with the 4 half ships as if it is a single 4x batch. I don't see the problem "in real life", unless there are only two production lines and taking out an unfinished hull to start a new one would imply extra costs.
But it can be better than that: you can finished the already started two ships, don't deliver them to the client, and then finish the other two, to give away the four ships together. In this case I can't really see any extra cost.
Currently you can do this in the game through micromanagement: add a second batch of 2x over the first one and then swap its possitions along the queue to ensure that both finishes in the same turn). As that is possible and carries no penalisation, why not making it easier and honour the game philosophy?
I wouldn't even apply any penalisation because it is inconsistent with the game mechanics (if micromanaging does not carry the penalty, why apply it if not micromanaging?).


Top
 Profile  
 
PostPosted: Wed May 17, 2017 12:32 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3295
It's not something I was aware of when testing as it's something I rarely do, but I disagree with Geoff's logic there, if you've got a ship 1/10th built and you decide you want 2 instead of one, you've still got a tenth of a ship: it was always the case that if you reduced the blocksize you'd lose excess but keep it proportionately if you increase the size.

I haven't thought about it but I don't see the need for a penalty, it wasn't there before we made the change and the change was at my request for balance/exploit reasons, it resolved one of my two intense dislikes in the current upkeep system and the other is something we're looking at next cycle.

I would however have no problem with a small penalty but it wouldn't need to be big.

_________________
Mat Bowles

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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 4:04 am 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 359
I think from the pov of a typical user, a loss of previous work is unexpected.
Rather the expected functionality is any previous work is delayed for new additions to the batch.
(a batch size would not actually change, it is either scrapped and replaced, or delayed to sync with a new batch)

Alternative proposal:
To address the unexpected PP loss, issue a confirmation dialog when changing blocksize with previous progress (with a "don't show this message" checkbox).

Could then add a delay X turns feature, the options might replace the pause/resume option with a sub-menu:
  • Resume (enabled only if previously delayed)
  • 1 additional turn
  • 5 additional turns
  • ... turns (input dialog)
  • Indefinitely (paused)

_________________
Any content posted should be considered licensed GNU GPL 2.0 and/or CC-BY-SA 3.0 as appropriate.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 10:26 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12045
Location: Munich
I think I / we avoided any retention of previous progress when increasing block size because it can get very complicated and inconsistent very quickly... The case of 1 ship with 2/4 turns progress being switched to 2 ships is relatively simple, but what about cases like 10 ships with 90% turns progress being switched to 11 ships? To ensure that the newly-added ship takes a full 10 turns to produce, the progress of the 11 ship production item would need to be set to (1/11 - 0.0001)*100% ~= 9%. So you're still throwing out quite a lot in that case...

I think the only way to avoid this sort of issue would be to have some internal state to the multi-ship production item, which tracks what % complete each ship within the multi-ship production item is, and then adjust the production item's cost per turn / maximum allocation according to how many of the internal ships still need production allocated to them, until the last one is complete, then start over from 0% producing all in parallel for the next iteration (if applicable).


Top
 Profile  
 
PostPosted: Wed May 17, 2017 11:27 am 
Offline
Vacuum Dragon
User avatar

Joined: Sun Sep 25, 2011 2:51 pm
Posts: 500
... 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.

_________________
[...] 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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 11:49 am 
Offline
Space Dragon
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 258
Geoff the Medio wrote:
I think I / we avoided any retention of previous progress when increasing block size because it can get very complicated and inconsistent very quickly... The case of 1 ship with 2/4 turns progress being switched to 2 ships is relatively simple, but what about cases like 10 ships with 90% turns progress being switched to 11 ships? To ensure that the newly-added ship takes a full 10 turns to produce, the progress of the 11 ship production item would need to be set to (1/11 - 0.0001)*100% ~= 9%. So you're still throwing out quite a lot in that case...

I think the only way to avoid this sort of issue would be to have some internal state to the multi-ship production item, which tracks what % complete each ship within the multi-ship production item is, and then adjust the production item's cost per turn / maximum allocation according to how many of the internal ships still need production allocated to them, until the last one is complete, then start over from 0% producing all in parallel for the next iteration (if applicable).
Ah, I had missed the whole point of ensuring that newly added ships do not get finished sooner than possible.

So, in the case of 10 ships that need 10 turns and are at 90% complete you would have an entry in the production queue like this (assuming 1k PPs per ship and plenty of PPs for it):
- max 1000 PPs/turn, 1 remaining turn (9k PPs already invested).
That "1000" is the result of 10 ships * 1000 PPs per ship / 10 turns to build.

Using a relatively simple formula, if an eleventh ship is added, it could be like this (assuming no penalisation, just delaying):
- max 200 PPs/turn, 10 remaining turns.
That "200" would be the result of (1 ship * 1000 PPs per ship + 1000 PPs that were remaining from the original batch) / 10 turns to build; and the 10 remaining turns are obvious.
After a turn, it would have 9.2k PPs invested (9.1k if you ignore the eleventh ship, but that would require more complex formula or the system to track independently each ship, as Geoff pointed out).
If on the next turn you change your mind and decide to remove the eleventh ship, should it show 91% complete

However, it would be "reasonable" to allow the investment of 1100 PPs on the first turn (so that the initial 10 ships would be already completed, just waiting, and the eleventh one would be at 10% completion) and the remaining 9 turns allow max 100 PPs/turn. In such case, it makes no sense to modify the blocksize since you would be better off adding a new batch of a single ship and allowing the initial batch to finish normaly, so that you can have those 10 ships sooner.


Summing up, if we considere that the minimum time to built a new ship should be respected, there is little advantage in allowing the addition of a new ship to an already started batch. It will be always better to let the initial batch to finish and queue the extra ship

So I changed my mind and I agree with the Geoff that wiping out full production is the simpler way and relatively reasonable (we can say that the shipyard manager gets pissed off because of the schedule change).
Or, maybe better, the blocksize could be freezed once some PPs have been invested on it, so that the player should add new batches and maybe remove the previous one or move it down the queue if he wants the focus on the new one.

Edit: em3 got ahead of me with that last suggestion.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 12:36 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12045
Location: Munich
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.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 12:43 pm 
Offline
Space Dragon
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 258
Geoff the Medio wrote:
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.
What about allowing blocksize change only when a turn or less has been completed?. Rollover won't be a problem then, and the formula to adjust completed percentage would be rather simple and won't ever allow for completion of ships in less than possible time:
- Same percentage if blocksize is reduced.
- Proportional if blocksize is reduced (percentage * initial number of ships / new number of ships)


Top
 Profile  
 
PostPosted: Wed May 17, 2017 2:14 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 205
I agree with Geoff.

Individually tracking ships within a batch job and completing a batch when the batch size number of ships are ready is one solution. Making the internal state apparent to the player would be helped by a UI elements to shows the partially complete state of each ship in the batch.

One way to do that might be to promote partially completed ships to full universe object status like partially completed buildings. Then they can show up on planet and be capture and completed by other empires.


I think that there is a simpler solution.

Simple Example

Assume my empire has an order for 2 ships that take 2 turns to produce.

On the turn that the ships are not delivered I have in production 2 half ships, rear ends I presume.

If I change the order to 1 ship, I still have 2 rear ends. The parts for the front end have not been made yet. So I still need one more turn to make the front end parts and I discard half a ship.

If I change the order to 3 ships, I still have 2 rear ends. It will now take 2 full turns to build the rear end and the front end for the new ship.

An Alternate Solution

When batch size is changed add an option to the right click context menu to "Split partially complete production". This will create a new non repeating production queue item with just the partially complete ships.

In the above example, in both cases the "Split partially complete production" action would create a production job to complete 2 ships in 1 turn and the newly adjusted production item would start from zero.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 2:21 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12045
Location: Munich
LGM-Doyle wrote:
One way to do that might be to promote partially completed ships to full universe object status like partially completed buildings.
Partially completed buildings are not yet UniverseObjects. There's special case code for the sidepanel buildings panel to show the enqueued building production items.

That said, showing under-production ships in the fleets window / on the map sounds reasonable.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 4:09 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
The more I think about the penalty the worse it seems.
Geoff the Medio wrote:
... To ensure that the newly-added ship takes a full 10 turns to produce...

But you're continuing to ignore the underyling question of whether any increase to blocksize really must require the full additional base number of turns to complete after the increase, whereas MatGB and myself have both clearly said we don't think that's important.
MatGB wrote:
I disagree with Geoff's logic there, if you've got a ship 1/10th built and you decide you want 2 instead of one, you've still got a tenth of a ship: it was always the case that if you reduced the blocksize you'd lose excess but keep it proportionately if you increase the size....I don't see the need for a penalty, it wasn't there before we made the change and the change was at my request for balance/exploit reasons....


As dbenage-cx pointed out, the player is certainly not expecting to get penalized if they increase the blocksize. All the penalty would really do is discourage people from increasing the blocksize and push them towards micromanaging the production more (that's how I personally currently deal with the penalty). In your case of 10 ships with 90% turns progress being switched to 11 ships, it should absolutely not be the case that we silently throw away all that production, and so far MattGB , myself and Obertus have all clearly said we're fine with the production being averaged together -- in your example the player would obviously be able to micromanage things to simply add a single ship and pause the current production for 9 turns, and then after after the end of 10 turns they would have all 11 ships without having wasted any of their production. So we can't let the non-micromanaging approach remain so hugely inferior to that as it currently is.

MattGB and I have both indicated we think it is fine to let the production times get averaged out when you increase the blocksize, you just let the player keep the proportional bit of % completion. The only other possibility mentioned above that seems semi-reasonable is em3's suggestion as modified by Obertus, actually blocking any increase (maybe any change at all) to blocksize if more than one turn's worth has already been completed (but that's essentially still forcing the micromanagement, just not leaving a simpler-but-penalized alternative). But even that restriction doesn't seem important to me, just let the production times average out.

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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 4:46 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12045
Location: Munich
Dilvish wrote:
In your case of 10 ships with 90% turns progress being switched to 11 ships, it should absolutely not be the case that we silently throw away all that production...
I was applying your suggestion for the case of 2 ships at 50% converting to 4 ships at 24.9%, to a case with somewhat different numbers (10 at 90% to 11 at 9%), to illustrate that it doesn't work so well in other situations.
Quote:
But you're continuing to ignore the underyling question of whether any increase to blocksize really must require the full additional base number of turns to complete after the increase...
That it is even being considering is very surprising to me. A basic idea of the production system is that stuff takes a minimum number of turns to produce, and this is a glitchy / micromanagy way to get around that by reallocating previous turns' spent production. I thought avoiding stuff being produced faster than it is supposed to was a big part of the reason to switch to a % based production progress system. Why would we let the player instantly create several partly or nearly-complete ships much faster than they are supposed to be able to? At least with paused production items on the queue at 1 turn from completion, the player has to plan ahead for how many ships and how much production to allocate... If they can instead just increment the production item batch size every time it's about to complete, and all the progress evenly spreads amongst the new batch size ships, then they can keep growing the production item with no planning required until they decide to let it finish. The batch production system was, I thought, a UI convenience for reducing queue clutter with large numbers of similar production items, not a means to circumvent turn limits to produce things.

If all the allocated progress must be saved within a single production queue item when its batch size changes, then the only acceptable (to me) option is to keep track of each ship within a multi-ship production item, and adjust the cost per turn of the item as the various ships within it are completed (or catch up) until they all finish at the same time.

LGM-Doyle's "split partially complete production" suggestions is also good, as it would move all the accumulated progress into a separate production item, letting the batch size of the original be freely modified.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 5:52 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4390
Geoff the Medio wrote:
That it is even being considering is very surprising to me.
The preexisting mechanic had existed for Years. When a significant penalty is added apparently without discussion, then no one should be surprised if it winds up being considered to change it back. The silent penalty certainly cannot remain as it is now.

Quote:
At least with paused production items on the queue at 1 turn from completion, the player has to plan ahead for how many ships and how much production to allocate... If they can instead just increment the production item batch size every time it's about to complete, and all the progress evenly spreads amongst the new batch size ships, then they can keep growing the production item with no planning required until they decide to let it finish.
Those are certainly both planning decisions, with different sets of pros and cons. The only real distinction comes down to your production timing issue, not one of them being "planning" and the other "not-planning".

Quote:
The batch production system was, I thought, a UI convenience for reducing queue clutter with large numbers of similar production items, not a means to circumvent turn limits to produce things.
Right as far as it goes. But actually circumventing turn limits would have been if we kept proportional completion even if decreasing blocksize, which is why we discussed it when blocksizes were first implemented and decided to throw out the extra production in the case of blocksize decrease. Letting the production times average out when you increase the blocksize is not something that we saw as circumventing the production times back then, and it is still not something I see as circumventing them, it is just a reasonable resolution of how to accommodate the blend, one which helps streamline production management. This blending doesn't just let someone get ships early-- they would also have to delay ships, and wind up getting the joint batch at an averaged delivery time.

Quote:
If all the allocated progress must be saved within a single production queue item when its batch size changes, then the only acceptable (to me) option is to keep track of each ship within a multi-ship production item, and adjust the cost per turn of the item as the various ships within it are completed (or catch up) until they all finish at the same time. LGM-Doyle's "split partially complete production" suggestions is also good, as it would move all the accumulated progress into a separate production item, letting the batch size of the original be freely modified.
I think that both of these would add very undesirable complication to production queue management, which is already quite enough of a nuisance.

It seems to me that this whole issue with the minimum production time is all driven by a hidden realism argument, that the "true" significance of the build time requirement has to be a specific thing that corresponds to a real life minimum build time, rather than what significance makes for the best game. For years we interpreted it in a way that allows for a more flexible and streamlined production queue management, and I strongly feel that interpretation is the one that makes for a better game.

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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 6:08 pm 
Offline
Space Dragon
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 258
The thing is I'm not really wasting time in microing because of the current mechanics. I you keep them as it is I'd still be happy with it. Using the situation that I'm more often in:

At some point I have a batch of Nx ships that takes more production than available.
Then available production increases (because total production increases or because something was finished upper in the queue) so that I get more than enough for the ships and I want to spend the remaining PPs in extra ships like the ones I'm building.

With current mechanics:
I add a second batch of Mx ships, with M>N so that no PPs are wasted once the first batch is finished. To be sure of that without calculations, I
- first put the new batch over the old one,
- adjust the blocksize of new batch to not let any PPs pass to the old one
- then swap both batches to get the old one finished ASAP
- set the repetitions of the old one to 1 and the new one to 99 (or whatever).
The new one will be getting the extra available PPs as if it was added to the old one with a blocksize increase with no penalisation).

With emm3 suggestion:
As I can't/won't wait for the current batch to get to turn 1 in order to be able to change blocksize, I'd do exactly as with current mechanics.

With free blocksize change:
Unless the old batch is in turn 1, as I still prefer to have the ships of the old batch finished ASAP, I'd still do as with current mechanics.

The more I think about this, the more confident I'm with current implementation.


@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?

Dilvish wrote:
It seems to me that this whole issue with the minimum production time is all driven by a hidden realism argument, that the "true" significance of the build time requirement has to be a specific thing that corresponds to a real life minimum build time, rather than what significance makes for the best game.
I though (as a newcomer, and given some discussions in varied threads in this forum) that the minimum build times were for balance reasons:
- bigger ships need longer time to build to help balance between many small vs few huge battles (anyways that is broken with current upkeep mechanics, another story).
- more expensive ships (because of high-end components) need longer time to help balance between many simpler, cheaper ships vs few more complex and expensive ships.
And all this to help variability of strategies instead of boring "everyone-always-do-the-same-cause-it's-the-best" no-brainer games.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 32 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group