[DONE] [Suggestion] Changing alien base deployment by time passed

[Meridian]

Great!
The syntaxis has been not changed?

No change, syntax is still the same.

[robin]

nooOOOoooo stop adding good features i absolutely must use!
 
thanks for adding it.

[davide]

nooOOOoooo stop adding good features i absolutely must use!
 
thanks for adding it.

....It is a double strike!!

[robin]

Question: do I need to add the progression to every deployment in the chain, or only to the first one?

example A:

Code: [Select]

  - type: STR_BASE_0
    alienBaseUpgrades:
      0:
        STR_BASE_0: 100
      1:
        STR_BASE_1: 100
    data:
      ...

  - type: STR_BASE_1
    alienBaseUpgrades:
      0:
        STR_BASE_1: 100
    data:
      ...
example B:

Code: [Select]

  - type: STR_BASE_0
    alienBaseUpgrades:
      0:
        STR_BASE_0: 100
      1:
        STR_BASE_1: 100
    data:
      ...

  - type: STR_BASE_1
    data:
      ...

[Meridian]

That's a damn good question... I wanted to implement B (only first one), but I have implemented A (every deployment in the chain).

I can change that easily... but before I do... which one would you prefer?

[robin]

I think after all that A is better.
The reason is that, in the mission scripts, you can make the chain start from an advanced point, as the game progresses, and it will still upgrade from there.
Example:

Code: [Select]

missionScripts:
  - type: alienBase
    missionWeights:
      0:
        STR_BASE0: 100
      2:
        STR_BASE1: 100
      4:
        STR_BASE2: 100

alienDeployments:
  - type: STR_BASE_2
    alienBaseUpgrades:
      0:
        STR_BASE_2: 100
      2:
        STR_BASE_3: 100
    data:
      ...
From month 4 missionScripts spawns BASE_2 bases directly, but the progression to BASE_3 still happens because it is directly defined for BASE_2; if the upgrades were defined only on BASE_0, I guess the progression wouldn't happen if you start from BASE_2.
Sure there is some duplicate data, but it matters little.

[Nord]

Please, point me to the right syntax.
How is correct:

Spoiler:

  - type: STR_ALIEN_NEST_1
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_1: 100
      2:
        STR_ALIEN_NEST_2: 100
      4:
        STR_ALIEN_NEST_3: 100

  - type: STR_ALIEN_NEST_2
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_1: 100
      2:
        STR_ALIEN_NEST_2: 100
      4:
        STR_ALIEN_NEST_3: 100

or

Spoiler:

  - type: STR_ALIEN_NEST_1
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_1: 100
      2:
        STR_ALIEN_NEST_2: 100

  - type: STR_ALIEN_NEST_2
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_2: 100
      2:
        STR_ALIEN_NEST_3: 100

Thanks.

[Thermite]

Would this be available as a default (the mods that come with the install on the standard folder) mod?

[ohartenstein23]

Would this be available as a default (the mods that come with the install on the standard folder) mod?

No. The standard folder is only for recreating the original game and the UFOExtender/XComUtil features. Any features OXCE adds will have to be activated by a mod in the users folder. In other words, almost nothing in OXCE is activated "by default".

[Thermite]

No. The standard folder is only for recreating the original game and the UFOExtender/XComUtil features. Any features OXCE adds will have to be activated by a mod in the users folder. In other words, almost nothing in OXCE is activated "by default".

I see...
Thanks

[Meridian]

Please, point me to the right syntax.

Syntactically, both are correct.

Semantically, the first option is better IMO.
But I would even suggest a third option (to prevent accidental downgrade back to STR_ALIEN_NEST_1 in case you make it more complicated):

Code: [Select]

  - type: STR_ALIEN_NEST_1
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_1: 100
      2:
        STR_ALIEN_NEST_2: 100
      4:
        STR_ALIEN_NEST_3: 100

  - type: STR_ALIEN_NEST_2
...
    alienBaseUpgrades:
      0:
        STR_ALIEN_NEST_2: 100
      4:
        STR_ALIEN_NEST_3: 100

The number of months is always "since the creation of the original base"... when upgrading a base, its age does NOT reset back to zero months.

[Nord]

The number of months is always "since the creation of the original base"... when upgrading a base, its age does NOT reset back to zero months.

This is a key, thanks.

[Meridian]

Since OXCE 7.3 it is possible to reset the base age when upgrading.

Let's assume you are upgrading an alien base with deployment type A into deployment B.

To reset the base age, you have two options:
1. set `resetAlienBaseAgeAfterUpgrade: true` on deployment A
2. or set `resetAlienBaseAge: true` on deployment B

[Meridian]

Since OXCE 7.4.4 it is possible to change the race of an alien base during the upgrade.

Attribute `upgradeRace`

Example:

Code: [Select]

alienDeployments:
  - type: STR_ALIEN_BASE_OLD
    alienBaseUpgrades:
      0:
        STR_ALIEN_BASE_OLD: 100
      3:
        STR_ALIEN_BASE_NEW_MUTONS: 100


Code: [Select]

alienDeployments:
  - type: STR_ALIEN_BASE_NEW_MUTONS
    upgradeRace: STR_MUTON