Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Kzer-Za

Pages: [1] 2 3 ... 10
1
Released Mods / Re: Recovery time revamped [OXCE]
« on: September 27, 2019, 07:35:40 pm »
Hm, I don't actually know how it would mix with infirmary/hospital.

2
Released Mods / Re: Decreased TUs for aliens on your first turn [OXCE]
« on: September 20, 2019, 11:11:49 am »
I suppose it's compatible with TFTD if we change "master: xcom1" to "master: xcom2" ?

Yes, it absolutely should work with TFTD, I just didn't think about it because I don't play it myself :)

3
OXCE Support / Re: Incorrect warning?
« on: September 13, 2019, 08:27:56 pm »
Sorry, I didn't think to mention that `convert` is a part of ImageMagick. I don't know what is correct palette or the correct transparency index, I just made a search on auto correcting transparency in a gif file, and this command seemed to do the trick in the sense that the engine stopped giving a warning. Since there seems to be no simple way of autochanging the transparency color while preserving other colors, I'm gonna just stick with with the acid-colored picture without warnings.

4
OXCE Support / Re: Incorrect warning?
« on: September 13, 2019, 07:01:50 pm »
Well, I know very little about editing graphics, so I simply put the original file through

Code: [Select]
convert retaliator_minimised.gif -transparent black 1.gif

What would be the correct way of fixing the image? (Preferrably, through command line).

5
OXCE Support / [Solved] warning about transparent color index?
« on: September 13, 2019, 06:42:32 pm »
When using this mod https://openxcom.org/forum/index.php/topic,1628.0.html I encountered a strange thing. The game gives this warning:

Code: [Select]
[13-09-2019_18-23-23] [WARN] Image Resources/Retaliator/retaliator_base.gif (from SDL) have set incorrect transparent color index 255 instead of 0

But in-game this image is displayed with correct colors. However, if I fix this image so that the game does not complain about it having incorrect colors, then it's displayed with wrong colors!

I may be wrong, but it seems like a bug to me, since the game has no problem with the file it gives a warning about, and it actually does have issues with the file with no warnings.

If it's something on my side, could someone please tell me how to get rid of this warning? (Because extra warnings catch the eye when you are trying to debug something you are working on, so it bothers me).

I'm going to attach the original gif, "fixed" gif, and the screenshot of what it looks like with the "fixed" gif.

6
Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]
« on: September 07, 2019, 06:07:52 pm »
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.

7
Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]
« on: September 06, 2019, 12:10:28 pm »
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 }".

8
Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]
« on: September 06, 2019, 10:49:49 am »
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

Code: [Select]
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.

9
Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]
« on: September 05, 2019, 11:25:53 am »
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.

10
Released Mods / Re: Chryssalid tweaks [OXCE]
« on: September 02, 2019, 04:41:04 pm »
I haven't looked at X-Com Files (yet?), but theoretically these tweaks should work with any mod as long as the mod in question does not change the id of Chryssalids and Zombies or their armors.

11
Released Mods / Re: Chryssalid tweaks [OXCE]
« on: September 01, 2019, 11:23:00 pm »
Unfortunately, no. It will take quite some work to adapt it to TFTD. But if you know how to script and take a look at the code, it will not be very hard, just long.

12
Released Mods / Chryssalid tweaks [OXCE]
« on: September 01, 2019, 08:50:41 pm »
This mod has two main tweaks and several lesser ones.

Main changes:
(If someone thinks these changes nerf Chryssalids, read through the lesser changes. They are still somewhat nerfed, but lesser changes also give them upsides they didn't have).

1. Originally, Chryssalid's zombifying attack succeeds even if it inflicts no damage. Yes, it fails if they miss completely (i.e. melee accuracy check is failed), but if they hit, then the victim is zombified even when all damage is negated by armor. It makes no sense to me: how are they supposed to inject their venom and plant an egg if their ovipositor (or whatever) didn't pierce the armor? Actually, on this forum there was a suggestion even to make their zombification work only after the damage they inflicted has killed the victim, but I prefer to think that even if they made just a scratch of 1 HP, it's enough to inject the venom. Let's suppose it's potent enough to kill the victim instantly. Still, if there is no scratch => no venom is injected or egg planted => no zombification. So the first change is that the attack should reduce the victim's health by at least 1 HP for zombification to happen.

2. Originally, Chryssalids hatch instantly. If you kill a zombie in the exact same turn in which it was zombified, a Chryssalid is gonna spawn from its remains. This also makes no sense to me. Even though the UFOpaedia mentions Chryssalid's high metabolism, there is a difference between high metabolism and developing a human-size organism from a small egg (Chryssalids carry about twenty of them, according to the same entry in UFOpaedia) in a second. It would be okay in a fantasy setting ("it's magic", and that's it), but not in a sci-fi setting. If they had metabolism rate that fast, they would have to have 100% health recovery, so that if they were not killed in one turn, they would restore from 1 HP to full health by the next turn. And also they would have to be only about 20% vulnerable to all types of damage to reflect the fact that they regenerate almost more quickly than you can harm them.

Also, from the gameplay point of view, it makes the player postpone dealing with zombies: since the zombie is already created, the situation is not gonna get much worse if you leave it alone, but it will get much worse if you kill it and thus hatch a Chryssalid. I think, if the Chryssalids had a reasonable delay before being able to hatch, it would be better by putting the pressure on the player to deal with zombies as soon as possible.

Hence the second change: Chryssalid hatching has a delay of zombification turn (ZT) + 1 turn. During that delay they are spawned dead (unfortunately, making them not spawn at all is impossible). If a zombie is killed on ZT + 2, the Chryssalid is spawned severely underdeveloped, i.e. having 1/3 of its max health and 1/3 of its most important stats (TUs, stamina, reaction, strength, and melee). If the zombie is killed on ZT + 3, the Chryssalid is spawned somewhat underdeveloped, i.e. having 2/3 of its max health and 2/3 of its most important stats. Only on ZT + 4 and later they are spawned fully developed.

Lesser changes:

1. Originally, if a zombie is not killed, the Chryssalid never hatches on its own. Now they shed the husk of the zombie on the ZT + 6.

2. Originally, a Chryssalid keeps attacking its victim until the latter is considered dead, i.e. has 0 or less HP. It tries to "actually kill" the victim even if one of its attacks has already landed, despite the fact that one successful attack is all that's needed and it's not necessary to actually kill the victim. But now, as soon as the Chryssalid lands the first successful strike (deals at least 1 damage to health), it stops attacking the victim and goes on to the next.

3. Now Chryssalids (and zombies too) have no sense of self-preservation. Burning fire? Not enough TUs? Pfft! They don't care, they just charge in. Don't go thinking that makes them less of a threat: it actually makes them far more menacing than before, especially considering the previous change (even if they stop 2 tiles from you, becoming sitting ducks, it still feels more threatening).

4. Especially also considering that they now have a melee skill of 150. Basically, they will never miss, unless they are severely wounded (or underdeveloped). Your hope is the thickness of your armor (and killing them before they get to you, of course).

5. Zombies have somewhat less damaging attack but somewhat more HP than before.

6. If you have the option "Alien bleeding" enabled, zombies previously would receive fatal wounds, same as all other 1-tile units. Now zombies are immune to wounds. They are also immune to stun.

7. All "excessive" damage from the hit that kills a zombie (i.e. the amount of HP that the zombie has in the negative after the hit) is inflicted on the hatching Chryssalid that was inside of it. This damage is still decreased by the Chryssalid's armor, of course. But underdeveloped Chryssalids have significantly worse armor (only for this carryover damage. After they spawn, they have the regular Chryssalid armor). Unfortunately, they get no fatal wounds from this carryover damage, even with the "Alien bleeding" enabled.

8. Speaking of the Chryssalid armor, UFOpaedia says it's "surprisingly vulnerable to explosive ammunition". Now it actually is. (Originally, it wasn't). To compensate for it, I somewhat increased its resistance to armor piercing and melee (it wasn't resistant to them at all) and greatly, to stun.

9. Some people prefer killing civilians "just in case" when there are Chryssalids around. Sorry, but this won't do :) X-COM should protect the population. I doubled the value of civilians (including the Armed Civilians mod): now you get 60 points for each rescued civilian, lose 60 for each one killed by aliens, and lose 100 for each one killed by X-COM.

Have fun! :)

---

Acknowledgements

Thanks to Meridian for OXCE with its huge possibilities for modding and to Yankes for his scripting language and consultations on how to use it.

---

Two important warnings:

1. At the moment of creating this post you have to be using the latest nightly version of OXCE for this mod to work, otherwise the Chryssalids spawned at the start of combat are gonna spawn dead.

2. Currently, the Chryssalids that are supposed to spawn dead due to the introduced hatching delay, are gonna be spawned kinda "undead", i.e. with 0 HP, but in a "live" state. This is not that big a deal: they can't take any action and gonna die as soon as the turn in which they were spawned ends, or as soon as they are shot at (even if the shot misses), whichever comes first. Besides, this is gonna change soon, in one of the coming nightly versions of OXCE.

13
Released Mods / Re: UFOpaedia-friendly Celatid [UNIT] [OXCE]
« on: September 01, 2019, 06:52:00 pm »
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.

14
OXCE Support Y-scripts / Re: Scripting basics
« on: September 01, 2019, 05:02:24 pm »
Thanks!

15
OXCE Support Y-scripts / Re: Scripting basics
« on: September 01, 2019, 02:28:36 pm »
The version that I used up to this morning was 5.6.1 (v2019-08-03), that's where things worked. Today I compiled the new version, which is 5.6.2 (v2019-08-28), that's where the error occurs.

Pages: [1] 2 3 ... 10