Solar's wishlist

[Meridian]

Okay, thanks for the honest and candid reply. If you can give me a short and detail answer, that will be much appreciated.

1. costMelee and all similar attributes will remain unchanged, they work 100% as intended... any change would be a bug
2. I am not planning to make melee do AOE damage
3. I also don't see any reason for battleType=12, it's not the weapon that explodes, it's the unit that explodes/self-destructs
4. Self-destruct can be a simple false/true flag on a unit... the actual self-destruct would be a new code, not reusing any existing mechanic... it would also be completely independent from leeroyJenkins and everything else mentioned above, I don't see any reason to "bastardize" (sorry for expression) well-defined existing features
5. The parameters of the self-destruct explosion (type, power, etc.) would be defined either via a dummy item linked to the unit; or by a few new attributes on the unit itself

All new attributes are subject to change during actual implementation, depending on compatibility with other features and potential extension of cyberdisc/bio-drone self-destruct triggers, power and type.

6. terrain destruction by melee is completely offtopic for self-destructing units... and will be handled completely separately... not going to describe it here

Lastly, of the two path I laid down above, which would you go to code it. If you approve of this feature.

None. They are both bad (in context of OpenXcom).

[wcho035]

Thank you Meridian, for this detail and through reply. It is stunting to me that neither of my suggested path would work. However, I am also humbled by the mastery and design which you have in mind to solve this. This also allow me to appreciate too, if the request may seem small but the strategy to pull it off is a lot more.

Again, thank you for this.

[krautbernd]

All new attributes are subject to change during actual implementation, depending on compatibility with other features and potential extension of cyberdisc/bio-drone self-destruct triggers, power and type.

Might this include the possibility of 'disarming' units that are set to self-destruct, in case stunned units wake up again?

[Meridian]

Might this include the possibility of 'disarming' units that are set to self-destruct, in case stunned units wake up again?

Disarm which units?

(The self-destructed ones will be insta-killed and won't be able to rise from the dead.)

[krautbernd]

Disarm which units?

(The self-destructed ones will be insta-killed and won't be able to rise from the dead.)

Stunnning units that are set to self-destruct on death attack. Would it be possible to remove/disable the self-destruct flag if the unit is successfully stunned and falls unconscious? Example would be a suicide bomber unit that is (supposed) to wear an explosive vest. Would it be possible to either retrieve the 'vest' (if the function is bound to an item that can be dropped) or disable the self-destruct alltogether?

[Meridian]

Stunnning units that are set to self-destruct on death. Would it be possible to remove/disable the self-destruct flag if the unit is successfully stunned and falls unconscious? Example would be a suicide bomber unit that is (supposed) to wear an explosive vest. Would it be possible to either retrieve the 'vest' (if the function is bound to an item that can be dropped) or disable the self-destruct alltogether?

I don't understand, please don't mix "self-destruct on death" (existing feature) with "self-destruct on attack" (new feature).

Units that self-destruct on death (cyberdisc):
- are disarmed when stunned or killed... just like every other unit in the game
- don't have to self-destruct... just like vanilla cyberdiscs or bio-drones for example... when killed by stun, melee, HE, etc.

Units that self-destruct on attack (suicide bomber):
- are disarmed when stunned or killed... just like every other unit in the game
- don't self-destruct if you kill or stun them... they only self-destruct if they are the attacker

[krautbernd]

Just noticed I actually wrote self-destruct on death. I meant self-destruct on attack. Sorry for the mix-up.

My question concerns what happens to those units when they wake up. I've never encountered a cyberdisc getting back up after being stunned, but supposedly they would still self-destruct if killed (since the existing self-destruct mechanic is bound to the corpse afaik).

Normal units drop their weapons (if they aren't part of their armor definitions) if they fall unconscious, which includes grenades etc. - would a suicide bomber that is stunned and wakes up still be able to explode or would it be possible to set item(s) that govern the "self-destruct on attack" ability (if the ability is implemented this way) to be droppable?

[Meridian]

My question concerns what happens to those units when they wake up. I've never encountered a cyberdisc getting back up after being stunned, but supposedly they would still self-destruct if killed (since the existing self-destruct mechanic is bound to the corpse afaik).

2x2 units (cyberdisc) cannot wake up, ever.
1x1 units (bio-drone) can wake up, same way as normal units. If you stunned or killed a bio-drone that woke up, it would work exactly the same as if you were doing it to him for the first time. Or in other words, the fact it was stunned before has no impact on anything.

Normal units drop their weapons (if they aren't part of their armor definitions) if they fall unconscious, which includes grenades etc. - would a suicide bomber that is stunned and wakes up still be able to explode or would it be possible to set item(s) that govern the "self-destruct on attack" ability (if the ability is implemented this way) to be droppable?

I don't plan to implement any items (droppable or fixed) to perform unit self-destruct.
The unit itself will explode, not any item it is carrying.

[krautbernd]

2x2 units (cyberdisc) cannot wake up, ever.
1x1 units (bio-drone) can wake up, same way as normal units. If you stunned or killed a bio-drone that woke up, it would work exactly the same as if you were doing it to him for the first time. Or in other words, the fact it was stunned before has no impact on anything.

I don't plan to implement any items (droppable or fixed) to perform unit self-destruct.
The unit itself will explode, not any item it is carrying.

I think I misunderstood the "dummy-item" part you mentioned. I guess my question then would be if the self-destruct flag can be dynamic, with an option to set it to false if the unit falls unconscious.

[zee_ra]

DEV update:

Changing default values technically requires either:
1. not changing them at all, store both modded value and modded default value and decide real-time, which one to use... which is inefficient, prone to errors and cannot be generalized... it's used on a few places, but it's an extreme PITA and cannot be used on larger scale
2. creating a completely new secondary mod system that is processed before the current mod system... just to have the default values prepared before any of the primary mod stuff is processed... that's a huge amount of work, for very questionable benefit

You can basically consider this request as rejected.

A workaround/compromise I can offer is to create a few templates and use

What is the current state of the capability to create new definitions in a mod by inheritance?  Let's consider the following example to illustrate what I mean.  Some mod X depends on mod ORIG, and an item X.weapon_nd should be largely the same as the ORIG.weapon_nd, but perhaps with a new ammo type available.  How could I proceed to implement something like this?

In general, I see no particular trouble with hard-coding module version dependencies, and generating new text for the whole definition of an item (in the example above, a copy of ORIG.weapon_nd with the definition for new ammo spliced-in) in the mod X, using whatever template engine, based on the text that was already present in the mod ORIG.  The strict versioning dependency allow me to ensure that the specific versions of X refer to the exact text in ORIG.  While this is the most general approach, that works with all games that have modding and versioning capability, I would like to inquire if there exists a different mechanism to accomplish the same in OXCE, without the reliance on the external templating engine?

[Meridian]

There is no such thing in OXC/E at the moment.

[zee_ra]

There is no such thing in OXC/E at the moment.

Ok.  Thank you for sharing that.

I wonder, if there's a way to ensure the strict version dependence on the parent mod?  It's something that I could pull off e.g. in HoI 4, and the rest is handled by static (i.e. mod release) generation, from templates, based on the contents of both templates and of the parent mod.

[Meridian]

No, modders are very bad at keeping their version numbers clean.

More often than not, they forget to increase the version number in metadata.yml when releasing a new mod version.

--

If you could live with a "minimum version dependence" (instead of "specific version dependence") on a parent mod (e.g. version 3.5.1 or higher), Yankes is working on that right now and it will be available in the OXC nightlies and next OXCE release within a few weeks.