Solar's wishlist

[SuperCaffeineDude]

Cool so is that reinforcements supported now? If so I look forward to seeing what people do with that!

I would suggest it's probably a feature highly desirable for vanilla base assaults (enclosed map), for that I would suggest...

direction: DropDownPoints // code searches for middle of base facilities marked as (EntryPoint == true) and uses a 5x5 square (the size of the the vanilla elevator) to place units (could drop units from the highest point to simulate jumping down)

SpawnInSprites [z,y,z] // instead of dropping them from a literal height just play an animation of them landing or teleporting, adds polish. In the case of teleporting, it could  also just be an overlay effect I guess.




I also wonder if, using the "direction: random" placement, one could even simulate an "aerial/orbital bombardment" (probably better achieved if you could teleport items, like primed grenades), it would probably feel a little cruel in most cases, but I imagine someone like Solarius could use it for timed missions.

Sub-Question: Would the script also be able to spawn in Civilian reinforcements (i.e. UN Troop support, Police Responders).

...

Love to reiterate the desire for suicide units, it might sound a little tasteless but mechanically they present an interesting challenge, thus it is such a troupe.

...

Anyway great, excited to see where this goes!

[krautbernd]

Cool so is that reinforcements supported now? If so I look forward to seeing what people do with that![...]

I think it's supported as in 'considered' and not as in 'implemented' though.

The problem I see with the facillities option is that is specific for base assaults, not universal. If you go that route you need different defintions for non base assault situations. I would prefer an universal approach that can be adapted for various mission types/map layouts. Same probably goes for SpawnInSprites - to take advantage of that option you actually need to design your map around it, and you need a way to include that animation (how/where would it be defined? Would it be unit specific? etc.). I think the original request was simply to allow additional unit spawns after the first/zeroth round.

[SuperCaffeineDude]

I think it's supported as in 'considered' and not as in 'implemented' though.

The problem I see with the facillities option is that is specific for base assaults, not universal. If you go that route you need different defintions for non base assault situations. I would prefer an universal approach that can be adapted for various mission types/map layouts. Same probably goes for SpawnInSprites - to take advantage of that option you actually need to design your map around it, and you need a way to include that animation (how/where would it be defined? Would it be unit specific? etc.). I think the original request was simply to allow additional unit spawns after the first/zeroth round.

O'no, shame , still it's interesting.
For the animations I'd imagine you could do either a teleport overlay (like the alien elevator particle effect (or be more inventive idk)), or/and set the animation to null by default (use forward facing sprite), then allow the modder to declare the coordinates on the unit's spritemap if they have made those alterations to said spritemap. (maybe that's not possible and I'm talking nonsense though)

I mean I guess one other thing you could do is have an invisible unit like "muton-teletrooper" "die" and spawn in the unit you want (i.e a "muton") with the "death-animation" acting as that transition.

Regardless I think it's great however (if) it comes 

[wcho035]

6. SUICIDE BOMBERS (new)
Priority: medium
Justification: Enemy units running towards the player and then blowing up is a common thing in games, and it keeps coming up in the OXC community. I consider it useful.

Suggestion of how this will work in benefit with existing available mechanic.

What is propose below a simplified version of the proposal. Part A has been tested to work in my mod. However, melee attacking unit did not die.  Has to be killed by external parties.

In the item ruleset

Part A

Item melee weapon.
damageType: 7
power: 1
costMelee
   health: -350 (Deduct health from suicide attacking unit)

Some future coding is needed to handle the unit health (wielding the melee weapon) deducted to negative value to allow it to die instantly in battlescape. Current coding does not handle dying from negative health value from battlescape using costMelee. Health would not go below 1 as confirm by Meridian

Part B

Item melee weapon.
battleType: 12
power: 350 (Positive or negative value depending how the future coding will remove health from suicide unit.)

battleType 12 is self-melee, a modification from Battletype 3. It might involve more coding but this has added benefit of allowing the future expansion of self inflicting weapons like syringe type weapon to boost a soldier stats.

[krautbernd]

Suggestion of how this will work in benefit with existing available mechanic.

Unit in unit ruleset must have isLeeroyJenkins in its list.

In the item ruleset

Item melee weapon.
damageType: 7
power: 1
costMelee
   health:  -350

Some code to handle the unit wielding the melee weapon dying instantly in battlescape.

Have you actually tried this? Units can't kill themselves this way, nor can they expend more resources than they have (which is kind of obvious, as otherwise having costs wouldn't make much sense). Even it was possible you'd still have to find a way to actually deal radial damage with melee attacks (since afaik melee weapons override any radius settings and deal damage to units only).

Item melee weapon.
battleType: 12
power: -350

battleType 12 is self-melee, a modification from Battletype 3. It might involve more coding but this has added benefit of allowing the future expansion of self inflicting weapons like syringe type weapon to boost a soldier stats.

What is the negative power value supposed to do? Can you elaborate how this is supposed to deal damage to the unit itself AND the the unit that is being attacked, as well as those around it?

EDIT:
I suppose damage could be dealt via self-destruction, but this comes with other drawbacks (or 'features', depending on how you look at it), such as possibly causing chain reactions.

Would it be possible to make isLeeroyJenkins work with ranged weapons?

[Meridian]

Won't work reliably (if at all)...

Yes, this would not work.
Cost of using an item cannot bring health below 1, cannot bring stun over current hp and cannot bring other resources below 0.
It would need to be done differently.

[wcho035]

Hi Meridian, if you choose the path of using a new battletype for this self melee/suicide feature.

Question, I believe the suicide unit has to be “tricked” into thinking like it is using a normal melee weapon. However, when it is attacking a player’s soldier, if it’s weapon does a melee attack on itself, it could bring its health down below zero and dies?

[Meridian]

Question, I believe the suicide unit has to be “tricked” into thinking like it is using a normal melee weapon. However, when it is attacking a player’s soldier, if it’s weapon does a melee attack on itself, it could bring its health down below zero and dies?

Melee weapons don't do area-of-effect damage, you can't hurt yourself with a melee weapon.

[krautbernd]

Hi Meridian, if you choose the path of using a new battletype for this self melee/suicide feature.

You don't need a new battletype if you can get a unit into melee range with a ranged weapon, hence my question of using 'isLeeroyJenkins' behaviour with ranged weapons. Either by introducing a new variable that replicates isLeeroyJenkins but with all weapon types or by introducing a flag which enables an item to be considered a melee weapon for 'isLeeroyJenkins'.

Could this be done / would it be practical?

[wcho035]

Melee weapons don't do area-of-effect damage, you can't hurt yourself with a melee weapon.

Understood, thanks for confirming, I trust you above all when it comes to this kind of information. Then by logic, you will probably choose the most efficient way to code this in making the feature to work.

If you choose the path of giving melee weapon able to do area-of-effect-damage (if possible). Would this also meet Solarius request having Melee weapon able to do terrain damage?  If you can confirm with yes or no?

[krautbernd]

If you choose the path of giving melee weapon able to do area-of-effect-damage (if possible). Would this also meet Solarius request having Melee weapon able to do terrain damage?

No, since area of effect damage isn't the underlaying problem with that. It's that melee weapons only work on units. You can't 'target' melee attacks the way you can with other weapons. Area off effect damage doesn't change that.

[Meridian]

If you choose the path of giving melee weapon able to do area-of-effect-damage (if possible). Would this also meet Solarius request having Melee weapon able to do terrain damage?  If you can confirm with yes or no?

This question cannot be answered with yes or no.

[wcho035]

This question cannot be answered with yes or no.

Okay, thanks for the honest and candid reply. If you can give me a short and detail answer, that will be much appreciated. Lastly, of the two path I laid down above, which would you go to code it. If you approve of this feature.

This shall be my last question on this topic.

[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.