Solar's wishlist

[Yankes]

This one is for Yankes, I can't comment much.

Yes, different overkill animations should be possible as you can change any frame of unit graphic.
Probably only problem is overwriting "burn" effect that fade to back unit sprite.

[Solarius Scorch]

Thanks for the response, Meridian. I have cleaned the list, here is the revised version:

1. TERRAIN DESTRUCTION BY MELEE
Priority: high
Justification: Lack of this feature has been a pain since melee weapons were added, and nothing has changed here. Half-assed solutions like 1-tile "ranged" weapons are not really satisfactory, and impossibility of using a machete to damage a bush is frustrating.

2. ALTERNATE ANIMATION FOR OVERKILL
Priority: medium
Justification: A purely aesthetic thing, but adding it would really enhance the experience. Ludicrous Gibs are a trope for a reason, and some weapons just aren't the same without it. Plus it seems (to a layman like me) to be relatively easy to add.

3. RESEARCH: FALSE FOR UFOPAEDIA ARTICLES
Priority: low
Justification: Lack of this option causes confusion with some Piratez players and there's no other way of clearing it up easily (without sacrificing some gameplay).
Clarifications: It's an inversion of "requires". With this, the only article displays when you do not have a given research. It would have to be compatible with requires. For example:
* You find a Plasma Pistol. You can immediately research it regardless of any research prerequisites. It will display an article saying "we think it's an alien weapon, blah blah"
* Later you collect enough knowledge to examine the item in full, which gives you full info, and the old article disappears.
So essentially there are two different articles, which never appear at the same time.
One problem I'm not sure how to approach is writing such rulesets for items. Continuing the plasma pistol example, the "early" research/article could not be STR_PLASMA_PISTOL, because it would conflict with the later article, which would also need to be STR_PLASMA_PISTOL, else the article wouldn't work properly. But it can't be some other string, because then the needItem command wouldn't work. I don't have a good solution at the moment.

4. FACILITIES: REQUIRED STAFF (SOLDIERS)
Priority: low
Justification: I think we have all accepted that this wouldn't happen anytime soon. Anyway, it's not my request and I have never really been interested in it personally, so it's hard for me to evaluate its value.

5. (not on the list but requested elsewhere) MID-BATTLE REINFORCEMENTS FOR THE AI
Priority: very high
Justification: I literally have several missions already designed (and some of it even made!) around this concept. Definitely a must have for almost any tactical game which is supposed to cover various scenarios, and OXCE+ as a whole moves X-Com in that area.

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.


A few comments/clarifications:

(IMO) not worth the effort.
It is a small feature gameplay-wise, but a very large feature (IMO) technically.

I agree. But at this point I consider it a part of the general movement option pack, discussed with Otto. Not the most important part.

I removed this request, because it would be better to keep it separately, in the "special moves" category.

UFO crash/landing sites are limited to one UFO and one xcom craft.

Visually, you can create a craft that looks like two or more craft... see 40k.
Visually, you can create a UFO, which looks like multiple UFOs...
But in the background, there will always be just one of each.

Well, what I really intended is to have multiple buildings per map, spawned with addUFO. But nowadays we can use the Otto's advanced terrain generation instead, with acceptable compromises.

What is this?

I've added more details to the request, based on our recent Discord conversation.

Then don't put it on your list?

I have a soft heart

Anyway, Soldier Transformations now support transforming soldiers into items... so you can make a project that transforms your senior psi operative(s) into resource(s) required to build some advanced Psi facility for example... as requested by Nord.

The initial request from Dioxine was a bit different: soldiers wouldn't be used for construction, but for operation. For example you need to assign someone to a radar (same as assigning scientists to research), else it won't function.
If this is silly, I'll remove it.

I have this from someone:

Not sure if you're trying to protect my privacy, in which case sorry for ruining it... But if you really don't know, then I admit it's mine.

Interesting, thanks.

Wouldn't this run the risk of having units spawn in unreachable/blocked locations, given the random nature of map generation? Would it be possible (or rather practical) to define spawn points manually, akin to how base storage tiles or spawned items (in terrains) are defined?

If you screw up, then it's possible. It's a modder's job to ensure this doesn't happen. On most maps it shouldn't be a problem, as they're open.

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