OpenXcom Forum
Modding => Released Mods => Topic started by: Kzer-Za on August 21, 2019, 05:28:30 pm
-
The UFOpaedia states that the Celatid:
1. appears to detect human brain waves and will move towards a human target even if well hidden;
2. has the ability to clone itself at an alarming rate.
So I decided to give them both these abilities :) Now they can feel you outside of line of sight within 13 tiles from themselves, and every third turn (± one turn) they are gonna split out a clone. These clones are actually slightly weaker than the adult Celatid, and cannot reproduce yet, since I decided that the time they are gonna need to mature must last more than what combat spans. And since splitting itself approximately into two takes time, during the turn in which it clones itself, the Celatid has only 50% TUs.
This mod still has some quirks that I can't (or don't know how to) iron out for now, but they are minor.
1. Since the only way to spawn an enemy during combat is via a weapon, the Celatids are actually carrying around grenades that do nothing more than spawn the clones. These grenades can be picked up from the Celatid corpse. I did not assign any sprites to them, so you won't see them, but if you move your mouse pointer next to the Celatid corpse (in the Inventory screen, when standing on the tile with the corpse), you can pick them up. There is no way around this for now. Fixed.
2. If the Celatid was killed during the alien turn in the end of which it was gonna clone itself (i.e. alien turns 3, 6, 9, etc (± one turn)), then even though it's dead, its clone will still appear in the end of this turn. This is gonna be rather rare because it can only happen if it's killed during the alien turn, and only every third alien turn to boot, but it's still possible (if the Celatid is killed with reaction fire from your troops or with friendly fire from aliens). There is also no way around this for now.
Other than that it works fine.
I would like to express my gratitude to Yankes for his script language and his explanations on how to use it, and to Meridian and Solarius Scorch for explanations on rulesets.
---
Attached the version 0.9. The first of the mentioned issues is fixed.
-
Nice work Mate, i will try this out this weekend as i would like to bring it into my OXC Factions total conversuon mod.
-
You are welcome to use it :)
-
This looks pretty swell, thank you! Nobody did the Celatid cloning before.
1. Since the only way to spawn an enemy during combat is via a weapon, the Celatids are actually carrying around grenades that do nothing more than spawn the clones. When these grenades go off, you can see flame as from an explosion beneath the Celatid and smoke above it appearing for a brief moment. If someone tells me how to get rid of these effects, I would be very grateful.
Create an empty X1.PCK entry and use it as hitAnimation. (Empty, or something else - up to you.)
For example I made an EMP grenade with custom explosion graphics:
extraSprites:
- type: X1.PCK
width: 1024
height: 64
subX: 128
subY: 64
files:
80: Resources/Weapons_Compilation/ExplosionAnimations/Triple_Ripple_exp.png
88: Resources/Weapons_Compilation/ExplosionAnimations/Grey_Skull_exp.png
96: Resources/Weapons_Compilation/ExplosionAnimations/EMP_Explosion.png <---- this one
104: Resources/Weapons_Compilation/ExplosionAnimations/Red_Skull_exp.png
112: Resources/Weapons_Compilation/ExplosionAnimations/Green_Skull_exp.png
items:
- type: STR_EMP_GRENADE
hitAnimation: 96
2. These grenades can be picked up from the Celatid corpse. I did not assign any sprites to them, so you won't see them, but if you move your mouse pointer next to the Celatid corpse (in the Inventory screen, when standing on the tile with the corpse), you can pick them up. There is no way around this for now.
I think it would be okay to make it totally visible for the player and even recoverable as "Celatid Egg", Celatid Spore" or something like that. Why not?
3. If the Celatid was killed during the alien turn in the end of which it was gonna clone itself (i.e. alien turns 3, 6, 9, etc (± one turn)), then even though it's dead, its clone will still appear in the end of this turn. This is gonna be rather rare because it can only happen if it's killed during the alien turn, and only every third alien turn to boot, but it's still possible (if the Celatid is killed with reaction fire from your troops or with friendly fire from aliens). There is also no way around this for now.
I don't think it's an issue. Sounds like a nice surprise.
-
I don't think it's an issue. Sounds like a nice surprise.
Or even make it a game mechanic, spore die 2 turns after host, you need some explosive to kill it (change item armor to be bit lower than in normal items).
And you can manually "kill" it by unpriming it (you can change name of this action to "kill spore").
Item can have different look in inventory when its "live" or when its "die".
-
1. Maybe I'm doing something wrong, but it doesn't seem to be working. If I specify an empty X1.PCK like this:
extraSprites:
- type: X1.PCK
the game just displays the same one-tile explosion as before. If I add a path to a non-existent file, it crashes. If I give it a transparent png I found on my computer, it crashes.
2, 3, and Yankes's suggestion: I would need sprites of these objects for it. And since anything I draw is not even half-decent, I can't make mods with graphics. Maybe if this mod actually finds some users, and one of them would be willing to contribute the graphics...
-
Can you post your code?
-
Well, I made only two changes to the code: inserted the piece from my previous message in the end of the file, and inserted hitAnimation in the item description like this:
- &STR_CELATID_GEMMA
type: STR_CELATID_GEMMA
size: 0.1
weight: 0
power: 0
damageType: 0
battleType: 4
blastRadius: 0
hitAnimation: 96 # the inserted line
# fixedWeapon: true
...
-
Ah, if I try to add an empty file, then the part with the X1.PCK looks like this:
extraSprites:
- type: X1.PCK
width: 1024
height: 64
subX: 128
subY: 64
files:
96: Resources/UFOpaedia-friendly_Celatid/Blank.png
And I place the specified png to the specified location, of course.
-
I am shooting blind here, but try changing damageType to 3. I doubt 0 would play nice with explosions.
-
Yes, changing it to 3 did work!
Updated the attached file.
-
I did not assign any sprites to them, so you won't see them, but if you move your mouse pointer next to the Celatid corpse (in the Inventory screen, when standing on the tile with the corpse), you can pick them up. There is no way around this for now.
I think assigning
invWidth: 0
invHeight: 0will help.
2. If the Celatid was killed during the alien turn in the end of which it was gonna clone itself (i.e. alien turns 3, 6, 9, etc (± one turn)), then even though it's dead, its clone will still appear in the end of this turn. This is gonna be rather rare because it can only happen if it's killed during the alien turn, and only every third alien turn to boot, but it's still possible (if the Celatid is killed with reaction fire from your troops or with friendly fire from aliens). There is also no way around this for now.
You can, for example, give these eggs "armor: 1" and make celatid exploding on death with "power: 2".
Btw, great minimods.
-
Thanks, I'l try that, when I get around to it in a couple of days.
-
Unfortunately, the second suggestion doesn't work, it seems that the items are dropped only after the corpse explosion takes place. But assigning the zero inventory size does work, so at least these grenades now can't be picked up :)
Updated the attached file.
-
Nice work!
It's nice to see the issue of making the Celatid lore-friendly being tackled again.
So I decided to give them both these abilities :) Now they can feel you outside of line of sight within 13 tiles from themselves, and every third turn (± one turn) they are gonna split out a clone. These clones are actually slightly weaker than the adult Celatid, and cannot reproduce yet, since I decided that the time they are gonna need to mature must last more than what combat spans. And since splitting itself approximately into two takes time, during the turn in which it clones itself, the Celatid has only 50% TUs.
luke83 made a good point here (https://openxcom.org/forum/index.php/topic,1314.0.html)that perhaps the cloning rate should vary with the chosen difficulty level otherwise players will either be overwhelmed or underwhelmed (or perhaps just whelmed).
Right now you have it at every 3rd turn and it's possible that might be a bit much.
I'll let you know how I fared after I encounter a Celatid.
2. If the Celatid was killed during the alien turn in the end of which it was gonna clone itself (i.e. alien turns 3, 6, 9, etc (± one turn)), then even though it's dead, its clone will still appear in the end of this turn. This is gonna be rather rare because it can only happen if it's killed during the alien turn, and only every third alien turn to boot, but it's still possible (if the Celatid is killed with reaction fire from your troops or with friendly fire from aliens). There is also no way around this for now.
I don't think it's an issue. Sounds like a nice surprise.
It's not what you intended but I agree with Solarius that it'd make for a nice surprise.
Maybe make it random?
I think it would be okay to make it totally visible for the player and even recoverable as "Celatid Egg", Celatid Spore" or something like that. Why not?
2, 3, and Yankes's suggestion: I would need sprites of these objects for it. And since anything I draw is not even half-decent, I can't make mods with graphics. Maybe if this mod actually finds some users, and one of them would be willing to contribute the graphics...
clownagent points out here (https://openxcom.org/forum/index.php/topic,2608.0.html)that the Celatid animation sequuence actually consisits of 28 frames and only the first ~8 are used.
So you probably don't need to draw anything as there's a lot of material to work with already.
In fact, the right combination of frames can show the cloning process, whether you want it to be from a live Celatid or a dead one.
As an added bonus, frame 25 shows what looks to be a Celatid Egg/Spore. So you can do something interesting with that as well.
-
I think the difficulty is already factored in by the amount of Celatids originally spawned in the map. Where on one level you would encounter 1 Celatid, on another you encounter, say 4. Each of them creates a clone every X turns, so the amount of clones is already proportional to the difficulty level. If I also increase their cloning rate with level, the difference between the levels will be too sharp. What "X" is equal to is another matter, this is debatable. I thought that if I made it less than three, then most players would see Celatids clone themselves too rarely. Besides, now they attack not so often as before, because, as I mentioned in the description, I thought that cloning should take some time, so on the cloning turn they have 50% TUs. But if people think that 3 turns is too frequent, I will decrease it. Perhaps, 5 turns?
Concerning the unused frames: that's a good idea, but can you explain how to use them? Since I can't draw, I didn't bother learning how to use existing sprites either. Also, there is the issue of the embryo sprite for inventory. Ok, for this I can repaint a stun bomb into green, perhaps. But I still would need a PNG of a stun bomb.
-
I think the difficulty is already factored in by the amount of Celatids originally spawned in the map. Where on one level you would encounter 1 Celatid, on another you encounter, say 4. Each of them creates a clone every X turns, so the amount of clones is already proportional to the difficulty level.
This is a good point that slipped my mind.
I used the battle generator to test it out but after the 3rd/4th turn the game crashed with the following error:
[FATAL] A fatal error has occurred: Invlid surface set 'BIGOBS.PCK' for item 'CELATID_CLONE_WEAPON': not enough frames
Either OXCE-5.6.2-1e89df63f-2019-08-15 isn't enough or you are missing something trivial in CELATID_CLONE_WEAPON.
Concerning the unused frames: that's a good idea, but can you explain how to use them? Since I can't draw, I didn't bother learning how to use existing sprites either. Also, there is the issue of the embryo sprite for inventory.
Download and extract MapView2 (also called OpenXCOM.Tools) from here (https://github.com/kevL/OpenXCOM.Tools/tree/master/Distribution).
Copy CELATID.PKG & CELATID.TAB from UFO\UNITS (so you are not directly modifying the game files) and open CELATID.PKG with PckView which is bundled with MapView2 (also called OpenXCOM.Tools) by navigating to File > "Open Pck (terrain/unit)".
When you are successful, you'll see something like this (https://www.ufopaedia.org/index.php?title=CELATID.PCK).
Now for some technical stuff, Celatids use drawing routine 9 and are in constant animations.
Referencing the relevant code here (https://github.com/OpenXcom/OpenXcom/blob/8d6694b8d86859765c7a3ebdbde9e3e03f3a61c0/src/Battlescape/UnitSprite.cpp#L1324-L1351)and here (https://github.com/OpenXcom/OpenXcom/blob/8d6694b8d86859765c7a3ebdbde9e3e03f3a61c0/src/Battlescape/Map.cpp#L1325-L1358) shows that their living sequence is hardcoded to start on frame 0 and end on frame 7 (8 frames altogether), whereas their death sequence simply starts on frame 25 and is limited to 3 frames by default (e.g. the death sequence could probably be from frame 25 to 50).
This means that to create new animation sequences for drawing routine 9, you need to define frames 0 to 7 and then frames 25 to 27 (i.e. frames 8 to 24 can be blank since they will be ignored anyway) and unless you increase the number of death frames (i.e. deathFrames (https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)#Armor)).
PckView is surprisingly powerful and can accomplish this with relative ease.
Ok, for this I can repaint a stun bomb into green, perhaps. But I still would need a PNG of a stun bomb.
PckView lets you paint with pixel precision.
Just copy BIGOBS.PKG & BIGOBS.TAB from UFO\UNITS and open BIGOBS.PKG with with PckView by navigating to File > "Open Pck (bigobs)" where you'll find the stun bomb on frame 38.
Actually, you know what, I made some time and attached some proof of concepts (just to show it can be done). I only consider the repainted stun bomb "final" but the clone animation sequence from the Celatid egg/spore could definitely be more seamless.
Note: I used ImageMagick to turn a sequence of PNG files into GIF format since PckView can't do that. For the game you can just have a custom pair of PCK and TAB files.
Edit: I was able to fix the crash by replacing:
builtInWeapons:
- CELATID_CLONE_WEAPON
with:
livingWeapon: true
and removing:
extraSprites:
- type: X1.PCK
-
Concerning the crash with the CELATID_CLONE_WEAPON; that's strange, I tested it on a nightly version 5.6.1 (v2019-08-03) and on 5.6.2 (v2019-08-28), both didn't crash. Maybe something was temporarily up with OXCE-5.6.2-1e89df63f-2019-08-15? Besides, I created this weapon by simply copying the rule of the original CELATID_WEAPON and decreasing the power and accuracy, since I wanted the clones to be slightly weaker than full-grown Celatids. So, maybe it was removing of
extraSprites:
- type: X1.PCK
that fixed the issue? Though in my installation I didn't have problems with that. Could you please check if this issue is there with the latest nightly?
And thanks for the explanations on animations! I'll get to it in about a week, when I have some time again.
-
Concerning the crash with the CELATID_CLONE_WEAPON; that's strange, I tested it on a nightly version 5.6.1 (v2019-08-03) and on 5.6.2 (v2019-08-28), both didn't crash. Maybe something was temporarily up with OXCE-5.6.2-1e89df63f-2019-08-15? Besides, I created this weapon by simply copying the rule of the original CELATID_WEAPON and decreasing the power and accuracy, since I wanted the clones to be slightly weaker than full-grown Celatids. So, maybe it was removing of
extraSprites:
- type: X1.PCK
that fixed the issue? Though in my installation I didn't have problems with that. Could you please check if this issue is there with the latest nightly?
And thanks for the explanations on animations! I'll get to it in about a week, when I have some time again.
probably incorrect reuse of bigobs from xcom1, read more here: https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)#Negative_indices_and_cross-referencing_other_mods
-
Strange that in my case everything is working, but to be on the safe side I replaced in CELATID_CLONE_WEAPON "bigSprite: 60" with "bigSprite: { mod: xcom1, index: 60 }".
-
Concerning the crash with the CELATID_CLONE_WEAPON; that's strange, I tested it on a nightly version 5.6.1 (v2019-08-03) and on 5.6.2 (v2019-08-28), both didn't crash. Maybe something was temporarily up with OXCE-5.6.2-1e89df63f-2019-08-15? Besides, I created this weapon by simply copying the rule of the original CELATID_WEAPON and decreasing the power and accuracy, since I wanted the clones to be slightly weaker than full-grown Celatids. So, maybe it was removing of
extraSprites:
- type: X1.PCK
that fixed the issue? Though in my installation I didn't have problems with that.
Technically what I had were 2 separate crashes with the same reason given.
The first crash happened on the 3rd turn and was fixed by removing the extraSprites section.
After that, the second crash happened on 4th turn and was fixed by defining livingWeapon.
I find it strange myself that this fixed it.
A couple things though... why is the extraSprites section there? X1.PCK contains the grenade animation which isn't used here. From what I see that section should be removed irregardless.
At first glance, the ruleset reference suggests that defining lvingWeapon won't work since it requires the "grenades" be marked as fixedWeapon which mean they can't be dropped but when I tested it, the cloning process still worked.
Could you please check if this issue is there with the latest nightly?
For the record, whatever is linked here (https://openxcom.org/forum/index.php/topic,5258.0.html)is what I consider to be the latest OXCE "nightly". If you are building from scratch or using an unlinked version you'll probably only have a handful of people who will experience your mod as intended.
Which, incidentally, is why when I tested your Chryssalid tweaks, they all spawned dead.
Edit: I did some digging around and found https://lxnt.wtf/oxem/#/Extended which is labeled as "Latest version(s) for Linux" in the main post but also contains builds for Windows.
Either the main post should be updated or anything newer than 5.6.2-1e89df63f-2019-08-15 are "nightly nighties" and it might be a safe assumption that most are not using it.
Strange that in my case everything is working, but to be on the safe side I replaced in CELATID_CLONE_WEAPON "bigSprite: 60" with "bigSprite: { mod: xcom1, index: 60 }".
I reverted my changes and used this instead and everything worked as intended.
I still question the extraSprites section though.
I'll let you know how I fared after I encounter a Celatid.
That said... since I had some times I went quite a few rounds with your Celatids and I think 3 turns might just indeed be balanced.
However, I think the primary Celatids should act more like rear commanders. This means removing psiVision from the primaries and giving it to the clones instead. This prevents the primaries from charging towards possible targets and thus increases the possibility that they'll survive to create more clones.
But to make the primaries somewhat opportunistic, the primaries should be marked with sniper while the clones should be marked with spotter. This means that the primaries could potentially attack what the clones see.
I get that you are want the Celatids to be UFOpedia-friendly so if you are opposed to removing psiVision from them, consider reducing it by a bit less than half (like say 6) and take it as though the primaries are more resistant to human brain waves.
Just my two cents.
-
Maybe extrasprites is not really needed, I added it as a part of the patch that removed explosion animation from the "grenades" when they went off.
About making Celatid clones into spotters I'm apprehensive because, as far as I know, you can't limit spotters to relaying their information to only a certain type of units. I mean, it would be okay if they spotted only for primary Celatids (kind of psi-link between them), but if someone uses a mod in which, e.g. Muton navigators are snipers, then they (navigators) would also get information from the clones. That would, in my opinion, be unreasonable both from the "realism" point of view since Celatids are not sentient, and from the gameplay one since it would essentially give non-Celatid snipers psi-vision too (since Celatids would detect someone with psi-vision and relay that information to snipers).
To make primary Celatids more or less stay in hiding it's not necessary to decrease their psi-vision radius. We can just decrease their aggression to 1 or 0. I think, 1 would be okay, and I made this change, but I won't be able to test it for a week or so.
-
About making Celatid clones into spotters I'm apprehensive because, as far as I know, you can't limit spotters to relaying their information to only a certain type of units. I mean, it would be okay if they spotted only for primary Celatids (kind of psi-link between them), but if someone uses a mod in which, e.g. Muton navigators are snipers, then they (navigators) would also get information from the clones. That would, in my opinion, be unreasonable both from the "realism" point of view since Celatids are not sentient, and from the gameplay one since it would essentially give non-Celatid snipers psi-vision too (since Celatids would detect someone with psi-vision and relay that information to snipers).
I knew about this concern but I never experienced it myself so I left my theoretical changes in place until I encountered a Celatid.
And boy, oh boy... it was a slaughter. The clone Celatids took point and the Mutons rained reaction fire. I lost over half my troops (barely taking out 4 aliens in the process) before I noped out of there.
Definitely felt "cheaty".
To make primary Celatids more or less stay in hiding it's not necessary to decrease their psi-vision radius. We can just decrease their aggression to 1 or 0. I think, 1 would be okay, and I made this change, but I won't be able to test it for a week or so.
So yeah, unless the spotter/sniper values can be further restricted that idea is out the window.
I'm going to try reducing the aggression instead as you mentioned.
-
A further lore-friendliness problem rears its head from the limitations of psiVision: Namely, the inability (unless the Wiki needs updating) to define specific units that can or can't be spotted by specific armour's psiVision at all, or by it in general other than through fearImmune. Celatids can detect human brainwaves according to the 'pedia, but would also be able to psisee dogs, Sectoid hybrids, Tau, elves, or whatever other player units you have in your modpack that are subject to morale rules. (and as an aside, that also means you'd have a harder time of making heroes who are immune to panic but can still be psi sensed, but I'm pretty sure that's possible by tinkering with bravery formulae)
But that is/was a limitation of OXCE, not a problem with this mod. Just wanted to mention it.
-
Seeing people while not seeing elves or dogs reeks of BS anyway. I can't come up with a single explanation for it, apart from magic (probably poorly designed).
-
Stunned celatid clone unit cannot be recovered alive, because the corresponding geoscape item is missing.
You can fix the mod by adding an item like this:
- type: STR_CELATID_CLONE
size: 0.0
recover: true
liveAlien: true
costSell: 40000
-
Stunned celatid clone unit cannot be recovered alive, because the corresponding geoscape item is missing.
You can fix the mod by adding an item like this:
- type: STR_CELATID_CLONE
size: 0.0
recover: true
liveAlien: true
costSell: 40000
Is there a way for me as a modder to know which specific frames in a given pck are missing? Currently, the debug message states only that some frames are missing, but does not say which.
-
Cool! But let me point at the elephant in this room. That is, implications.
The floating system of Celatids is said to be a “naturally” grown anti-grav, rather than lighter-than-air. So it looks like they are mostly a bio-technological way to produce small antigrav units, moonlighting as a hunter-killer (as a side effect or with divergence from purely “industrial” breed). If captured alive, breeding and harvesting Celatids looks like a good way to churn out small (i.e. useful for hardware smaller than aircraft) antigrav modules without taxing your workshop and engineers. Perhaps setting up a Celatid farm would require something like a small-scale version of Mind Shield. Or maybe just use telepath minders.
Also, there are two possibilities:
- Celatids use Elerium.
So it’s the “usual” Elerium-based antigrav, just biologically produced. In this case beside all other materials its reproduction is limited by having enough of Elerium to “refuel” the young. Mechanically perhaps Elerium would be “ammunition” for the spawning pseudo-weapon. Also, Elerium could be extracted from the Celatid corpses (or maybe from Elerium bladders dropped as “ammunition”). - Celatids don’t use Elerium.
Then their reproduction is not necessarily limited by exotic materials… but of course as a source of antigravity systems not dependent on Elerium they would become the second most important resource.
Also, can it feed itself? The fun option is yes, because then you could let them pick up items, and…
- If there is a way to customize item attraction (maybe with scripts?) make raw Elerium attractive for them, so in those rare cases when a Celatids is near Power Source broken by a shot (including its own), you either put it down very quickly or will be ears-deep in Celatids in a few turns.
- And/or just allow them to pick up the usual stuff per “Aliens Pick Up Weapons” standard mod, but have on-turn script to handle extraction of Elerium contents from the picked items that require it for production (such as plasma weapon magazines). That is, destroy the source item and “reload” the spawning pseudo-weapon or increase the reproduction readiness variable.
Destruction of raw Elerium or dropped alien artifacts would also give X-Com an incentive to neutralize the floating bladders ASAP.
Either way, if they tend to spawn soon after picking up objects, it will happen more often where the player can see their reproduction by fission (near broken stuff or downed armed aliens respectively).
Besides, now they attack not so often as before, because, as I mentioned in the description, I thought that cloning should take some time, so on the cloning turn they have 50% TUs.
However, I think the primary Celatids should act more like rear commanders. This means removing psiVision from the primaries and giving it to the clones instead. This prevents the primaries from charging towards possible targets and thus increases the possibility that they'll survive to create more clones.
That may be going too far. Just reducing the value (range) would make them less feisty.
But… if their actual (acid spit) weapon has limited ammunition (but gradually recharged on its own), they are going to run ahead less and hide more, right?
Also, the part with sack going down without green “blood” would look less weird for spawning than spitting animation. Is this k/o animation? Maybe just stun it in script (barely, so it recovers on the next round). So it’s given the “armed” spawning item, then knocked out, so it drops the item, which “goes off” and spawns?
-
I took the Freedom of making my own Version of this.
Celatids will now Clone Celatids and there is a animation for the Cloneing.
Even thou i am not really satiesfied with this. A new Sprite showing the Celatid emerging is needed.
And during the Animation the Orginal Units Sprites should ne invisible, so the Animation is clearly visible (it starts with a Frame of the Original Celatid Armor sprite).
Attaching this here for People who one try this out.
Each Celatid can Clone itself about 6 times and the clones are normal Celatids, so they grow quickly in number!
Maybe we need some nerf for this, e.g. make both units unconscious for a turn or so after split?
-
Ok I managed to tackle it. Tested it also and had fun with this. 8) 8)
I think i found a ok balance for vanilla and for vanilla based mods, these creatures follow a expotenzial growth pattern,
so do not let them linger to long in the corner or you might get overrun.
I am putting this menace on mod.io, so everyone can enjoy. https://mod.io/g/openxcom/m/ufopaedia-celatid-mod
UFOpaedia Celatid Mod v1.0
Author: Kzer-Za, hellrazor
According to the UFOpaedia Celatids should appear to detect human brain waves and will move towards a human target even if well hidden.
And Celatids should have the ability to clone itself at an alarming rate.
So it was decided to give them both of these abilities.
Now they can feel you outside of line of sight within 13 tiles from themselves, and every third turn seventh turn they are gonna split out a clone.
And since splitting itself approximately into two takes time, during the turn in which it clones itself, the Celatid has only 0 TUs.
-------
CHANGELOG:
1.0:
Fix problems Mod not loading on OXCE 8.0.0
Fix problems with Mod not properly working
Adjust Cloning Timers slightly, so Cloning take place on Alien turn 7
Added Cloning Animation as hitAnimation
Removed Clones replaced by normal Celatids
0.9:
Fixed Celatids leaving invisible but pickable "grenades" on their deaths.
0.8:
Fixed the explosion animation being showed when a clone is spawned.
0.71:
Fixed the Celatid gammae being recovered in the end of mission.
0.7:
Release
INSTALL INSTRUCTIONS:
#UFOpaedia_Celatid Mod by Kzer-Za, hellrazor
#Prerequisites:
This mod requires at least:
OXCE: OXCE v7.15+ see: https://openxcom.org/forum/index.php/topic,5258.0.html
or newer (Newer Versions can include changes, which requires the mod to be updated or patched)
Please report all issues and bugs here: https://openxcom.org/forum/index.php?topic=7307.0
#Install instructions:
- Go to your Mod folder and delete the old "UFOpaedia_Celatid" directory.
- Extract Zip file
- Copy over the directory "UFOpaedia_Celatid" in your user mods directory.
- Activate "UFOpaedia_Celatid" under Mods
-
Uploaded this mod to mod.io hosting.
Available under this link: https://mod.io/g/openxcom/m/ufopaedia-celatid-mod
-
Took the liberty myself to make a couple of changes to your new version.
Changed the tags to:
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:
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:
- 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.
-
Took the liberty myself to make a couple of changes to your new version.
Changed the tags to:
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:
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:
- 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.
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)
-
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:
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.
-
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:
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.
-
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:
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:
limit_lower timer 0;
to be:
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:
[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.
-
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
-
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:
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:
limit_lower timer 0;
to be:
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.
-
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.
-
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 :)