[DONE][Suggestion] Add "transferTime" but for manufactured items

[Alex_D]

Currently, a delay for bought items can be specified in "transferTime". Another delay is specified for soldiers and such.
However manufacturing items once made they appear immediately on the base stores.

I'd like to propose the feature to introduce some sort of delay for manufacturing similar to "transferTime". This may apply to any or all items specified under the manufacture order.
The purpose is to simulate claim tickets delivery that is not immediate but take some time to arrive to the base.

I don't know if this would break other things, so please ignore if it's the case.

[shinr]

From the top of my head, the "Spy on Ninjas" project in X-Piratez could use something like this to be more "realistic":

Currently it is:
Runts "producing" the Project (probably simulating Spy support) > Random Results upon completion

With this, it can be:
Runts "produce" preparations (cheaper than above) for the Spy mission > Upon completion, a Delay Simulating the Young Uber spying on Ninjas > Random Results

[Solarius Scorch]

Also, alcohol should need some time to mature, without runts' involvement.

[Yankes]

Also, alcohol should need some time to mature, without runts' involvement.

but should reserve space too, then question is when space req should be checked?

[Solarius Scorch]

but should reserve space too, then question is when space req should be checked?

Depends; I think for winemaking, storage space is enough, but a modder could just as well say that some particular project requires workshop space while it "gestates".
It's a matter of how complicated we want to get.

[Meridian]

...maybe first consider whether you want to endure a popup each time every single bottle of booze is delivered.

[Delian]

Each manufacture project should produce 1 unit of climate change, which comes biting you 10 years later.

[Meridian]

Done.

Sample ruleset:

Code: [Select]

manufacture:
  - name: STR_AVENGER
    transferTimes: [0, 0, 14]

First number is transfer time for items.
Second number is transfer time for scientists, engineers and soldiers.
Third number is transfer time for craft.

Zero means turned off (i.e. no transfer at all).
For personnel, minimum is 1 (hour).

Defaults are: items = 0, craft = 0, personnel = 24.

You don't have to specify all 3 numbers.
For example if the project only produces items, you can also just specify 1 number, example:

Code: [Select]

manufacture:
  - name: STR_PISTOL
    transferTimes: [7]


[Delian]

I think that a single number transferTime would've been enough.

Code: [Select]

manufacture:
  - name: STR_AVENGER
    transferTime: 14


Code: [Select]

manufacture:
  - name: STR_PISTOL
    transferTime: 7

The transfer time is applied to all products, whether it's craft, people, or items. I can't imagine a logical use case where you'd want to produce something, but have the various products delivered at different times.

[Meridian]

There's already manufacturing projects like that today.

E.g. personnel arriving in 24 hours and items added to base instantly.

I'm just backwards-compatible.

Code: [Select]

  - name: STR_TURANIAN_UBER_RECRUITMENT
    spawnedPersonType: STR_SOLDIER_M
    spawnedSoldier:
        rank: 1
        armor: STR_HYENA_RIDER_ARMOR_UC
        currentStats:
          tu: 80
          stamina: 80
          bravery: 70
          throwing: 69
        transformationBonuses:
          STR_HUNTRESS: 1
    producedItems:
      STR_BOW_H: 1
      STR_BOW_H_QUIVER: 10
      STR_KNOIF_BARB: 1
      STR_PIKE: 1
      STR_LUXURY_FUR: 1
      STR_CLOTHING_TRIBAL: 1
      STR_SKULL: 1
      STR_BANDAGE: 2


[Delian]

I know, but every single one of those projects is bugged - either the person should spawn instantly, or he and his items should later arrive together. The only reason they don't is, well, because it couldn't be changed.

As far as backwards compatibility goes, it's already there. If the transferTime is left out, then the functionality remains the same. You don't need an array of 3 numbers to be backwards compatible.

[Yankes]

I know, but every single one of those projects is bugged - either the person should spawn instantly, or he and his items should later arrive together. The only reason they don't is, well, because it couldn't be changed.

As far as backwards compatibility goes, it's already there. If the transferTime is left out, then the functionality remains the same. You don't need an array of 3 numbers to be backwards compatible.

"bug"? I would say "feature" as is how Meridian explicitly implemented it before. And new property reflect it.
Adding only one value only complicate code to make it backward compatible and reduce configurations possibles.
Beside we already have cases when we "reuse same property for multiple uses" but soon after backpedal it split it into
multiple properties because old version blocks some use cases.