Recurring order

Hello,

With now 8 FP on a planet, the 5 queue slots is starting to be a little short.
Not willing to run for an 8 queue slots (it will take months), I decided to get a month of pro (and, a little thank you for devs).

I though that it would solve my queing issue, But I obviously misread the feature.
It re-queue an order when it start.

As my orders are 3RAT,3COT,2DW, the recurring feature isn’t adapted to maintain the 8 FP up and running, because orders are re-added when the order start, and I can’t have, 8 order in queue.

Is it assumed that the recurring feature (aka a pro feature) still rely on queue stop number ?

A better implementation would be :
“Recurring order will be re-queued as soon as it ends”
I mean, from my point of view … :slightly_smiling_face:

1 Like

Adding another point as a reply so the one that already seen this feedback can see it.

In fact, I have also 5 FRM, for 4 products (BEA NUT MAI for RAT, and 2 RCO for OVE)
They could be fine with recurrint here, because 5 FRM for 5 queue.

But, on a 24h plan, the BEA/NUT/MAI run on a ~21h, and the RCO on 1d2h.
It means that on day (roughly 5d), 2 queued RCO will start before the end of the previous one.
The overall 5 FRM will produce at max, but more RCO than what I want, and less,say MAI and BEA.
The productivity of MAI and BEA will drop, as the RAT behind it.

Although my OP can be answered by a “grind to an 8 queued slot” (but a grind in term of months :grimacing:).
But here, this is 5 FRM for a 5 queue slot, but cannot be maintained with a recurring queue.
Something can be discussed.

Here is an image for the proposition above (“Recurring order will be re-queued as soon as it ends”):
Yellow circle as button to enable, or not, the reccurtion of the order (available as PRO)
Sans titre

As my orders are 3RAT,3COT,2DW, the recurring feature isn’t adapted to maintain the 8 FP up and running, because orders are re-added when the order start, and I can’t have, 8 order in queue.

The queue system can do this and does work. The ratio of products produced has no relevance for how long each production time is.

I’m just going to show my production lines as they exist. Hopefully it makes sense.

This will always produce exactly 200 RAT, 200 DW and 6 COF. After a week, it will have produced 2100 RAT, 2100 DW and 72 COF. The difference in the amount of time each production order takes has no relevance in the final ratio of product you end up with.

The same applies for your crops. This will always produce perfect ratio’s of crops to go into my FP’s to make RAT.

1 Like

You mean that the point to look is the total ratio of time of production for each product (for recurring order queued) ?

(side question, how your crops are green? mine are red)

EDIT: Seems correct on long term while build continue running.
There is no more 24h gate, this notion doesn’t have any when using the queue this way, unless jobs sync sometime.
Gonna give it a try
Thanks for the tip.

But still thinking my propal is simplier :slightly_smiling_face:

Oh I’m using a script someone made to change the colors of the icons, because for whatever reason, counterpoint made crops and food AND luxury items all red. 60-80% of my global inventory was some shade of red, it’s ridiculous.

There are also community tools like PRUNNER and PMMG beautifier that help you calculate production loads.

https://chrome.google.com/webstore/detail/pmmg-extended/cadmmgnpgphgndeeoldoohkcbjkohigg

But think about it. If you have two buildings. And you want to build two different items, each with different production times. The amount of time it takes is irrelevant since the queue system is sequential. If one item takes a second and hte other days a day.

  1. Item A, building 1, 24 hours
  2. Item B, building 2, 1 second
  3. Item B finishes, starts production on Item A
  4. Both buildings are working on item A for 24 hours now.
  5. Both buildings finish Item A, 1 second later, an additional unit of item B gets produced. Final result, 2 of each unit is produced in 24 hours, 2 seconds.

The ratio of productid products will always be 1:1

The amount of time is irrelevant if you plan as “I want x items A and y items B”
But not if you plan as “I want one building dedicated to A, and one dedicated to B”

In this case, ratios of queued time of prod is the solution :
Item A, building 1, 12h (gonna get 2items/24h)
Item B, building 2, 8h (gonna get 3 items/24h)

Need to queue 2 unitary jobs of item A and 3 unitary jobs item B to match a good ratio of production time equivalent to 2 building running the 2 items h24.
It will have at one time the 2 buildings on A, but at another time, the 2 buildings will run on B, and longer because of the 3rd job waiting), catching up.

(Or, a 4-time of A and 6-time of B, it takes only 2 queue slot)

Thanks for the soft, numbers matche my own spreadsheet, it’s reassuring :grinning:

This will still produce 1:1 of each item. You will not make 2:3 of each.

This will produce 2:3 ratio of each product.

Here is another example. This production queue will produce 80 NS for every 20 FLX. In a 4:1 ratio. How long each of these tasks takes is irrelevant. The total sum of the output quantity of ALL queued orders is all that matters.

image

I recommend against thinking of this problem as “dedicating building to x”. I recommend against thinking of the buildings as isolated units. When you have multiple copies of one building, think of it as “one big building”.

I recommend thinking of this problem from the perspective of what is output.

lowstrife is totally correct for the maths. The ratio of the products is given by the ratio of the amounts indicated in the production queue. It does not depend on the duration of each order, nor on the number of production units in the production line. This is however, on average, in the long run. In finite time, there are some “boundary effects”. Like if you load products on a ship every week, and an order takes 5 days, then some weeks (2 weeks out of 5) the double of the usual amount will be available. Lower production times for each order helps “smoothing” the “boundary effects”.