UFOpaedia-friendly Celatid [UNIT] [OXCE]

[hellrazor]

Uploaded this mod to mod.io hosting.

Available under this link: https://mod.io/g/openxcom/m/ufopaedia-celatid-mod

[CrazedHarpooner]

Took the liberty myself to make a couple of changes to your new version.
Changed the tags to:

Code: [Select]

extended:
  tags:
    RuleArmor:
      DELAY: int
      RANDOM_DELAY: int
    BattleUnit:
      TIMER_BU: int
armors:
  - type: CELATID_ARMOR
    psiVision: 13
    tags:
      DELAY: 5
      RANDOM_DELAY: 4
(item tag has been removed)

The script for the 'createItem' hook has been modified so:

Code: [Select]

      createItem: |
        var int timer;
        var int temp;
        var ptr RuleItem itemRuleset;
        var ptr RuleArmor armorRuleset;
        var ptre BattleUnit itemOwner;

        item.getOwner itemOwner;
        if neq itemOwner null;
          itemOwner.getTag timer Tag.TIMER_BU;
          itemOwner.getRuleArmor armorRuleset;
          armorRuleset.getTag temp Tag.DELAY;
          add timer temp;         
          armorRuleset.getTag temp Tag.RANDOM_DELAY;
          if gt temp 0;
            var ptre GeoscapeGame gameGeo;
            var ptre RandomState stateRandom;
            battle_game.getGeoscapeGame gameGeo;
            gameGeo.getRandomState stateRandom;
            stateRandom.randomRange temp 0 temp;
            add timer temp;
          end;
          itemOwner.setTag Tag.TIMER_BU timer;
          offset timer 2 -1;
          limit_lower timer 0;
          item.setFuseTimer timer;
        end;       
        return;

This version of the script now allows ease of customizing the timers. You can set a fixed DELAY and RANDOM_DELAY value as you want. The script will increase the timers cumulatively per each 'embryo' that unit is carrying using the same two tags. This also removes the need to declare individual embryo items with their timers and just use the main 'type' STR_CELATID_EMBRIO like so:

Code: [Select]

  - type: STR_CELATID_TERRORIST
    builtInWeaponSets:
      -
        - CELATID_WEAPON
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
In addition, thanks to having a single item for the embryo, you can now increase the number of carried embryos without having to define new items, just add STR_CELATID_EMBRYO lines to the weaponset list.

If you set DELAY to 7 and RANDOM_DELAY to 0 you'll get your original timers.

[hellrazor]

Took the liberty myself to make a couple of changes to your new version.
Changed the tags to:

Code: [Select]

extended:
  tags:
    RuleArmor:
      DELAY: int
      RANDOM_DELAY: int
    BattleUnit:
      TIMER_BU: int
armors:
  - type: CELATID_ARMOR
    psiVision: 13
    tags:
      DELAY: 5
      RANDOM_DELAY: 4
(item tag has been removed)

The script for the 'createItem' hook has been modified so:

Code: [Select]

      createItem: |
        var int timer;
        var int temp;
        var ptr RuleItem itemRuleset;
        var ptr RuleArmor armorRuleset;
        var ptre BattleUnit itemOwner;

        item.getOwner itemOwner;
        if neq itemOwner null;
          itemOwner.getTag timer Tag.TIMER_BU;
          itemOwner.getRuleArmor armorRuleset;
          armorRuleset.getTag temp Tag.DELAY;
          add timer temp;         
          armorRuleset.getTag temp Tag.RANDOM_DELAY;
          if gt temp 0;
            var ptre GeoscapeGame gameGeo;
            var ptre RandomState stateRandom;
            battle_game.getGeoscapeGame gameGeo;
            gameGeo.getRandomState stateRandom;
            stateRandom.randomRange temp 0 temp;
            add timer temp;
          end;
          itemOwner.setTag Tag.TIMER_BU timer;
          offset timer 2 -1;
          limit_lower timer 0;
          item.setFuseTimer timer;
        end;       
        return;

This version of the script now allows ease of customizing the timers. You can set a fixed DELAY and RANDOM_DELAY value as you want. The script will increase the timers cumulatively per each 'embryo' that unit is carrying using the same two tags. This also removes the need to declare individual embryo items with their timers and just use the main 'type' STR_CELATID_EMBRIO like so:

Code: [Select]

  - type: STR_CELATID_TERRORIST
    builtInWeaponSets:
      -
        - CELATID_WEAPON
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
        - STR_CELATID_EMBRYO
In addition, thanks to having a single item for the embryo, you can now increase the number of carried embryos without having to define new items, just add STR_CELATID_EMBRYO lines to the weaponset list.

If you set DELAY to 7 and RANDOM_DELAY to 0 you'll get your original timers.

Thanks but I am not really interested in a random timer. I specifically removed it from the original script. I wanted to have the cloning time fixed at the end of a alien turn, and let the unit in question loose all TU during that turn. Also it is easier for the player to calculate if he knows the multiplication rate follows a fixed pattern.
I do not think that your script Version will work as expected. I see a few issues, i need the Item to be a semy grenade to play the cloning animation.
Of course the timer can come from the unit or from the armor.

I might give it a try when i find the time, but for the time being i exactly have what i wanted, with a very simple script and some YAML ref-node hooks.

Code: [Select]

      createItem: |
        var int timer;
        var int temp;
        var ptr RuleItem itemRuleset;
        var ptr RuleArmor armorRuleset;
        var ptre BattleUnit itemOwner;

        item.getOwner itemOwner;
        if neq itemOwner null;
          itemOwner.getTag timer Tag.TIMER_BU;
          itemOwner.getRuleArmor armorRuleset;
          armorRuleset.getTag temp Tag.DELAY;
          itemOwner.setTag Tag.TIMER_BU timer;
          offset timer 2 -1;
          limit_lower timer 0;
          item.setFuseTimer timer;
        end;       
        return;
There is no tag for TIMER_BU it is not specified. (i removed the random stuff because unneeded), also there is no unpriming of the Item once they drop towards ground.
KISS -> Keep It Simple / Stupid (a very important principle)

[CrazedHarpooner]

TIMER_BU is specified in the BattleUnit tag. I had named it differently to avoid conflict. If you mean there's no initial value set, that's because unset tags have a value of 0 from my testing and that's the value I want as it represents the cumulative timers that gets updated in this line:

Code: [Select]

itemOwner.setTag Tag.TIMER_BU timer;
As I've mentioned, the randomness can be configured, if you set the RANDOM_DELAY to 0, there will be none and having DELAY set to 7 will follow your original pattern.

I did not add the script that handles the unpriming because your original design did that perfectly fine and worked in combination with my version of the 'createItem' hook. I saw no need to post your code as is without changes for the 'newTurnItem' hook. I probably should of made this clearer.

[hellrazor]

TIMER_BU is specified in the BattleUnit tag. I had named it differently to avoid conflict. If you mean there's no initial value set, that's because unset tags have a value of 0 from my testing and that's the value I want as it represents the cumulative timers that gets updated in this line:

Code: [Select]

itemOwner.setTag Tag.TIMER_BU timer;
As I've mentioned, the randomness can be configured, if you set the RANDOM_DELAY to 0, there will be none and having DELAY set to 7 will follow your original pattern.

I did not add the script that handles the unpriming because your original design did that perfectly fine and worked in combination with my version of the 'createItem' hook. I saw no need to post your code as is without changes for the 'newTurnItem' hook. I probably should of made this clearer.

So TIMER_BU is internally counted up each turn as long as the battle units exists, correct? Or does it represent the total number of turns?
Which opens up a few more questions, will it behave the same way or not?
Despite of that i not really see the advantage of your way of implementing this even thou it might by a valid way of doing it.

And yes i get your point about the randomness being configureable, the point is I removed randomness from the timers for a reason. It was the only way (at least to my knowledge) to make sure the following things happen:

1.) Celatid Cloning occurs at the end of the Alien turn via timer.
2.) In the turn the Celatids clones the Unit will have 0 TU and can not move during its turn (since it is cloning).
3.) This gives the player the chance to kill both units in his next Turn with AOE damage (e.g. a Alien Grenade)

Of course the Celatid can clone also on X-Com turns, but this rather unfair, since the Cloning Unit does not suffer any penalties on its next turn, instead it has full TU and can do everything, also the CLone will have full TU on the next Alien turn, when it is spawned at the end of X-Com term.

Timers represent Turns, 0, 2, 4, 6, 8 etc.. is end of X-Com Turn, 1, 3, 5, 7, 9 is end of Alien Turn. The randomness could work but only if the random timer result would be in the pattern: 1, 3, 5, 7, 9 etc.. representing the ed of the Alien turn.

Also I have to update this standaline mod, since i found the expotential growth pattern to be to harsh on the player. At least for Hardmode Expansion, so i decided to give each Celatid there only one Embryo, which results in a linear growth pattern: 1, 2, 3, 4... / 2, 4, 6, 8 / 4, 8, 12, 16 / 6, 12, 18, 24
Which seems more reasonable. We are talking about free enemy units here. Of course Cydonia is the exception were those Celatids will grow expotentially in number (the brain is the players goal)

I appreciate your effort, nonethless. Thanks.

[CrazedHarpooner]

TIMER_BU is increased per unit after each iteration of the createItem hook. This is what allows for a single item to be used for all grenades. Let's say we use a DELAY of 7 and a RANDOM_DELAY of 0. The 1st emtryo a celatid has will be set to 13 while the the tag will be set to 7, the next emtryo that same celatid is carrying is processed it will use the stored 7, add another 7 and make the adjusment to set the embryo timer to 27 and set the tag to 14 and so on. 3rd Embryo will load the 14 add another 7 and set the timer to 41 and so on. Since TIMER_BU is stored per unit, the timers won't interfere with the timers of another unit.

TIMER_BU doesn't accumulate the actual grenade timers, but rather whole turns accumulated (probably should use a better description) and with this operation here:

Code: [Select]

          offset timer 2 -1;
it converts it to grenade timer. For the 1st embryo this would be (7 x 2) - 1 = 13. 2nd would be (14 x 2) -1 = 27 and 3rd would be (21 x 2) -1 = 41. It has no further use beyond inventory creation for each celatid.

If anything, I would probably change this code that I added as a failsafe:

Code: [Select]

          limit_lower timer 0;
to be:

Code: [Select]

          limit_lower timer 1;
so that the earliest clone would happen at the end of the aliens' first turn rather than at the end of the player's turn in case someone uses extremely low DELAY and RANDOM_DELAY that could go into negative timers and thus disable some of the embryos.

The design of my changes was made to be (mostly) configurable to whoever wants to implement it with different values, hence the 2 tags to set the delays. In addition you're no longer required to define more than 1 embryo item and can use any number of them limited only by how many you load in the builtInWeaponSets and apparently, because of the invWidth and invHeight both being 0, you can define a number of embryos much larger than their inventory size. I've tried it with 36, but that's just me, a madman running experiments that probably should never get released.

Anyway, I've decided to attach the rul file that contains all the code that I've tested it with and a debug message to verify values. Note that while some of the code was modified, it still uses assets that are provided in the mod you've made available, so you might have to rename it or something if you want to test it yourself. Here's the output with DELAY:7 and no RANDOM_DELAY:

Code: [Select]

[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 94)  - Turn: 7  - Timer: 13
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 95)  - Turn: 14  - Timer: 27
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 96)  - Turn: 21  - Timer: 41
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 97)  - Turn: 28  - Timer: 55
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 98)  - Turn: 35  - Timer: 69
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 99)  - Turn: 42  - Timer: 83
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 100)  - Turn: 49  - Timer: 97
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 101)  - Turn: 56  - Timer: 111
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 102)  - Turn: 63  - Timer: 125
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 105)  - Turn: 7  - Timer: 13
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 106)  - Turn: 14  - Timer: 27
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 107)  - Turn: 21  - Timer: 41
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 108)  - Turn: 28  - Timer: 55
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 109)  - Turn: 35  - Timer: 69
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 110)  - Turn: 42  - Timer: 83
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 111)  - Turn: 49  - Timer: 97
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 112)  - Turn: 56  - Timer: 111
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 113)  - Turn: 63  - Timer: 125
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 116)  - Turn: 7  - Timer: 13
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 117)  - Turn: 14  - Timer: 27
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 118)  - Turn: 21  - Timer: 41
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 119)  - Turn: 28  - Timer: 55
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 120)  - Turn: 35  - Timer: 69
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 121)  - Turn: 42  - Timer: 83
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 122)  - Turn: 49  - Timer: 97
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 123)  - Turn: 56  - Timer: 111
[05-02-2025_13-06-42] [DEBUG] Script debug log: Item: BattleItem(name: "STR_CELATID_EMBRYO" id: 124)  - Turn: 63  - Timer: 125

I do agree that my script is overkill if your intent is to have each celatid clone once, but for anyone that might want to use something of the sort I believe it's flexible enough to cover different needs.

[hellrazor]

I do agree that my script is overkill if your intent is to have each celatid clone once, but for anyone that might want to use something of the sort I believe it's flexible enough to cover different needs.

I am using both linear growth with one clone and expotentiell growth.
I do not really see the advantage in the script you created, at least for my use purposes. Othe may find it useful thou.
I want to keep the amount of scripts as small as possible and as understandable as possible, if I have more lines in a ruleset which are easy to understand then so shall by it. I rather define a fixed timervalue then have to determine if the correct values is being pieced together via debug log. But that is just my personal opinion.

See implementation here: https://github.com/hellrazor4223/hardmode-expansion/blob/master/Ruleset/extended_HM.rul
And here: https://github.com/hellrazor4223/hardmode-expansion/blob/f4c138f4d787aa55227011ace5ee01115a164283/Ruleset/items_HM.rul#L3710
And here: https://github.com/hellrazor4223/hardmode-expansion/blob/f4c138f4d787aa55227011ace5ee01115a164283/Ruleset/units_HM.rul#L1335

[hellrazor]

TIMER_BU is increased per unit after each iteration of the createItem hook. This is what allows for a single item to be used for all grenades. Let's say we use a DELAY of 7 and a RANDOM_DELAY of 0. The 1st emtryo a celatid has will be set to 13 while the the tag will be set to 7, the next emtryo that same celatid is carrying is processed it will use the stored 7, add another 7 and make the adjusment to set the embryo timer to 27 and set the tag to 14 and so on. 3rd Embryo will load the 14 add another 7 and set the timer to 41 and so on. Since TIMER_BU is stored per unit, the timers won't interfere with the timers of another unit.

TIMER_BU doesn't accumulate the actual grenade timers, but rather whole turns accumulated (probably should use a better description) and with this operation here:

Code: [Select]

          offset timer 2 -1;
it converts it to grenade timer. For the 1st embryo this would be (7 x 2) - 1 = 13. 2nd would be (14 x 2) -1 = 27 and 3rd would be (21 x 2) -1 = 41. It has no further use beyond inventory creation for each celatid.

If anything, I would probably change this code that I added as a failsafe:

Code: [Select]

          limit_lower timer 0;
to be:

Code: [Select]

          limit_lower timer 1;


I don't get it please try to explain in a way i can understand if you would be so kind. Thanks in advance.

[CrazedHarpooner]

Sure, no problem, but I can't guarantee that I'll be good at it.

I'll start with TIMER_BU, probably a terrible name, perhaps TURNS_BU would be better. It is used as a 'variable' where I store the acumulated number of turns from created embryos (per celatid), it starts at 0 since it's not set. At the end of the script hooked to 'createItem' it gets updated with the total calculated turns based from DELAY and RANDOM_DELAY.  TIMER_BU will be updated per each embryo item created and used for the next embryo item for that celatid. If we use delay values of 7 and 0 respectively for the tags, the first embryo for any celatid will read a value of 0 and at the end save a value of 7, the 2nd embryo will load that value of 7 and save a value of 14 at the end and so on. This tag variable is unique per celatid and each will update idependently based on the number of embryo items the celatid is loaded with. Also, the turns are not necessarily absolute from battle start, but rather relative from celatid spawn.

The 'offset' y-script operator takes 3 values, multiplies the 1st and 2nd, then adds the 3rd to the total and assigns it to the variable used for the 1st value. The way I use it, I always double the value of 'timer' and then add (-1) which of course ends up being a substraction. This ensures the actual embryo timer is set to an odd number. As you've clearly explained yourself, odd timers are used for alien end of turn.
'limit_lower' is just a safeguard for when 'timer' ends up having a value of 0 or negative due to delay values being 0 or negative themselves, setting any value lower than 1 to 1 (previously 0, but that was wrong) ensuring it will go off no earlier than the end of the 1st alien turn..

The reason why I decided to use turns instead of timers for the tags is to simplify the customization without having to calculate the timers. If any modder wants to set the cloning to happen at 8 turn intervals for example, they just need to set DELAY to 8 and the script will handle the conversion to timers and ensure it's done at the end of the alien's turn.

Hope I've managed to explain it in a clear enough manner.

[hellrazor]

Sure, no problem, but I can't guarantee that I'll be good at it.

I'll start with TIMER_BU, probably a terrible name, perhaps TURNS_BU would be better. It is used as a 'variable' where I store the acumulated number of turns from created embryos (per celatid), it starts at 0 since it's not set. At the end of the script hooked to 'createItem' it gets updated with the total calculated turns based from DELAY and RANDOM_DELAY.  TIMER_BU will be updated per each embryo item created and used for the next embryo item for that celatid. If we use delay values of 7 and 0 respectively for the tags, the first embryo for any celatid will read a value of 0 and at the end save a value of 7, the 2nd embryo will load that value of 7 and save a value of 14 at the end and so on. This tag variable is unique per celatid and each will update idependently based on the number of embryo items the celatid is loaded with. Also, the turns are not necessarily absolute from battle start, but rather relative from celatid spawn.

The 'offset' y-script operator takes 3 values, multiplies the 1st and 2nd, then adds the 3rd to the total and assigns it to the variable used for the 1st value. The way I use it, I always double the value of 'timer' and then add (-1) which of course ends up being a substraction. This ensures the actual embryo timer is set to an odd number. As you've clearly explained yourself, odd timers are used for alien end of turn.
'limit_lower' is just a safeguard for when 'timer' ends up having a value of 0 or negative due to delay values being 0 or negative themselves, setting any value lower than 1 to 1 (previously 0, but that was wrong) ensuring it will go off no earlier than the end of the 1st alien turn..

The reason why I decided to use turns instead of timers for the tags is to simplify the customization without having to calculate the timers. If any modder wants to set the cloning to happen at 8 turn intervals for example, they just need to set DELAY to 8 and the script will handle the conversion to timers and ensure it's done at the end of the alien's turn.

Hope I've managed to explain it in a clear enough manner.

Thanks so I actually got it