FreeOrion

Forums for the FreeOrion project
It is currently Wed May 24, 2017 12:32 am

All times are UTC




Post new topic Reply to topic  [ 27 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed May 17, 2017 6:51 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4209
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


Top
 Profile  
 
PostPosted: Wed May 17, 2017 8:31 pm 
Offline
Space Kraken
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 117
Dilvish wrote:
I understood him just fine. Perhaps reread my explanation?
Sure. I may have missed something.

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.

Sorry I'm still not getting your point.


Top
 Profile  
 
PostPosted: Wed May 17, 2017 9:03 pm 
Offline
Programmer

Joined: Sun Feb 14, 2016 12:08 am
Posts: 287
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?

_________________
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:34 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4209
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


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

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4209
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.

Quote:
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.

Quote:
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.

Quote:
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


Top
 Profile  
 
PostPosted: Thu May 18, 2017 1:57 am 
Offline
Space Kraken
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 117
I still think em3 suggestion is the best one (easy, nice and simple):
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:
Quote:
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
Quote:
your argument assumes a particular interpretation of the "minimum required turns rule"
Yeah, a particular one: if a ship is intended to need N turns to complete, then it must take N turns to complete.

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.
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.


Top
 Profile  
 
PostPosted: Thu May 18, 2017 2:50 am 
Offline
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3089
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.


Top
 Profile  
 
PostPosted: Thu May 18, 2017 1:24 pm 
Offline
Creative Contributor
User avatar

Joined: Sat Sep 13, 2003 6:52 pm
Posts: 1384
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.



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)


Top
 Profile  
 
PostPosted: Thu May 18, 2017 5:16 pm 
Offline
Space Kraken
User avatar

Joined: Mon Apr 10, 2017 4:25 pm
Posts: 117
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.


Top
 Profile  
 
PostPosted: Tue May 23, 2017 9:37 am 
Offline
Space Kraken

Joined: Tue Sep 30, 2014 10:01 am
Posts: 121
I am not sure if I got your use cases right, but I'll try.


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.


Top
 Profile  
 
PostPosted: Tue May 23, 2017 10:06 am 
Offline
Psionic Snowflake
User avatar

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


Top
 Profile  
 
PostPosted: Tue May 23, 2017 5:09 pm 
Offline
Space Kraken

Joined: Tue Sep 30, 2014 10:01 am
Posts: 121
em3 wrote:
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)

Oh I missed that one. Hm like chaining two orders, so that work on an order starts after the previous one was finished?

Visually that could be like the items have to be next in the queue adding a linked symbol and showing that a later batch is not currently processed by greying it out (like a paused item).

some item
linked item 1 (gets processed, looks normal)
+ linked item 2 (looks like a paused item)
+ linked item 3 (looks like a paused item)
some other item

When reordering the items, you would reordered all of the linked items at once.

I guess this could be implemented on client side, by actually pausing/unpausing linked items.

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


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

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:  
cron
Powered by phpBB® Forum Software © phpBB Group