[Verse] [HealthPipeline] Limitations with the new API in v43.00

General Feedback & Requests (UEFN)
, , ,
1

Select a topic

Verse API

Tell us your feedback. What is working, what is not, and what would you change?

Here is a quick overview of my toughts about the HealthPipeline API that was released on v43.00:

  • health_adjustment_tag: It has <epic_internal> constructor. We can’t make custom damage tags from the base type. The API provide damage_tag and healing_tag which we can subclass, but they don’t fit all use cases (they are always perceived as aggressive or supportive), I want to make for example neutral_health_adjustment_tag which has no bias on assumptions or how receivers will handle it, but the epic_internal prevents it. It should not be marked <epic_internal>, and the class itself should allow being constructed (non-abstract)

  • health_adjustment_entry: is marked as <final>. We can’t subclass them to add constraints or extra data, to be checked later on receivers of the scene event or compute on the modifiers. It should not be marked as <final>

  • health_adjustment_result_entry and health_adjustment_result: same as above, is also marked as <final>, preventing the same subclassing and custom usages with constraints io additional extra data passed (ex. I can’t make a subclass with a field that annotates the receivers that received it, or other values if wanted to pass as callback to the sender). It should not be marked as <final>

  • health_adjustment_event: This one is critical imo. Similar to the first note above, it has <epic_internal> constructor, which means we can’t subclass directly from them to declare new fields to pass data along, add constraints and so on. The API does provides template subclasses damage_event and healing_event that we can subclass, but the same as the first note, it is not neutral and incorrectly assumes a behavior or intent that we may not always want to. We can’t make a neutral_health_adjustment_event. It should not be marked <epic_internal>, and the class itself should allow being constructed (non-abstract)

  • (FortHealthPileline:)*: Everything here is marked as <final>. This one is fine and I agree with the design and its purpose.

We can’t receive the health_adjustment_event AT ALL on any other components. This means that we can’t apply modifiers before passing up along the scene tree, we also can’t make or use custom components that respond to it.
Seems like ONLY the epic provided health_component can “see” and receives the scene events (I assume they cast to the class before sending the event)…
It should not be like that, and completely breaks the purpose of scene events. It should send the event always and get ignored/accepted during the OnReceive call… (like the example bellow)

custom_health_component<public> := class<final_super>(component):
    OnReceive<override>(SceneEvent:scene_event):logic =
        if (health_adjustment_event[SceneEvent]):
            Print("Event Received")
        (super:)OnReceive(SceneEvent) # Or return true/false, does not matter here

This does not work, it should. :arrow_up:

We also don’t get any info about impact data (such as normals, velocity, hit location), which is required for many usages, such as applying VFX, doing scene queries, reacting to gameplay events, particles, spawning other entities and so on.
Sure, not every health adjustment may have a hit data such as collision hit (poison damage effect for example is not a world physical collision), but we should still have that data for when it makes sense.
I think we should have an type of optional field in a interface that drives that information when having it.