[Answered] How to detect when BattleActions are used by BattleTypes and [...]?

[Tiny Wisdom]

Subject: [y-script] How to detect when BattleActions are used by BattleTypes and then edit BattleUnit (regardless of outcome)?

Examples:

Example #1: If Aimed Shot is used by Heavy Laser, decrease attacker Stamina/Energy by 50% even if the shot misses or does 0 damage.

Example #2: If Panic Unit is used by Psi-Amp, decrease attacker Health by 50% even if the attempt fails.

Problems:

There isn't a script hook that directly does this.

hitUnit: Requires a unit to actually be hit. Even if I compromised here and required hits, Psi-Amps (for instance) don't trigger this event. Unless there's a way to simulate a hit?

awardExperience: Doesn't actually trigger until the end of the mission. Even if I compromised here and required successful outcomes, the event triggers too late.

newTurnItem: Can't detect when an item is used or change item use costs.

skillUseUnit: Items aren't skills. Unless I can hide the default item actions and replace them with skills that do the exact same thing (but then the skill menu would have to be used and that'd be misleading since they aren't actually psi skills)?

tryPsiAttackUnit: This gets Example #2 the furthest, however, you cannot edit the BattleUnit because attacker and victim are both ptr and not ptre (this is a trivial change at the code level afaik and I would like this change to be made, but it doesn't solve Example #1).

Solutions:

Other than changing things at the code level, I'm out of ideas.

I don't want to roll my own binaries so hopefully I missed an outside-the-box solution?

[Nord]

About examles: it is easy to do with costUse, costSnap etc.

[Yankes]

I have in plans add script hook like this, probably biggest problem for me doing it is figure how best do it as I have bit decision paralysis as there multiple way to do it and each have different draw backs and benefits.


Beside, use of `ptr` is critical and deliberate, changing it will allow crippling game state that could even result in crashes.

[Tiny Wisdom]

About examles: it is easy to do with costUse, costSnap etc.

The reason why I'd prefer a script is so the % penalty in the examples can change based on one or more of the attacker's stats.

For instance, in the Psi-Amp example, it could change based on Psi Skill.

This wouldn't be a problem if costUse (and friends) could use various unit stats as parameters like with damageBonus but it doesn't, iirc.

I have in plans add script hook like this, probably biggest problem for me doing it is figure how best do it as I have bit decision paralysis as there multiple way to do it and each have different draw backs and benefits.

Well that's good to hear.

Beside, use of `ptr` is critical and deliberate, changing it will allow crippling game state that could even result in crashes.

I did read you saying that somewhere.

So either I compromise and use costUse (and friends) until you add the script hook or I change things at the code level and temporarily roll my own binaries?

And just to be clear, there isn't an awful misuse of an existing script hook that can pull off what I want is there?

[Yankes]

Yes, this are only possibility there.

Btw most `cost*` should have option to switch from flat cost to % cost, you should can have 50% hp cost (I could some miss remember bit it should work)

[Tiny Wisdom]

Btw most `cost*` should have option to switch from flat cost to % cost, you should can have 50% hp cost (I could some miss remember bit it should work)

It does, however, both flat cost and % cost are fixed values which aren't further modified by using various unit stats as parameters.

So I can't dynamically get 50% if Psi Skill is 0-33 and 25% if Psi Skill is >=34.

[Yankes]

No, cost is static for other parts of AI plan ahead moves. This is why I do not add scripts for cost calculation as it will easy interfere with it and even with reserved move cost.

[Tiny Wisdom]

No, cost is static for other parts of AI plan ahead moves. This is why I do not add scripts for cost calculation as it will easy interfere with it and even with reserved move cost.

That makes sense.

I have in plans add script hook like this, probably biggest problem for me doing it is figure how best do it as I have bit decision paralysis as there multiple way to do it and each have different draw backs and benefits.

I forgot to mention it earlier, but, hopefully the script hook implementation you come up with can also handle:

Example #3: If Launch Missile is used by Blaster Launcher, change waypoints allowed from nine (9) to a number computed using various unit stats as parameters.

[Yankes]

This will be impossible, waypoints number should be set long before item is used, script I want to add is call right after unit was used, this mean too late to change that.

[Tiny Wisdom]

This will be impossible, waypoints number should be set long before item is used, script I want to add is call right after unit was used, this mean too late to change that.

Is that the case even if we skip the computation:

Code: [Select]

items:
  - &STR_BLASTER_LAUNCHER
    type: STR_BLASTER_LAUNCHER
    waypoints: 9
  - type: STR_BLASTER_LAUNCHER_6
    refNode: *STR_BLASTER_LAUNCHER
    waypoints: 6
  - type: STR_BLASTER_LAUNCHER_3
    refNode: *STR_BLASTER_LAUNCHER
    waypoints: 3
and use a (not yet available) script hook to do the rest?

[Yankes]

For what this 3 items will be used? You ask for even more, to script replace one item by another that is another can of worms (you can't replace ammo with corpse and some item are forbidden in some slots).

Proper solution is dedicated calculation of number of waypoins, that can be done safety when game require it. Same how some bonues are calculated.

[Tiny Wisdom]

For what this 3 items will be used? You ask for even more, to script replace one item by another that is another can of worms (you can't replace ammo with corpse and some item are forbidden in some slots).

Proper solution is dedicated calculation of number of waypoins, that can be done safety when game require it. Same how some bonues are calculated.

It's not that I want these 3 particular items.

What I actually want is the dedicated calculation of the number of waypoints but you said that would be impossible so I was seeing if I could think outside the box a bit. Did I misunderstand what you meant?

Of course, someone could try replacing ammo with a forbidden item but my intent was to filter out what was replaceable by using the refNode attribute (i.e. only copies of items with minor changes can replace the original).

What I'm asking for is in line with the first two examples (i.e. restricting item performance by using various unit stats as parameters), it's just that waypoints are an additional factor for Blaster Launchers.

All in all though, I'm asking because I believe you would have a solution that could benefit more modders rather than me duct taping in something at the code level.

[Meridian]

What I actually want is the dedicated calculation of the number of waypoints but you said that would be impossible so I was seeing if I could think outside the box a bit. Did I misunderstand what you meant?

It's not impossible, it's just very inconvenient within the current architecture and flow.

The number of waypoints is in the strictly read-only part of the data model (in the mod ruleset). Adding more read-only instances of a blaster launcher (as you suggested above) changes nothing, actually it adds even more complexity on top: the game would have to be additionally able to somehow temporarily replace underlying read-only rules of a battle item, which is basically like trying to kill a fly with a tactical nuke (not only an overkill, but also a complicated cleanup after the fact).

The calculation of the number of waypoints is a much cleaner approach, but there is no single point where this can be effectively done. The method, which returns this number is used on multiple places and not all of them can provide all parameters needed for calculation. Also, it is called multiple times even just during the actual usage in the battle and could return different results for different calls within the same "usage".

So, we would need to introduce a new modifiable attribute on a BattleItem (instead of RuleItem), and carefully go through the whole process and select where and when this number should be initialized, updated and used. This requires a relatively big refactor, which is possible, but not something Yankes or I are very interested in doing; unless a lot of people show interest.

[Tiny Wisdom]

It's not impossible, it's just very inconvenient within the current architecture and flow.

I wasn't sure about the particulars since I'm not that familiar with the codebase.

So thank you both for taking the time to explain.

P.S. Thus ends my journey with y-script. I'll be making a separate post about some possible rulesets (sorry ;).